10 ms·

> I'm happy to go on record claiming that Go is the mainstream language that gets this really right. And it does so by relying on two key principles in its core

by ken 8y ago

> I'm happy to go on record claiming that Go is the mainstream language that gets this really right. And it does so by relying on two key principles in its core design... The unmentioned third principle that it relies on is: "Curly braces, so it looks almost like C if you squint". That's what makes a language "mainstream" these days. It looks like Go is very good at concurrency, but from everything I've read, I don't see how it's any better than Erlang or Clojure. The only controversial part of Eli's claim is the implication that other languages that get concurrency right aren't "mainstream". That's not a well-defined term and so naturally this is going to irk many people. Perhaps the title would have been more accurate as "Go hits the concurrency nail on the head, using the hammer of K&R style". :-)

the_clarence 8y ago
You’re mentioning functional languages. That’s not for everyone or every usecase. (I love Erlang.)
- ken 8y ago
  So, in the world of concurrency, are imperative languages good for every person and every use case? :-) My intention was not to single out functional languages. Those were just the first languages I thought of with the best concurrency support. (I don't think it's mere coincidence, though, that so many concurrency-aware languages are functional. If concurrency is a major concern, perhaps one should consider that "mainstream" or even "imperative" might not necessarily be a hard requirement.) How about Occam or Crystal, then, which use CSP and are imperative yet don't have curly braces?
  - AnimalMuppet 8y ago
    > So, in the world of concurrency, are imperative languages good for every person and every use case? :-) Clearly, no. I think it comes down to the question of shared mutable state. Functional languages say "don't do that, it's evil" - with some justification. If the problem doesn't push you toward shared mutable state, then consider functional languages. When could the problem push you toward shared mutable state? I worked on a video router. You had maybe 100 video sources, maybe 80 video destinations, and six different sources of control. All six sources of control needed to see the same state of what inputs were connected to what outputs. So the fundamental nature of the problem was one giant shared mutable state.
    - XorNot 8y ago
      Where this shows up a lot is the types of business problems which functional programming finds itself in. The least surprising thing in the world is that Haskell and functional Scala work pretty okay for Hadoop ETL work, for example.
- marcosdumay 8y ago
  Neither is concurrency. But if you need concurrency, functional is very visibly the way to go.
  - dnautics 8y ago
    Definitely agree. For work I built a highly concurrent job scheduler in 3 months from zero in elixir, and being confident about the internals due to its functional nature let me focus on smoothening the interface edges
pythonaut_16 8y ago
I don't think Go has better concurrency than Erlang, but go does have generally better raw performance. Ultimately I think both are good languages they just make different trade offs. If I was designing a command line app I'd probably choose Go, if I was designing a web service I'd probably choose Elixir/Erlang. Of course those can easily flip; there are classes of command line apps where I might choose Elixir/Erlang and there are classes of web services where I might choose Go. I can't speak to Clojure though.
nimish 8y ago
Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ignored :(
- fossuser 8y ago
  I think syntax actually matters a lot more then people tend to give credit for in a language's success. I suspect this is why functional languages have struggled to became very popular while languages with C like syntax have added some functional features instead. The learning curve for imperative programming structure just seems easier for people to understand and work with.
  - cube2222 8y ago
    I don't agree. It's just that the familiar is easier. If you first teach someone programming with haskell, they'll have the same hard time switching to C.
  - another-cuppa 8y ago
    Yeah, but is it because people actually like the syntax? Some languages seem to be attractive to people right from the start, like Python. Some take a while to grow on you but then you realise their brilliance and don't want anything else, like Lisp. C isn't either of those.
    - dummyfunnytoo 8y ago
      FWIW, I've disliked the look of Python from the first time I saw it and loved Lisp-like syntax immediately. Can agree on C though.
    - AnimalMuppet 8y ago
      I don't know about that. I grokked C's syntax immediately, just from reading K&R, without actually having a compiler to try anything on. It just made sense to me. I suspect (but cannot prove) that certain languages and/or programming styles make more sense for certain people, and others do so for other people. (There also is almost certainly some bias toward familiarity.)
virmundi 8y ago
Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.
- dev_dull 8y ago
  Go made tradeoffs that maybe didn’t make it “better” at concurrency, but it really did make it easier than alternatives.
- ken 8y ago
  That's a good point. Modern programming languages are all pretty big and complex and whenever someone tries to nail down "this is why it's good/popular" there always seem to be other significant factors that got missed. After all, if it were just one factor that leads to programming language popularity, we could design the Next Big Language by just following that recipe! In the case of Go, I can imagine many of its attributes are significant: - Good concurrency model - Familiar style for imperative C/Algol-family programmers - Requires no VM - Backed by major corporation - Runs on all major OSs - etc Actually, I think I'm changing my mind. I'd put "corporate backing" higher on the list. Some languages have gotten a huge boost by being backed by a major corporation (classic example: Objective-C), and I'm having trouble thinking of a general-purpose programming language backed by a major company that did not become popular (Dart would be my best guess but even that seems to be doing alright).
  - pjmlp 8y ago
    Modula-2 used to fit all those points, except backed by major corporation, unless we consider GM a major corporation.
    - _ph_ 8y ago
      I consider Go as a Modula-2 successor. It shares most traits I liked a lot with Modula-2. I prefer the C-style syntax to the more long-winded one though. The familiarity is no surprise though, considering that Robert Griesemer is a student of Wirth.

by ken 8y ago

the_clarence 8y ago

You’re mentioning functional languages. That’s not for everyone or every usecase. (I love Erlang.)

ken 8y ago
So, in the world of concurrency, are imperative languages good for every person and every use case? :-) My intention was not to single out functional languages. Those were just the first languages I thought of with the best concurrency support. (I don't think it's mere coincidence, though, that so many concurrency-aware languages are functional. If concurrency is a major concern, perhaps one should consider that "mainstream" or even "imperative" might not necessarily be a hard requirement.) How about Occam or Crystal, then, which use CSP and are imperative yet don't have curly braces?
- AnimalMuppet 8y ago
  > So, in the world of concurrency, are imperative languages good for every person and every use case? :-) Clearly, no. I think it comes down to the question of shared mutable state. Functional languages say "don't do that, it's evil" - with some justification. If the problem doesn't push you toward shared mutable state, then consider functional languages. When could the problem push you toward shared mutable state? I worked on a video router. You had maybe 100 video sources, maybe 80 video destinations, and six different sources of control. All six sources of control needed to see the same state of what inputs were connected to what outputs. So the fundamental nature of the problem was one giant shared mutable state.
  - XorNot 8y ago
    Where this shows up a lot is the types of business problems which functional programming finds itself in. The least surprising thing in the world is that Haskell and functional Scala work pretty okay for Hadoop ETL work, for example.
