5 ms·

> Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing u

> Other than fast compiles and easy binary distribution, I don't see any value here, and I see even experienced Go programmers constantly wasting time writing unreadable boilerplate to work around the bad language design. I know I must be missing something because some people much smarter than me like this language, but... what is it? If you "other than" two huge-for-many-use-cases good things, sure, it might look bad. ;) But I would add good overall performance and in particular straightforward flexible concurrency support to the list of good things. And IMO once you're in the set of "things with good perf" there's generally a lot of "boilerplate" of one sort or another anyway.

sbrother 2y ago
Yeah that's fair. In terms of "things with good perf" I'd rather be writing C++ or Rust, but there are significant issues with using either of those on a large team. I'm more comparing it against languages like Kotlin and Swift, or even Scala.
LinXitoW 2y ago
It might be nit picking, but that's more the ecosystem or tooling that's great. The language is mediocre, but it's what everyone gushes about. I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value". And the fast compiles at least are in big parts because the language is so horrendously basic. Can't get hung up on checking type constraints if you barely have any.
- int_19h 2y ago
  > I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value". I'd say this is still the norm in discourse around Go, it's just that the goalposts have moved somewhat since it has more features now.
zbentley 2y ago
I'm in a similar boat to sbrother (GP) and some of the other sibling commenters: like GP, I don't love the language (honestly, "patronizing" is the word that feels most accurate to describe working in Go for me, if a programming language can even be patronizing); like others, I have been impressed with how well it works when programming in its niche (high-performance network proxies). I'd add what I think is perhaps its most significant benefit to the list: Go fully solved the function coloring I/O problem in a way few other languages (Erlang/Elixir and ... Bend? Others?) have. That's adjacent to the concurrency benefits in the parent comment, but a little different: allowing procedural, non-colored code to be efficiently concurrent over I/O without introducing function coloring or requiring people to code specifically to an event loop/IO multiplexer in some other way requires good concurrency support in the language, to be sure. However, getting rid of function coloring while providing efficient concurrent IO also requires: a solid stdlib of IO capabilities; a very very good runtime that can coalesce goroutine-concurrent IO into multiplexing OS primitives in the same way a function-colored event loop would (while pre-empting/scheduling in a reasonable way that mitigates unexpected blocking); a strong "critical mass" of libraries to talk to common IO-ful systems; a strong community convention of "we will generally prefer reimplementing IO drivers in Go rather than binding/Cgo-ing in foreign code". It's when you combine all of those that Go shines as a platform for concurrent (usually network) IO.

sbrother 2y ago

Yeah that's fair. In terms of "things with good perf" I'd rather be writing C++ or Rust, but there are significant issues with using either of those on a large team. I'm more comparing it against languages like Kotlin and Swift, or even Scala.

LinXitoW 2y ago

It might be nit picking, but that's more the ecosystem or tooling that's great. The language is mediocre, but it's what everyone gushes about. I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value". And the fast compiles at least are in big parts because the language is so horrendously basic. Can't get hung up on checking type constraints if you barely have any.

int_19h 2y ago
> I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value". I'd say this is still the norm in discourse around Go, it's just that the goalposts have moved somewhat since it has more features now.

zbentley 2y ago

I'm in a similar boat to sbrother (GP) and some of the other sibling commenters: like GP, I don't love the language (honestly, "patronizing" is the word that feels most accurate to describe working in Go for me, if a programming language can even be patronizing); like others, I have been impressed with how well it works when programming in its niche (high-performance network proxies). I'd add what I think is perhaps its most significant benefit to the list: Go fully solved the function coloring I/O problem in a way few other languages (Erlang/Elixir and ... Bend? Others?) have. That's adjacent to the concurrency benefits in the parent comment, but a little different: allowing procedural, non-colored code to be efficiently concurrent over I/O without introducing function coloring or requiring people to code specifically to an event loop/IO multiplexer in some other way requires good concurrency support in the language, to be sure. However, getting rid of function coloring while providing efficient concurrent IO also requires: a solid stdlib of IO capabilities; a very very good runtime that can coalesce goroutine-concurrent IO into multiplexing OS primitives in the same way a function-colored event loop would (while pre-empting/scheduling in a reasonable way that mitigates unexpected blocking); a strong "critical mass" of libraries to talk to common IO-ful systems; a strong community convention of "we will generally prefer reimplementing IO drivers in Go rather than binding/Cgo-ing in foreign code". It's when you combine all of those that Go shines as a platform for concurrent (usually network) IO.