6 ms·

Go just sells itself well. Languages that _actually_ make concurrency easy, such as Haskell, Scala, OCAML or distributed concurreny easy (Erlang/Elixir) are wa

Go just sells itself well. Languages that _actually_ make concurrency easy, such as Haskell, Scala, OCAML or distributed concurreny easy (Erlang/Elixir) are way ahead of Go but are not as hyped and are not marketing themselves as well.

jshen 6y ago
Concurrency isn’t easy in any language.
- Jtsummers 6y ago
  Erlang comes pretty close to achieving this. When/if people get past the “weird” syntax it’s a very straightforward model that minimizes a lot of the hazards, though locks are definitely still possible.
  - neilwilson 6y ago
    The actor model struggles when you run up against something that is naturally sequential and the order matters. If you want a 1000 households to visit a set of shops in a repeatable Random order until the shops runs out of stock, that’s a List sort with a seed and a sequential loop Make the 1000 households concurrent and sending messages and it becomes a major exercise in clocking, scaling and scheduling.
    - mikhailfranco 6y ago
      Erlang processes (Actors) solve this kind of problem naturally, with code that is concise, asynchronous and parallelized. For example, look at solutions for 'Sleeping Barber'. It's possible to write a full solution in <40 SLOC. Starting 1000 processes is trivial and fast in Erlang. See the first few pages of Joe's presentation from 20 years ago: process creation time ~10us (up to 30k processes); message time ~1us [1]. The code is in his book and the email thread [2]: [1] https://www.rabbitmq.com/resources/armstrong.pdf https://www.rabbitmq.com/resources/armstrong.pdf [2] https://erlang.org/pipermail/erlang-questions/2007-July/028068.html https://erlang.org/pipermail/erlang-questions/2007-July/0280...
      - neilwilson 6y ago
        It’s rather more tricky than the sleeping barber. It’s more that their are 100 hairdressers, each household has a set of seven of them and each hairdresser only has a fixed amount of hair colour so not everybody will be served, and you need to be able to repeat the visits deterministically based on a random seed so the only whole process is verifiable.
  - grantjpowell 6y ago
    I really like Fred (ferd) Hebert's take on erlang and concurrency and distribution problems (Earlier in the book he points out how concurrency and distribution are a similar type of problem). https://learnyousomeerlang.com/distribunomicon https://learnyousomeerlang.com/distribunomicon > distributed programming is like being left alone in the dark, with monsters everywhere. It's scary, you don't know what to do or what's coming at you. Bad news: distributed Erlang is still leaving you alone in the dark to fight the scary monsters. It won't do any of that kind of hard work for you. Good news: instead of being alone with nothing but pocket change and a poor sense of aim to kill the monsters, Erlang gives you a flashlight, a machete, and a pretty kick-ass mustache to feel more confident > This is the standard 'tools, not solutions' approach seen before in OTP; you rarely get full-blown software and applications, but you get many components to build systems with. You'll have tools that tell you when parts of the system go up or down, tools to do a bunch of stuff over the network, but hardly any silver bullet that takes care of fixing things for you. As for the weird syntax, I use Elixir (https://elixir-lang.org/ https://elixir-lang.org/) on the daily and its pretty great. See here for a different write up I did https://news.ycombinator.com/item?id=24173635 https://news.ycombinator.com/item?id=24173635
- galaxyLogic 6y ago
  That's a point worth emphasizing. Functional programming is advocated as a means of simplifying programming. When you program with pure functions which always return the same results for the same arguments, things become like mathematics, expressions can be simplified and reasoned about. Yes. But I don't see how such a purely mathematical viewpoint could fit nicely into the real-time world where processes evolve concurrently and can take different times to do things on different executions. In the real world things are mutable, and concurrent programming must take that into account. Therefore it is "complicated".
- iLemming 6y ago
  If anything I learned from writing concurrent code before, and after doing it in Clojure - when talking about uncomplicated concurrency, you have to begin with immutability. Without immutability by default, that conversation is a non-starter.
  - inaseer 6y ago
    That's a fair point. Having said that, it's also interesting to realize that most distributed systems (which are concurrent by their very nature) don't have that luxury. Our micro-services interact with databases, event queues, blob stores etc and each of those external entities is shared mutable state. Furthermore, services can crash at any time and can't start from a clean slate (unlike in-process concurrency which doesn't have to worry about that). My meta-point is that while I agree with your sentiment, the reality of modern day services is that you are _forced_ to reckon with mutable complexity when designing distributed concurrent services (and more and more of us are doing that with the shift to micro-services in the industry)
jeffbee 6y ago
You think Go has a bigger hype machine than Haskell and Erlang? The number of blog posts that have been written about how great Erlang is is comparable in total size to the amount of Erlang code that exists.
- valenterry 6y ago
  > You think Go has a bigger hype machine than Haskell and Erlang? In absolute terms? Yes In terms relative to the userbase? No In terms relative to how powerful or well-designed the language is? Certainly
  - philosopher1234 6y ago
    What don't you like about go's design? I see this sentiment all the time that go is poorly designed. What I don't see all the time is why people have this idea. Is it because its not as strongly typed or mathematically obsessed as other languages? Is it because it doesn't add much that is deeply novel like e.g. Rust?
    - fileeditview 6y ago
      I think people dislike Go because it is missing the fancy feelings. I am more convinced every year that a lot of programmers just love complexity. Simple things will be blown up and abstracted 3 times. This is still possible with Go of course but it is not as easy as with other languages. Go is like a rusty old hammer that will just work and there are not too many ways to hold it. I like Go for this. I think it has a great design. I can do most things from the top of my head. Code reviews are less painful. And I like that the language evolves more slowly and does not pile every crap idea on top of itself. I also know that a language doesn't have to fill every niche.. In the end Go is a productivity language. If you want to get stuff done it is an excellent choice. If you want to muse about the beauty or correctness of your code there probably are better choices.
      - valenterry 6y ago
        I initially just wanted to let your post stay uncommented, but I also don't want people to get the wrong idea, so here is my comment to your last sentence: > In the end Go is a productivity language. If you want to get stuff done it is an excellent choice. Maybe for mediocre developers. And there are a lot of them and that is totally okay - everyone has been one at some point. But more experienced and developers who do their job with passion and strive to improve, will be limited by the language very quickly which makes them much less productive. Therefore, with good developers, go will reduce productivity in comparison to some other languages.
erik_seaberg 6y ago
I like Scala but it inherits Java's issues with shared mutable state and limits on OS threads and stacks. Kotlin coroutines look good but I think they're very new. I haven't learned how Haskell might reconcile concurrency and laziness (is forcing a value serialized?)
- valenterry 6y ago
  I am a professional Scala developer and I can count the number of times where I have created or used shared mutable in the last two years on one hand. No one forces you to do it and the Scala community has developed excellent tools to mitigate these problems when using Java libraries. Same for OS threads. We use green threads in Scala for a long time now, there is a great amount of library support. Here is some example: https://zio.dev/docs/overview/overview_basic_concurrency https://zio.dev/docs/overview/overview_basic_concurrency

jshen 6y ago

Concurrency isn’t easy in any language.

Jtsummers 6y ago
Erlang comes pretty close to achieving this. When/if people get past the “weird” syntax it’s a very straightforward model that minimizes a lot of the hazards, though locks are definitely still possible.
- neilwilson 6y ago
  The actor model struggles when you run up against something that is naturally sequential and the order matters. If you want a 1000 households to visit a set of shops in a repeatable Random order until the shops runs out of stock, that’s a List sort with a seed and a sequential loop Make the 1000 households concurrent and sending messages and it becomes a major exercise in clocking, scaling and scheduling.
  - mikhailfranco 6y ago
    Erlang processes (Actors) solve this kind of problem naturally, with code that is concise, asynchronous and parallelized. For example, look at solutions for 'Sleeping Barber'. It's possible to write a full solution in <40 SLOC. Starting 1000 processes is trivial and fast in Erlang. See the first few pages of Joe's presentation from 20 years ago: process creation time ~10us (up to 30k processes); message time ~1us [1]. The code is in his book and the email thread [2]: [1] https://www.rabbitmq.com/resources/armstrong.pdf https://www.rabbitmq.com/resources/armstrong.pdf [2] https://erlang.org/pipermail/erlang-questions/2007-July/028068.html https://erlang.org/pipermail/erlang-questions/2007-July/0280...
    - neilwilson 6y ago
      It’s rather more tricky than the sleeping barber. It’s more that their are 100 hairdressers, each household has a set of seven of them and each hairdresser only has a fixed amount of hair colour so not everybody will be served, and you need to be able to repeat the visits deterministically based on a random seed so the only whole process is verifiable.
- grantjpowell 6y ago
  I really like Fred (ferd) Hebert's take on erlang and concurrency and distribution problems (Earlier in the book he points out how concurrency and distribution are a similar type of problem). https://learnyousomeerlang.com/distribunomicon https://learnyousomeerlang.com/distribunomicon > distributed programming is like being left alone in the dark, with monsters everywhere. It's scary, you don't know what to do or what's coming at you. Bad news: distributed Erlang is still leaving you alone in the dark to fight the scary monsters. It won't do any of that kind of hard work for you. Good news: instead of being alone with nothing but pocket change and a poor sense of aim to kill the monsters, Erlang gives you a flashlight, a machete, and a pretty kick-ass mustache to feel more confident > This is the standard 'tools, not solutions' approach seen before in OTP; you rarely get full-blown software and applications, but you get many components to build systems with. You'll have tools that tell you when parts of the system go up or down, tools to do a bunch of stuff over the network, but hardly any silver bullet that takes care of fixing things for you. As for the weird syntax, I use Elixir (https://elixir-lang.org/ https://elixir-lang.org/) on the daily and its pretty great. See here for a different write up I did https://news.ycombinator.com/item?id=24173635 https://news.ycombinator.com/item?id=24173635
galaxyLogic 6y ago
That's a point worth emphasizing. Functional programming is advocated as a means of simplifying programming. When you program with pure functions which always return the same results for the same arguments, things become like mathematics, expressions can be simplified and reasoned about. Yes. But I don't see how such a purely mathematical viewpoint could fit nicely into the real-time world where processes evolve concurrently and can take different times to do things on different executions. In the real world things are mutable, and concurrent programming must take that into account. Therefore it is "complicated".
iLemming 6y ago
If anything I learned from writing concurrent code before, and after doing it in Clojure - when talking about uncomplicated concurrency, you have to begin with immutability. Without immutability by default, that conversation is a non-starter.
- inaseer 6y ago
  That's a fair point. Having said that, it's also interesting to realize that most distributed systems (which are concurrent by their very nature) don't have that luxury. Our micro-services interact with databases, event queues, blob stores etc and each of those external entities is shared mutable state. Furthermore, services can crash at any time and can't start from a clean slate (unlike in-process concurrency which doesn't have to worry about that). My meta-point is that while I agree with your sentiment, the reality of modern day services is that you are _forced_ to reckon with mutable complexity when designing distributed concurrent services (and more and more of us are doing that with the shift to micro-services in the industry)

jeffbee 6y ago

You think Go has a bigger hype machine than Haskell and Erlang? The number of blog posts that have been written about how great Erlang is is comparable in total size to the amount of Erlang code that exists.

valenterry 6y ago
> You think Go has a bigger hype machine than Haskell and Erlang? In absolute terms? Yes In terms relative to the userbase? No In terms relative to how powerful or well-designed the language is? Certainly
- philosopher1234 6y ago
  What don't you like about go's design? I see this sentiment all the time that go is poorly designed. What I don't see all the time is why people have this idea. Is it because its not as strongly typed or mathematically obsessed as other languages? Is it because it doesn't add much that is deeply novel like e.g. Rust?
  - fileeditview 6y ago
    I think people dislike Go because it is missing the fancy feelings. I am more convinced every year that a lot of programmers just love complexity. Simple things will be blown up and abstracted 3 times. This is still possible with Go of course but it is not as easy as with other languages. Go is like a rusty old hammer that will just work and there are not too many ways to hold it. I like Go for this. I think it has a great design. I can do most things from the top of my head. Code reviews are less painful. And I like that the language evolves more slowly and does not pile every crap idea on top of itself. I also know that a language doesn't have to fill every niche.. In the end Go is a productivity language. If you want to get stuff done it is an excellent choice. If you want to muse about the beauty or correctness of your code there probably are better choices.
    - valenterry 6y ago
      I initially just wanted to let your post stay uncommented, but I also don't want people to get the wrong idea, so here is my comment to your last sentence: > In the end Go is a productivity language. If you want to get stuff done it is an excellent choice. Maybe for mediocre developers. And there are a lot of them and that is totally okay - everyone has been one at some point. But more experienced and developers who do their job with passion and strive to improve, will be limited by the language very quickly which makes them much less productive. Therefore, with good developers, go will reduce productivity in comparison to some other languages.

erik_seaberg 6y ago

I like Scala but it inherits Java's issues with shared mutable state and limits on OS threads and stacks. Kotlin coroutines look good but I think they're very new. I haven't learned how Haskell might reconcile concurrency and laziness (is forcing a value serialized?)

valenterry 6y ago
I am a professional Scala developer and I can count the number of times where I have created or used shared mutable in the last two years on one hand. No one forces you to do it and the Scala community has developed excellent tools to mitigate these problems when using Java libraries. Same for OS threads. We use green threads in Scala for a long time now, there is a great amount of library support. Here is some example: https://zio.dev/docs/overview/overview_basic_concurrency https://zio.dev/docs/overview/overview_basic_concurrency