9 ms·

For a few years, I found myself continuously appreciating Go's design and models more and more. Right now, a bit bored of working in the same paradigm for a dec

by mighmi 3y ago

For a few years, I found myself continuously appreciating Go's design and models more and more. Right now, a bit bored of working in the same paradigm for a decade, I've been trying to find new approaches but find myself rather trapped - as after a novel exploration, it turns out the current approach really does seem to work better. Go's whole concurrency model of Communicating Sequential Processes is cool, although seems to be the aspect I question the most. Erlang's Actor Model does seem a bit superior and Go can introduce footguns at points, but I've yet to really investigate the alternatives as much as I'd like. Also, Beej's guide to network programming https://beej.us/guide/bgnet/html/ https://beej.us/guide/bgnet/html/ mentioned in the beginning really is quite fantastic.

vore 3y ago
The thing I find weird about Erlang's design is that actor mailboxes have no backpressure mechanism, which seems like a pretty big footgun. Go channels have their own quirks, but requiring them to be bounded was a good design choice.
- littlestymaar 3y ago
  > Go channels have their own quirks, but requiring them to be bounded was a good design choice. Making it the default is a good design choice, but mandating them isn't: sometimes you don't want backpressure and buffering is what you want, and with no unbounded channel, you easily end up with being an unbounded amount of goroutines instead… (it happened to me once earlier this year)
- superb_dev 3y ago
  Ponylang has backpressure for its actor's
- toast0 3y ago
  BEAM has some backpressure; it used to have more. If you send to a remote process, and the dist buffer is full, you'll be suspended. (Or you can send with no_suspend, and drop rather than suspend). When you send to a local process, you need to lock that processes's mailbox, which offers a little bit of backpressure if there's contention. Doesn't provide backpressure when the recipient process is just ignoring its mailbox, though. IIRC, earlier releases, maybe around r12-r16 would penalize processes that sent to a local process with a big mailbox, but I think that was removed because it didn't really work as envisioned, so better not to have the complexity. There's ways to build systems that are resilient to large mailboxes, but it's not necessarily simple.
- ghayes 3y ago
  And Elixir introduced GenStage to help with this [0]. The thing that I love about erlang's actor model over Go (that for me a fatal flaw with Go and CSP) is the "spooky action at a distance" issue. It's much easier to reason locally within an erlang project, in my opinion, versus a Golang project, since once a channel is created, it's often very difficult to trace its usage. [0] https://elixir-lang.org/blog/2016/07/14/announcing-genstage/ https://elixir-lang.org/blog/2016/07/14/announcing-genstage/
- fidotron 3y ago
  The best effort I've seen to get around this is https://github.com/lpgauth/shackle https://github.com/lpgauth/shackle It was motivated by a need to eliminate OOM errors and supports large scale operation at very low latency.
zer8k 3y ago
I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. That's the problem with Go in general I think. Much like my experience with Ruby on Rails it seems like once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. Great for bottom-tier devs and unmotivated people working on corporate TPS reports. Bad for the motivated engineer. Opportunities like this (to introduce a new idea into the go concurrency ecosystem) are basically impossible.
- Philip-J-Fry 3y ago
  >I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. What's the issue with making Go good for the lowest common denominator developer? This is fantastic for businesses as they can get new developers productive within a few days. It's great for the ecosystem because the barrier of entry is low. Just because it's made simple and easy to pick up doesn't mean you can't write complex software with it. It's a programming language, you can write whatever you want with it. If it makes writing complex software easier, then that's a good thing. The only reason why someone would think that's not a good thing is their ego because $FAVOURITE_LANGUAGE has 10x as many language features and 10x as many ways to do the exact same thing. What is this walled garden you think exists that prevents motivated engineers from doing good work? I like to think of myself as motivated and Go is the reason for that. It made writing complicated concurrent software so much easier for me, and it made reasoning about them so much easier. I do not understand this criticism of Go.
  - didntcheck 3y ago
    I can't help but feel that the reason why new developers reach parity with existing ones so quickly is not due to the productivity of Go, but because the productivity ceiling has been intentionally lowered so that everyone is equally constrained. Having to keep reading reinvented wheels because the language is intentionally poorly expressive is a burden on getting work done. There maybe is only one way to do a thing, and everyone has to keep doing it, rather than being able to write it once and build an abstraction Compare say Java 5 code written with raw servlets implementations and JDBC calls versus modern Spring code. The implementation of the former is easier to understand because everything is very explicit, but the intent of the latter is far easier to understand, since the boilerplate is mostly gone, allowing the actual business logic (what you care about 90% of the time) to be obvious. And you can of course see the implementation if you need to

