Constraints in Go

I sometimes wonder if they should have implemented generics. On the one hand you had a group of people using go as it was and presumably mostly happy with the lack of generics. On the other side you have people (like me) complaining about the lack of generics but who were unlikely to use the language once they were added.

It's very subjective but my gut feeling is they probably didn't expand their community much by adding generics to the language.

I think a lot of the people who wanted generics wanted them more to be like C++ templates, with compile time duck typing. Go maintainers were unwilling to go that route because of complexity. However, as a result, any time I think "oh this looks like it could be made generic" I fall into a rabbit hole regarding what Go generics do and dont allow you to do and usually end up copy pasting code instead.

Generic containers are needed in some cases. Using generic containers with interface{} is very slow and memory-intensive. Not a problem for small containers, but for big containers it's just not feasible, so you would need to either copy&paste huge chunks of code or generate code. Compared to those approaches, generic support is superior in every way, so it's needed. But creating STL on top of them is not the indended use-case.

I think "oh this looks like it could be made generic" is the wrong time to convert to generics.

You should convert when you reach the point "I wish I had that code but with this other type". Even then, sometimes interfaces are the right answer, rather than generics.

Having recently had to work on a Go project for the first time, I think I agree with you here. I'd tried Go a little bit when it came out, had zero interest in what it offered, and then when I was asked to work on this project a couple months ago I thought it would be fun to try it out again since I had read the language had improved.

No, it still feels like programming with a blindfold on and one hand tied behind my back. I truly don't get it. I've worked with a lot of languages and paradigms, am not a zealot by any means. 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?

Mad LoCs, dude, gotta make alotta lines, that’s what productivity is!

> I see even experienced Go programmers constantly wasting time writing unreadable boilerplate

if it is unreadable, in Go, probably the most readable language used today, i would question the aforementioned experience.

What you're doing right now is called "coping".

> 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.

I mostly agree, hence the

> end up copy pasting code instead

bit of my original comment

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.

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.

I don't think a language where for every 1 line of functionality, you need 3 lines of error handling boilerplate gets to be called readable.

Heck, Go went out of it's way to "subvert expectations" more than the last season of Game of Thrones.

99% of decent C-ish languages either do "String thing" or "thing: String", but Go is so fancy and quirky, it does "thing String" for no freaking reason. Don't get me started on the nightmare that is map types.

I like Go's error handling. The reader knows exactly which lines of code can encounter an error, and exactly how the error is handled.

I find that exception-based code is much harder to read. The happy path is clearer, but exceptional code paths are often completely obscured. It's harder to reason about what state the program is in when the exception is handled.

Exceptions have been a mistake, the alternative are Result types, a concept which predates go.

I felt the same way initially, but the language has grown on me. The turning point was writing a lot of Go, like full-time project work for a few months.

But as I've gotten older, I've started striving more and more for simplicity above all else, especially in systems design (disclaimer: I'm an SRE). Go is pretty good at being simple.

There are some things that still annoy me a whole bunch, though. Like - just one example - `fmt.Errorf` not being a first-class syntactic construct (or the difference between `%v` and `%w` in `fmt.Errorf`).

Library authors were the main target group, I think.

Without generics, your library has to define interfaces that your users have to implement and it all gets a bit strange and unintuitive.

With generics you can write library code that is easier to use.

The thing I was worried about with this (adding generics) is that we'd start moving more towards the NPM Hell of everyone just writing plumbing code for imported packages. But thankfully that hasn't happened and idiomatic Go still tends to just use the standard lib and very few external packages.

Most of the improvements made to any language don’t expand the community much. And they don’t have to, because that’s not the point. The point is to improve the language and ecosystem to help make better software.

Generics support is a ubiquitous feature in static programming languages. If it was included on day one in Go, nobody would have blinked an eye. This is only such a controversial topic in Go because the language maintainers made it one.

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.

> 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.

Go doesn't force you to either handle or propagate the error.

And the alternatives are not exceptions, of course, but ADTs.

I frequently hear that Go is simple, and I generally take that to mean that it doesn't have a whole lot of features. But doesn't this then force the complexity on the programmer? There is a set amount of complexity in the world, and either your language models it or you model it, but something has to model it for your program to be a faithful representation of the problem in question. It seems that Go has shunted much of that complexity onto the programmer. This article does a good job of summarizing (and indeed helped to shape) my thoughts on the matter: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...