[karmakaze]

It may have been a dumb comment, but there's some truth to it. Go was to solve a Google problem of devs that needed to write system management programs, not systems themselves. The choices of Python or C/C++ left a large gap that Go filled.

I used Go for most of my own projects and as I got deeper into it began to realize its warts, but the worst was that you can't get performance by "share memory with communicating"--channels are slow. Reading the non-idiomatic stdlib implementation shows the difference of who it's made by vs who it's for (which isn't the authors).

[9rx]

> Go was to solve a Google problem of devs that needed to write system management programs, not systems themselves.

What's the difference? The opposite, so to speak, of system is script, and I don't think system management falls into the scripting category. A system management system is a system too. But that isn't what they were talking about anyway. They were talking in the context of building servers (think like a HTTP server). That was clearly spelt out.

I understand that the Rust crowd has reimagined system to mean something akin to kernel, much like they have reimagined enums to be akin to sum types. Taking established words and coming up with entirely new meanings for them is what they like to do. But that reimagining has no applicability outside of their little community. This is not how the industry in general considers it.

[vessenes]

It’s funny you mention that: my on and off years with go have locked a couple (possibly wrong today) ‘rules’ for go; one is that channels are crazy slow, and another is that defer does not always work like you imagine it will.

There was a sort of misunderstood dream in the early days of go that it would make fanning out and using your 24 cores easy as empowered by channels: this is still not easy in go, although it may be easier and less error prone than c.

In the intervening decade, python has made say a parallel for loop immensely easier.