[xyzzy_plugh]

> Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits

I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stability.

> Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.

I think that was very much the intent. There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together.

Go is a _systems_ language at heart. It focuses on maintainability and literacy, and that's where it leads the pack in my eyes. It's possible to squeeze pretty phenomenal performance out of such a simple language. It's easy to drop into assembly for ultimate optimizations.

Perhaps generality is a mistake? I don't miss it. I've never found joy in debugging someone else's generalized metaprogramming.

Building software at serious scale has led me to appreciate the wisdom buried within Go. It's boring and I love it.

I've written a bit of Rust (and a lot of C++) which I find enjoyable enough, but they're tools I rarely find myself reaching for.

[ilovecaching]

> There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together.

Plan 9 is an operating system. If you're referring to goroutines, CSP is completely unrelated to any of the work done at Bell Labs. That was Hoare. Go also kept a ton of terrible ideas, like nil, void (interface{}), and default mutability.

> Go is a _systems_ language at heart.

It really bothers me when people say this, because it's just untrue regurgitation from the Go team. It's not a systems language. It's a language that's pretty good for small web services. It has expensive interop (Solomon Hykes commented on this during one of his Gotime interviews) with C (even the Go team says cgo is not Go).

> It's easy to drop into assembly for ultimate optimizations.

You can only drop down into Plan 9 assembler, which is essentially useless. Write me an SGX lib without cgo in x86 and you can make that claim.

[lossolo]

A lot of your claims about Go are false.

> It's a language that's pretty good for small web services.

I know projects in production running HUGE web services written in Go serving millions of reqs/s. If that's small for you then I don't know what large is. Look at techempower benchmarks[1] and additionally compare the source of actix-raw (Rust) to fasthttp (Go).

OS written in Go: In experiments comparing nearly identical system call, page fault, and context switch code paths written in Go and C, the Go version was 5% to 15% slower.

Read the paper[2]

1. https://www.techempower.com/benchmarks/#section=data-r16&hw=...

2. https://www.usenix.org/system/files/osdi18-cutler.pdf

[pjmlp]

People are doing OS research in Go, and Fuchsia core components like the TCP/IP stack are written in it, regardless of what the HN crowd thinks where Go should be used.

https://github.com/mit-pdos/biscuit

https://github.com/ycoroneos/G.E.R.T

Last version of Plan 9 was actually Inferno, which HNers keep forgetting about, which used Limbo for userspace code.

Limbo uses the channel syntax later adopted by Go.

[UK-Al05]

People do os research in c#

[pjmlp]

And hopefully in the future even more so.

I was quite disappointed how WinDev managed to sink Longhorn and later WP 7.

[erwan]

+1 for Biscuit and Fuchsia