I think a lot of the commenters are missing the point.
Golang is less expressive than other languages, like Rust or Haskell. You can't create fancy custom types and things like that. Of course there are drawbacks.
The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily. That certainly isn't the case for C or C++, and probably others (other people have told me this is true of Rust, but I have not used it, so I will not claim that).
Golang is not the fastest, or the most expressive, or whatever else. But it's got enough expressiveness to not be painful for most use cases (slices, maps, and structs cover a lot of ground). It's fast enough for most use cases (faster than most scripting languages).
In my opinion, Golang has a very good ratio of (effort required to learn) / (utility of learning). I have no doubt that Haskell is extremely powerful... if you can learn how to use it.
I wouldn't be signing up to write a new OS kernel in Go, but for a userland program that doesn't have hard-RT requirements? I think Go strikes a better balance compared to C, C++, Java, Python, and others.
> The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily.
I don't think this necessarily follows. I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go just as easily as other, more expressive languages. In fact, I think it's more likely in Go simply because you _have_ to write more code in Go. More code is more maintenance. Go encourages you to repeat yourself and to not create / use abstractions. Nil pointers are still a thing. It's incredibly easy to accidentally shadow a variable and not handle an error. These are all solved problems in other languages, yet they persist in Go, and they are all maintenance headaches.
> I don't think "clever"ness is what makes code unmaintainable. You can still create a tangled mess in Go...
It's not the only factor, but it is certainly _a_ factor: "Clever code" is typically meant as derogatory. Fancy abstractions for simple use cases is a common cause of tech debt IME, and harder to unwind than under-abstracted code (tedious as that is to fix).
> It's not the only factor, but it is certainly _a_ factor: "Clever code" is typically meant as derogatory
Yep, but here's the thing - if the problem is misuse of the tool, then the solution should be to not misuse the tool. Saying "we will remove features because some people misuse it" is like saying "we will remove headlights from cars because some people drive irresponsibly[1]".
Go remains my language of choice if I have to build efficient webservices, but I really feel sad when people make it sound like Go is awesome because it misses language constructs. No! It is awesome because it is FAST (quite near C) but it is very easy to do simple things like writing http servers, parsing JSON and so on (like Python et al).
Overall, I agree with this sentiment, but it doesn't mean Go couldn't be improved without going all "fancy". Rust isn't the paragon of type systems.
For example, I'd look to languages like Pascal, Modula, Oberon (the last two an important influence on Go in the first place), Ada, and Nim for how to provide practical mechanisms that don't descend into Haskell/ML-style type-system magic. Several of those languages have also implemented generics successfully.
> Golang is less expressive than other languages, like Rust or Haskell. You can't create fancy custom types and things like that. Of course there are drawbacks.
You can absolutely do whatever you want at runtime with reflection. The problem is that compile time type checking possibilities are poor in contrast. It's exactly like C in this regard. You can't type check a linked list in C at compile time. Go has typed arrays but you get my point, replace arrays with generic stacks, generic circular buffers or what not. this isn't "fancy types", it's basic CS.
Golang is less expressive than other languages, like Rust or Haskell. You can't create fancy custom types and things like that. Of course there are drawbacks.
The benefit however, is that it's much harder to write "clever" code, which translates into being harder to write unmaintainable code. If you know Go, you can sit down at nearly any Go codebase and know what's going on pretty easily. That certainly isn't the case for C or C++, and probably others (other people have told me this is true of Rust, but I have not used it, so I will not claim that).
Golang is not the fastest, or the most expressive, or whatever else. But it's got enough expressiveness to not be painful for most use cases (slices, maps, and structs cover a lot of ground). It's fast enough for most use cases (faster than most scripting languages).
In my opinion, Golang has a very good ratio of (effort required to learn) / (utility of learning). I have no doubt that Haskell is extremely powerful... if you can learn how to use it.
I wouldn't be signing up to write a new OS kernel in Go, but for a userland program that doesn't have hard-RT requirements? I think Go strikes a better balance compared to C, C++, Java, Python, and others.