Comment by bad_user | Hacker News Reader

Comment by bad_user | Hacker News Reader

Parent Full thread

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 functional programming (as in programming with mathematical functions), then you wouldn't want to go back to a language that makes that impossible ;-)

- Akka actors are not the only game in town for processing data, you can also use Finagle, FS2, my own Monix and even Akka Streams; And yes, concurrency often requires multiple solutions because there's no silver bullet and Go's channels suck compared with what you can do with a well grown streaming solution

- Scala's Future are not meant for "hiding threads" and 1:1 multi-threading is actually simpler to reason about, because if that fancy M:N runtime starts being unsuitable (because lets be honest, most M:N platforms are broken in one way or another), then you can't fix it by choosing a more appropriate solution without changing the platform completely

- Your devs are maybe lazy or maybe they don't give a fuck, but given that you're supposedly dealing with concurrency in your software, if those developers struggle with a programming language, then it's time to invest in their education or hire new developers, because the programming language is the least of your problems

- Paul Phillips still works with Scala and he most likely hates languages like Go, so when you mention him or his presentation, it definitely cannot be in support of Go

Paul Phillips here. I searched my tweet archive for my tweets about Go. Draw your own conclusions.

- Kill me before I look at go.

- Nobody shot me first so I looked at go. Sigh. After maybe an hour of go I was ahead of where I was after a week with rust.

- The first audible WTF with go: cuddled else is mandatory. Parse error otherwise.

- go is a terrible, terrible language, yet still a major productivity boost. Amdahl's law in another context.

- You often see languages which are fighting the last war. Go is fighting the War of 1812.

- If someone had made up Go within a work of fiction, they'd have been laughed out of the room.

- I had thought Blub was a rhetorical device, but Go is more Blub than Blub.

- reduce: what you will do with your expectations after you start with Go

- Did they miss any chance to introduce an ad hoc inadequate non-solution? Tool directives in comments! What could go wrong!

- Comical levels of confirmation bias in proglangs. Guy doesn't get it, poor impl, isn't useful, "see?" Examples: scala, python, go.

- Some specifics are enumerations in scala, closures in python, and anything devised since 1980 in go.

- Go: compiler directives in comments is "an elegant design". https://t.co/DjCO1UxgC2 http://t.co/BR3kFxRZvc

- Rust and Scala drown you in complexity. Go drowns you in simplicity.

- This comment sums up Go pretty well. https://t.co/Td9Q3wOW43

- go logging package lets you set the global Writer, but not query it. So you can't save/restore it. Nice job.

- This year's gold medalists in type safety's missing-the-point olympics: Go! https://t.co/ktrlBUEwP9

- Turns out Go is the result of a bar bet between Rob Pike and Robert Heinlein. Everybody lost.

- It’s incredible how far Go has lowered my estimation of the vaunted Google engineer. What an institutional failure.

- Go is what you might come up with if your definition of programming was “shuffling electrons”.

- A Go discussion thread is “how to build a space station with crayons” up to homotopy.

- A supposed selling point of Go is that you can learn it in a day. Think of what that tells you about what it can do.

- The existence of Go leads me to realize the infamous Google technical interview is designed to weed out out-of-the-box thinking.

- I added a second file to https://t.co/ktrlBUEwP9 further explaining how go's casting requirements are broken by design.

- But little did I know, I’m just a “lesser” programmer because I enjoy Go’s simplicity" says a commenter. Well, yeah.

- The Go string type can't be passed as a fmt.Stringer. You apparently have to accept interface{} and type match. Amazing.

- An example of go upside: "go get ...gocov" and code coverage instantly worked. In scala it has always been painful/fragile at best.

- Any go code which has error in parameter position which tests err against nil will silently miss a bunch of errors.

- Hostility to abstraction: the Go story

- Sad that google waited this long to put a deep mind on go.

I missed a couple which didn't mention go:

- Rob Pike is like Henry Ford, except when people said “faster horses” he said “that is the best idea I’ve ever heard.”

- Rob Pike is the Antonin Scalia of programming language design - an Originalist. Except 1970s not 1770s.

Enjoy your horse then; I'll just speed off into the sunset with the latest model Generics Motors has to offer. :)

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 probability that you never did functional programming; and if you did actual functional programming

This sounds a lot like the "no true Scotsman" fallacy. I'm not attacking your argument here, but perhaps you could expound upon that first point and clarify.

> Given the same set of messages in the same order, you arrive at the same actor state

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...

[3] https://alexn.org/blog/2016/05/15/monix-observable.html

Reply on news.ycombinator.com