marcosdumay 8y ago
Neither is concurrency. But if you need concurrency, functional is very visibly the way to go.
- dnautics 8y ago
  Definitely agree. For work I built a highly concurrent job scheduler in 3 months from zero in elixir, and being confident about the internals due to its functional nature let me focus on smoothening the interface edges

pythonaut_16 8y ago

I don't think Go has better concurrency than Erlang, but go does have generally better raw performance. Ultimately I think both are good languages they just make different trade offs. If I was designing a command line app I'd probably choose Go, if I was designing a web service I'd probably choose Elixir/Erlang. Of course those can easily flip; there are classes of command line apps where I might choose Elixir/Erlang and there are classes of web services where I might choose Go. I can't speak to Clojure though.

nimish 8y ago

Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ignored :(

fossuser 8y ago
I think syntax actually matters a lot more then people tend to give credit for in a language's success. I suspect this is why functional languages have struggled to became very popular while languages with C like syntax have added some functional features instead. The learning curve for imperative programming structure just seems easier for people to understand and work with.
- cube2222 8y ago
  I don't agree. It's just that the familiar is easier. If you first teach someone programming with haskell, they'll have the same hard time switching to C.
- another-cuppa 8y ago
  Yeah, but is it because people actually like the syntax? Some languages seem to be attractive to people right from the start, like Python. Some take a while to grow on you but then you realise their brilliance and don't want anything else, like Lisp. C isn't either of those.
  - dummyfunnytoo 8y ago
    FWIW, I've disliked the look of Python from the first time I saw it and loved Lisp-like syntax immediately. Can agree on C though.
  - AnimalMuppet 8y ago
    I don't know about that. I grokked C's syntax immediately, just from reading K&R, without actually having a compiler to try anything on. It just made sense to me. I suspect (but cannot prove) that certain languages and/or programming styles make more sense for certain people, and others do so for other people. (There also is almost certainly some bias toward familiarity.)

virmundi 8y ago

Go doesn’t need a VM. That’s key. You get good concurrency with an easy to deploy binary that can target the major chips.

dev_dull 8y ago
Go made tradeoffs that maybe didn’t make it “better” at concurrency, but it really did make it easier than alternatives.
ken 8y ago
That's a good point. Modern programming languages are all pretty big and complex and whenever someone tries to nail down "this is why it's good/popular" there always seem to be other significant factors that got missed. After all, if it were just one factor that leads to programming language popularity, we could design the Next Big Language by just following that recipe! In the case of Go, I can imagine many of its attributes are significant: - Good concurrency model - Familiar style for imperative C/Algol-family programmers - Requires no VM - Backed by major corporation - Runs on all major OSs - etc Actually, I think I'm changing my mind. I'd put "corporate backing" higher on the list. Some languages have gotten a huge boost by being backed by a major corporation (classic example: Objective-C), and I'm having trouble thinking of a general-purpose programming language backed by a major company that did not become popular (Dart would be my best guess but even that seems to be doing alright).
- pjmlp 8y ago
  Modula-2 used to fit all those points, except backed by major corporation, unless we consider GM a major corporation.
  - _ph_ 8y ago
    I consider Go as a Modula-2 successor. It shares most traits I liked a lot with Modula-2. I prefer the C-style syntax to the more long-winded one though. The familiarity is no surprise though, considering that Robert Griesemer is a student of Wirth.