[PopsiclePete]

I think it's a pretty mediocre language because of the compiler intrinsic data structures and functions like maps and slices that cannot be created by the language proper. It can be verbose and tedious, some of the std lib stuff like "context" ends up "infecting" everything (ala async/await), variable shadowing sucks, still has "nil" instead of something more modern and safe like Rust's Result<T>, etc, etc.

If I had designed this language in a "design a new programming language" college class, I'd probably have gotten a C+ for my efforts at best.

What Go is, is a great tool more than a great language. I like to use it because my output from it is usually reliable, is on time, is light on resources, is easy to deploy, and allows me to get kudos at my job and more $$$. It's wonderful screwdriver for today's screws.

But I don't think it's a great language the way a LISP is a great language, or Smalltalk, or Haskell, or OCaml. It won't really open your eyes to a new way of thinking about problems that you didn't already know from your C days. You still have too much interface{} stuff everywhere, or reflection (which is extremely tedious) or pretty-awful code generation compared to LISP macros.

[akagusu]

> What Go is, is a great tool more than a great language. I like to use it because my output from it is usually reliable, is on time, is light on resources, is easy to deploy, and allows me to get kudos at my job and more $$$. It's wonderful screwdriver for today's screws.

You are completely right. As a language, Go totally sucks in comparison with other "modern" languages but I think no other "modern" language beats Go when you look for them as tools. Go is a "get things done" kind of language that imposes a lot of constrains on what you can do and how you can do and this limits how developers can express themselves, and it makes Go sucks as a language but these exact constrains make Go excel as a engineering tool because Go code is easy enough to read and understand so it makes your team move fast without break things, fast compilation, fast executions, easy in hardware resources.

Definitely a great engineering tool.

[lanstin]

I find my thinking when I did a lot of C network servers was mostly on the state machine. What msgs are needed to do this task and what state needs to be changed to track the piece of work. In Go I design it as a data flow, what inputs, outputs, what channels and go routine pools, etc. the state can be implicit in the local block of the go routine due to the excellence of the run time. And all the cores for free, no sync except to edit hash maps, so design those to be used not per request but less often.