211–220 of 378 posts
Earlier quoted context omitted.
For completeness: https://www.indeed.com/jobtrends/q-scala-q-golang.html
Or for those who don't call it "golang": https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html
Making the move from Go to X, and why we're not going back (2018)
Earlier quoted context omitted.
The problem with for-each in a lot of languages is that it's a statement, not an expression, so it only works with mutable data.
I'm definitely in camp map/filter/fold, but if you instantiate a list/accumulator, fill/operate on it inside the loop, then consume it, you're essentially writing pure code. The fact that you're doing it on top of mutable foundations doesn't matter (at that scale).
[Scala team lead at Lightbend here] I'm always eager to learn how we can improve Scala, especially as we kick of the Scala 2.13 cycle (hard at work on compiler performance and standard library improvements). Email is 'adriaan.at("lightbend.com") Regarding Scala's growth, I will leave you with https://www.indeed.com/jobtrends/q-scala.html .
I think a more appropriate comparison for the language would be F#, which is probably not a surprise to you. I have never used Scala professionally, so I can't give any suggestions that would improve the use of Scala for day to day programming. Years ago I was learning 1 language per year, and picked up Scala and F# that way. After completing the Coursera courses on Scala, I put together a few projects on github using it, enough to get some job feelers that ignored my "don't send me job offers." And I realized that while I enjoyed fiddling around with the language on my own, I didn't want to spend my professional time deciphering other people's Scala code, and so I dropped it. Take from that what you will - maybe I am just not cut out for it.
I do use Go professionally, although it is a minority language where I work.
Some notes: - the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual f…
I don't understand the claim that Akka actors are both impure and non-deterministic. If your actor is communicating only through its inbox, then it is both pure and deterministic. Given the same set of messages in the same order, you arrive at the same actor state. Sure, you can do wacky things with side-effects, but that's not akka's fault. > in general if you place those in the same article, there's a high probabil…
You just described object identity (see [1]), which are objects whose state is determined by the history of the messages received. An object with identity is stateful, side-effectful and impure by definition.
So no, an actor is almost never pure or deterministic. I'd also like to emphasize determinism here, because you can never rely on a message ordering, given their completely asynchronous nature, so you get something much worse than OOP objects with identity.
> This sounds a lot like the "no true Scotsman" fallacy
I'm talking about my experience. Given that I'm currently a consultant / contractor, I have had a lot of experience with commercial Scala projects initiated by other companies. And in general the projects that use Akka actors are projects that have nothing to do with functional programming.
This happens for a lot of reasons, the first reason being that most people are not in any way familiar with functional programming, or what FP even is for that matter. Not really surprising, given that most Scala developers tend to be former Java/Python/Ruby developers that get lured by Akka actors and once an application grows, it's hard to change it later. Evolution to functional programming happens in a web service model where new components get built from scratch.
But the second reason is more subtle. Functional programming is all about pushing the side-effects at the edges of your program. And if you want to combine the actor model with functional programming, you have to model your actors in such a way as to not contain any business logic at all (e.g. all business logic to be modeled by pure functions, immutable data-structures and FP-ish streaming libraries), evolved only with `context.become` (see [2]). So such actors should be in charge only with communications, preferably only with external systems. This doesn't happen because it's hard to do, because developers don't have the knowledge or the discipline for it and because it then raises the question: why use actors at all?
Because truth be told, while actors are really good at bi-directional communications, they suck for unidirectional communications, being too low level. And if we're talking about communicating over address spaces, for remoting many end up with other solutions, like Apache Kafka, Zookeeper, etc.
On combining Akka actors with functional programming, I made a presentation about it if interested (see [3]).
[1] https://en.wikipedia.org/wiki/Identity_(object-oriented_prog...
[2] https://github.com/alexandru/scala-best-practices/blob/maste...
Earlier quoted context omitted.
As simple as a distributed, horizontally scalable SQL database, perhaps? ( https://github.com/cockroachdb/cockroach ). Those dumb Go programmers and their toy programs ( https://quicknotes.io/n/1XB0 ).
Developers have been using C and a bunch of other imperative languages for years. They obviously, created software two order magnitudes more complex than CockroachDB (or Docker, or Kubernetes, or etcd). We used to write entire operating systems in assembly, heavens forbid. Just look at the PostgreSQL codebase (all C) and compare that to cockroach DB. Being "a better C" was the original battle cry of Go. It's definite…
I think it is from Non-Go users who would use Go if only it had generics.
This mentions weak IDE support as one of Scala's pain points, but Go has very much the same problem, and the language is vastly less complex. The two best IDEs for Go right now IMO are VS Code and the EAP Gogland, but both of them are not yet on par what you get with Java. VS Code has only support for very rudimentary refactoring (renames) and relies on a rather slow horde of external CLI linters (executed on save) t…
As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…
This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I ha…
I know I'm preaching to the choir here. I know we've all come back to our own code six months later and had to puzzle it out.
Earlier quoted context omitted.
Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider: users.filter(_.active).map(_.email) to be easier to read (and not a pain in the ass to type) than: emails := make([]string, 0) for _, u := range users { if u.active { emails = append(emails, u.email) } } return email The first style is more exp…
The second example is vastly more readable in terms of understanding what it is supposed to do. I mention this as neither a programmer on either Scala nor Go. If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explana…
Earlier quoted context omitted.
Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider: users.filter(_.active).map(_.email) to be easier to read (and not a pain in the ass to type) than: emails := make([]string, 0) for _, u := range users { if u.active { emails = append(emails, u.email) } } return email The first style is more exp…
The second example is vastly more readable in terms of understanding what it is supposed to do. I mention this as neither a programmer on either Scala nor Go. If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explana…