4 ms·

* "easy" concurrency * rich standard library, particular for internet facing apps * "simple" language * single binaries * massive corporate support * rich

* "easy" concurrency * rich standard library, particular for internet facing apps * "simple" language * single binaries * massive corporate support * rich or full toolset The first and second point fortunately "coincided" with: the move to multi-core chips, and the "second" dot.com boom of the 2010s. Which you could probably attribute to the rise of (Google) Chrome, and the decline (finally!!) of IE6, which held back a lot of "innovation".

heleninboodler 4y ago
I'd add "well designed" to the standard library point. When I first started using Go, one of the things that struck me was that not only was there tons of standard library functionality to do things I'd normally have to install 3rd party modules for in other languages, but those standard library modules (mostly) had well-designed, easy-to-use, and consistent interfaces. Mostly. I'll still never forgive them for making crypto.PublicKey an empty interface.
- dividedbyzero 4y ago
  I don't think Go's stdlib is particularly well-designed. It's not bad, not at all, but it doesn't seem to stick out in that respect.
  - 0des 4y ago
    What's wrong with it?
    - saghm 4y ago
      I haven't used Go in a while, but I remember there was some pain when `Context` began being used for a lot of new APIs but couldn't be introduced to older APIs for compatibility reasons. I also had some frustrations with what seemed like overfitting with standard libraries interfaces, e.g. the interface for closing something returning an error, so then every `close` method would return an error even if it was always nil (which stuck out more to me given that interfaces in Go are implicit, so it wouldn't really be that big a deal to just have a separate interface for closing things without returning an error and no code would have to be changed in all the places that would use it).
ahoka 4y ago
This reads exactly like the joke where successful people describe their daily routine and one of the items besides things like running and meditating once a day is "my parents are millionaires".
- avgcorrection 4y ago
  More like - Stable middle-class upbringing. Ah, I remember how nice it was to decompress at our summer house in Tuscany.
- arinlen 4y ago
  > (...) and one of the items besides things like running and meditating once a day is "my parents are millionaires". Also known as the Elon Musk school of bootstrapping. Step 1: have an emerald mine.
mort96 4y ago
The concurrency is "easy" in that the syntax for spawning a thread is simple... but that's kind of it. Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. But like other languages, you end up in concurrency hell with mutexes and condition variables and semaphores and deadlocks. It has a concurrency story that's about as good as the likes of C++, and inferior to Rust (which errors at compile-time if you do something dangerous) or JavaScript (where the core event loop makes concurrency less necessary and concurrency is achieved with multiprocessing). In my experience, debugging concurrent Go is way harder than debugging concurrent C++, since the cheapness of spawning a new thread makes people much less careful about their threading model.
- fsociety 4y ago
  Strongly disagree. Yes, it is not a free lunch but they have made several deliberate decisions. If you code your Go like you would C++, you are not using the language in its intended fashion. They have nice features like a data race detector and deadlock detector. Channels are not just a concurrent queue, they have nice deliberate things built into them. They are based off of Communicating Sequential Processes (CSP), which has influenced other languages like Rust and Erlang as well. Green threads are very cheap, and therefore remove yet another thing to think about when using threading. They have made good decisions around the memory model for them as well. When I worked in C, the first thing we’d do in a new program is introduce a green thread-like scheduler so we could achieve concurrency. Then achieving parallelism is as simple, heh, as bumping up the number of worker threads and fixing the data races. Go handles both of this for you from the start. So sure, when you are aware of sound multi threading design, know what TSAN is, and have a lot of experience with C++ you can look at Go and scoff and say Rust is better. But for 90% of the programmers I meet in my career, especially those who grew up in the age of the internet, they do not have experience with this and greatly benefit from Go. I am in probably one of HN’s “most coveted” engineering companies, and barely anyone has worked in largely multithreaded programs. It is such a problem that we are now splitting services into processes to avoid handling multithreading. But over in our Go-world this is just not a concern. Seriously, Go is designed really well for backend services. I used to hate on it a lot, but after working at larger tech companies I have bought into it more for those use-cases.

heleninboodler 4y ago

I'd add "well designed" to the standard library point. When I first started using Go, one of the things that struck me was that not only was there tons of standard library functionality to do things I'd normally have to install 3rd party modules for in other languages, but those standard library modules (mostly) had well-designed, easy-to-use, and consistent interfaces. Mostly. I'll still never forgive them for making crypto.PublicKey an empty interface.

dividedbyzero 4y ago
I don't think Go's stdlib is particularly well-designed. It's not bad, not at all, but it doesn't seem to stick out in that respect.
- 0des 4y ago
  What's wrong with it?
  - saghm 4y ago
    I haven't used Go in a while, but I remember there was some pain when `Context` began being used for a lot of new APIs but couldn't be introduced to older APIs for compatibility reasons. I also had some frustrations with what seemed like overfitting with standard libraries interfaces, e.g. the interface for closing something returning an error, so then every `close` method would return an error even if it was always nil (which stuck out more to me given that interfaces in Go are implicit, so it wouldn't really be that big a deal to just have a separate interface for closing things without returning an error and no code would have to be changed in all the places that would use it).

ahoka 4y ago

This reads exactly like the joke where successful people describe their daily routine and one of the items besides things like running and meditating once a day is "my parents are millionaires".

avgcorrection 4y ago
More like - Stable middle-class upbringing. Ah, I remember how nice it was to decompress at our summer house in Tuscany.
arinlen 4y ago
> (...) and one of the items besides things like running and meditating once a day is "my parents are millionaires". Also known as the Elon Musk school of bootstrapping. Step 1: have an emerald mine.

mort96 4y ago

The concurrency is "easy" in that the syntax for spawning a thread is simple... but that's kind of it. Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. But like other languages, you end up in concurrency hell with mutexes and condition variables and semaphores and deadlocks. It has a concurrency story that's about as good as the likes of C++, and inferior to Rust (which errors at compile-time if you do something dangerous) or JavaScript (where the core event loop makes concurrency less necessary and concurrency is achieved with multiprocessing). In my experience, debugging concurrent Go is way harder than debugging concurrent C++, since the cheapness of spawning a new thread makes people much less careful about their threading model.

fsociety 4y ago
Strongly disagree. Yes, it is not a free lunch but they have made several deliberate decisions. If you code your Go like you would C++, you are not using the language in its intended fashion. They have nice features like a data race detector and deadlock detector. Channels are not just a concurrent queue, they have nice deliberate things built into them. They are based off of Communicating Sequential Processes (CSP), which has influenced other languages like Rust and Erlang as well. Green threads are very cheap, and therefore remove yet another thing to think about when using threading. They have made good decisions around the memory model for them as well. When I worked in C, the first thing we’d do in a new program is introduce a green thread-like scheduler so we could achieve concurrency. Then achieving parallelism is as simple, heh, as bumping up the number of worker threads and fixing the data races. Go handles both of this for you from the start. So sure, when you are aware of sound multi threading design, know what TSAN is, and have a lot of experience with C++ you can look at Go and scoff and say Rust is better. But for 90% of the programmers I meet in my career, especially those who grew up in the age of the internet, they do not have experience with this and greatly benefit from Go. I am in probably one of HN’s “most coveted” engineering companies, and barely anyone has worked in largely multithreaded programs. It is such a problem that we are now splitting services into processes to avoid handling multithreading. But over in our Go-world this is just not a concern. Seriously, Go is designed really well for backend services. I used to hate on it a lot, but after working at larger tech companies I have bought into it more for those use-cases.