by mighmi 3y ago

vore 3y ago

The thing I find weird about Erlang's design is that actor mailboxes have no backpressure mechanism, which seems like a pretty big footgun. Go channels have their own quirks, but requiring them to be bounded was a good design choice.

littlestymaar 3y ago
> Go channels have their own quirks, but requiring them to be bounded was a good design choice. Making it the default is a good design choice, but mandating them isn't: sometimes you don't want backpressure and buffering is what you want, and with no unbounded channel, you easily end up with being an unbounded amount of goroutines instead… (it happened to me once earlier this year)
superb_dev 3y ago
Ponylang has backpressure for its actor's
toast0 3y ago
BEAM has some backpressure; it used to have more. If you send to a remote process, and the dist buffer is full, you'll be suspended. (Or you can send with no_suspend, and drop rather than suspend). When you send to a local process, you need to lock that processes's mailbox, which offers a little bit of backpressure if there's contention. Doesn't provide backpressure when the recipient process is just ignoring its mailbox, though. IIRC, earlier releases, maybe around r12-r16 would penalize processes that sent to a local process with a big mailbox, but I think that was removed because it didn't really work as envisioned, so better not to have the complexity. There's ways to build systems that are resilient to large mailboxes, but it's not necessarily simple.
ghayes 3y ago
And Elixir introduced GenStage to help with this [0]. The thing that I love about erlang's actor model over Go (that for me a fatal flaw with Go and CSP) is the "spooky action at a distance" issue. It's much easier to reason locally within an erlang project, in my opinion, versus a Golang project, since once a channel is created, it's often very difficult to trace its usage. [0] https://elixir-lang.org/blog/2016/07/14/announcing-genstage/ https://elixir-lang.org/blog/2016/07/14/announcing-genstage/
fidotron 3y ago
The best effort I've seen to get around this is https://github.com/lpgauth/shackle https://github.com/lpgauth/shackle It was motivated by a need to eliminate OOM errors and supports large scale operation at very low latency.

zer8k 3y ago

I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. That's the problem with Go in general I think. Much like my experience with Ruby on Rails it seems like once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. Great for bottom-tier devs and unmotivated people working on corporate TPS reports. Bad for the motivated engineer. Opportunities like this (to introduce a new idea into the go concurrency ecosystem) are basically impossible.

Philip-J-Fry 3y ago
>I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. What's the issue with making Go good for the lowest common denominator developer? This is fantastic for businesses as they can get new developers productive within a few days. It's great for the ecosystem because the barrier of entry is low. Just because it's made simple and easy to pick up doesn't mean you can't write complex software with it. It's a programming language, you can write whatever you want with it. If it makes writing complex software easier, then that's a good thing. The only reason why someone would think that's not a good thing is their ego because $FAVOURITE_LANGUAGE has 10x as many language features and 10x as many ways to do the exact same thing. What is this walled garden you think exists that prevents motivated engineers from doing good work? I like to think of myself as motivated and Go is the reason for that. It made writing complicated concurrent software so much easier for me, and it made reasoning about them so much easier. I do not understand this criticism of Go.
- didntcheck 3y ago
  I can't help but feel that the reason why new developers reach parity with existing ones so quickly is not due to the productivity of Go, but because the productivity ceiling has been intentionally lowered so that everyone is equally constrained. Having to keep reading reinvented wheels because the language is intentionally poorly expressive is a burden on getting work done. There maybe is only one way to do a thing, and everyone has to keep doing it, rather than being able to write it once and build an abstraction Compare say Java 5 code written with raw servlets implementations and JDBC calls versus modern Spring code. The implementation of the former is easier to understand because everything is very explicit, but the intent of the latter is far easier to understand, since the boilerplate is mostly gone, allowing the actual business logic (what you care about 90% of the time) to be obvious. And you can of course see the implementation if you need to