6 ms·

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.
    - tralarpa 8y ago
      Oberon (which is a successor of Modula-2)
      - _ph_ 8y ago
        While I used Modula-2 a lot in a long distant past, I unfortunately never got into Oberon, so I didn't consider it in my comment. Though if Go is a successor to Oberon and Oberon is a successor to Modula-2, Go is also a successor to Modula-2 :).
        pjmlp 8y ago
        Go's method definitions are copied from Oberon-2 syntax.
- matt_m 8y ago
  Go is also statically typed while Erlang/Clojure are dynamically typed. That seems like another pretty significant difference aside from the syntax.
- kureikain 8y ago
  > Backed by major corporation I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python. I think the key thing to make Go adopt is because the Docker project and Hashi Corp. The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams
  - TheDong 8y ago
    You're welcome to your opinion. Anecdotally, I've heard from many people that Go only took off in China because chinese programmers like google and it was sold as a language by google. > Google engineers probably favors Java/Python That's irrelevant. The fact of the matter is that Go has a company backing it and providing a constant stream of well-paid developers and infrastructure. Most small languages can barely afford to have two poorly-paid fulltime developers. I doubt go would exist if there weren't several people getting paid very large quantities of money working on it.
    - kureikain 8y ago
      Let's look at it from different angle. When first release, AWS Lambda or even Google Cloud FUnction didn't support Go. NodeJS always get there. Python is there always. So the point of big company backing it doesn't add much value. Even Google didn't support Go for their Google Cloud Function.
  - tmerr 8y ago
    Eh? I can't speak for all of Google but I like me some Go. It has a culture of minimalism both in language and code, which makes it easy to pick up and read others' work. I wouldn't recommend it for all problems, but it's at least nice for backend services. Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructures with for loops, others immutable datastructures with the stream API. Some code uses dependency injection, while some doesn't. As a result it takes more time to mentally calibrate to the style when pulling up a .java file. Another imperfection: GC pauses can cause request timeouts and are annoying to debug. Python's not perfect either: aside from the obvious performance issues, use of the awkward retrofitted type system makes me wonder why a statically typed language isn't being used to begin with. The lack of good static analysis is especially annoying at Google where the tooling is quite good. Just my 2c
- AnimalMuppet 8y ago
  Major backing can get you publicity, but don't think that's the deciding factor. What really matters is that major backing gets you the resources to produce a really solid, complete standard library. That is a critical component to language success.
- weberc2 8y ago
  I like Go because everything is super simple. From dependency management to unit testing to performance profiling to its build/deploy story, everything just works. I don't need to learn a new configuration language and project configuration format and complex dependency management system just to build my project. I don't need to pick a unit test framework and test runner. I don't need to figure out how to wire said framework / test runner into my build tooling. I don't need to figure out how to ship my app along with its dependencies or make sure that my deployment target has the right version of a VM installed. I don't even need to worry about learning a new IDE. I could keep going, but it's things like this that matter to me even more than the language itself.
- floitsch 8y ago
  Failed programming languages are not popular, which is why it is hard to remember them. For example, Ceylon (backed by Redhat) never got any traction, and most people forgot about it or never heard about it.
pjmlp 8y ago
Modula-2 did it first in 1978. With co-routines and static compilation.
Groxx 8y ago
You can do this with many VM languages too - you package the VM with the code you want to ship. The VM-wrapper still needs to be built for the target arch (like Go), but the code it runs does not (like Go). I will absolutely agree though that Go makes this easy, which is quite a large benefit. But it's not in any way the opposite of a VM.

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.
  - tralarpa 8y ago
    Oberon (which is a successor of Modula-2)
    - _ph_ 8y ago
      While I used Modula-2 a lot in a long distant past, I unfortunately never got into Oberon, so I didn't consider it in my comment. Though if Go is a successor to Oberon and Oberon is a successor to Modula-2, Go is also a successor to Modula-2 :).
      - pjmlp 8y ago
        Go's method definitions are copied from Oberon-2 syntax.
matt_m 8y ago
Go is also statically typed while Erlang/Clojure are dynamically typed. That seems like another pretty significant difference aside from the syntax.
kureikain 8y ago
> Backed by major corporation I don't think Go success has anything to do with Google. Google engineers probably favors Java/Python. I think the key thing to make Go adopt is because the Docker project and Hashi Corp. The second most important thing is it is super easy to compile Go program and run it and adopt by DevOps teams
- TheDong 8y ago
  You're welcome to your opinion. Anecdotally, I've heard from many people that Go only took off in China because chinese programmers like google and it was sold as a language by google. > Google engineers probably favors Java/Python That's irrelevant. The fact of the matter is that Go has a company backing it and providing a constant stream of well-paid developers and infrastructure. Most small languages can barely afford to have two poorly-paid fulltime developers. I doubt go would exist if there weren't several people getting paid very large quantities of money working on it.
  - kureikain 8y ago
    Let's look at it from different angle. When first release, AWS Lambda or even Google Cloud FUnction didn't support Go. NodeJS always get there. Python is there always. So the point of big company backing it doesn't add much value. Even Google didn't support Go for their Google Cloud Function.
- tmerr 8y ago
  Eh? I can't speak for all of Google but I like me some Go. It has a culture of minimalism both in language and code, which makes it easy to pick up and read others' work. I wouldn't recommend it for all problems, but it's at least nice for backend services. Java is a victim of its own success: it has lived through style evolutions which have lead to fragmentation in the ecosystem. Some code uses mutable datastructures with for loops, others immutable datastructures with the stream API. Some code uses dependency injection, while some doesn't. As a result it takes more time to mentally calibrate to the style when pulling up a .java file. Another imperfection: GC pauses can cause request timeouts and are annoying to debug. Python's not perfect either: aside from the obvious performance issues, use of the awkward retrofitted type system makes me wonder why a statically typed language isn't being used to begin with. The lack of good static analysis is especially annoying at Google where the tooling is quite good. Just my 2c
AnimalMuppet 8y ago
Major backing can get you publicity, but don't think that's the deciding factor. What really matters is that major backing gets you the resources to produce a really solid, complete standard library. That is a critical component to language success.
weberc2 8y ago
I like Go because everything is super simple. From dependency management to unit testing to performance profiling to its build/deploy story, everything just works. I don't need to learn a new configuration language and project configuration format and complex dependency management system just to build my project. I don't need to pick a unit test framework and test runner. I don't need to figure out how to wire said framework / test runner into my build tooling. I don't need to figure out how to ship my app along with its dependencies or make sure that my deployment target has the right version of a VM installed. I don't even need to worry about learning a new IDE. I could keep going, but it's things like this that matter to me even more than the language itself.
floitsch 8y ago
Failed programming languages are not popular, which is why it is hard to remember them. For example, Ceylon (backed by Redhat) never got any traction, and most people forgot about it or never heard about it.

pjmlp 8y ago

Modula-2 did it first in 1978. With co-routines and static compilation.

Groxx 8y ago

You can do this with many VM languages too - you package the VM with the code you want to ship. The VM-wrapper still needs to be built for the target arch (like Go), but the code it runs does not (like Go). I will absolutely agree though that Go makes this easy, which is quite a large benefit. But it's not in any way the opposite of a VM.