And this is -exactly- one of the reasons they didn't accept or continue with a sane proposal for more ergonomic error handling. I like go, but this was the one thing that I kept feeling like I was wasting so much time dealing with.

I think it was.

Go without generics was ok. I say that as a fan of generics in other languages.

There is room for languages with simpler feature sets.

It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.)

I'm not sure what Go's value proposition is now.

Developers can't pick it up in a week, as it used to be. Maybe that's okay too, since Go already has critical mass.

Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions.

As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet"

What was surprising is that after Go was released as an open source project, nobody ever stepped up with a workable solution. You can sense the optimism in that original announcement that later turned to "Go might never get generics" dispair. As you'll recall, it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break, which almost certainly never would have happened if Go was still some basement project used by nobody, Go probably still wouldn't have generics.

[1] https://youtu.be/rKnDgT73v8s?t=3267

Error 403. Summarize?

some of us that have to work with people like you are happy that you're constrained by Go.

Ok, and what if you realize you want these things a million lines in? Do you still move off of Go?

Generic programming isn’t some fancy research language feature like dependent types. It’s just a bare minimum feature in any modern typed language.

It’s perplexing that after C# and Java both notably shipped without generics initially then added them later that they decided to ship Go without generics.. only to end up adding them later.

> A for loop is more readable than the lambda soup.

Let's assume you have as slice of strings you want to uppercase. Which of the following is more readable?

    uppercased := slices.Map(inputSlice, strings.ToUpper)
    // or
    uppercased := make([]string, 0, len(inputSlice))
    for _, s := range inputSlice {
      uppercased = append(uppercased, strings.ToUpper(s))
    }

    parsed, err := slices.MapErr(inputstrings, time.ParseDuration)

IMO it depends on the language… to me, map/collect/etc are useful in languages that have the concept of immutable data, because you can initialize an array with a single call chain, and be sure that nothing after that can modify it.

What I’ve seen in the “for loop” approach that I can’t stand, are things like (pseudo code)

  var a = []
  for x in coll1 {
    a.push(foo(x))
  }

  do_stuff_with(a)

  // … further down the function

  for y in coll2 {
    a.push(bar(y))
  }

  do_other_stuff_with(a)

IMO the sane way to do it is to just not incrementally mutate things like that, and stick with giving things a single place where they’re defined and initialized. Go doesn’t really help you here because there’s no such thing as immutable data. So just adding Map/collect or whatever doesn’t really buy you much.

map functions are very useful for iterating over collections. Most functions iterating over collections are useful, because a lot of the data you're commonly dealing with is collections. And most collections are generic.

> Function literals are verbose and inlining is far less agressive.

> Even python shuns map and filter in favor of comprehensions.

That's the problem of the language design. And Python isn't the best language to turn to for language design

> A for loop is more readable than the lambda soup.

A for loop shoving modified items into a temp variable with append() that is then returned is less readable than a map function transforming data. Too bad Go decided to turn lambdas into unreadable soup.

__For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper compile-time generic code to deal with some generic wrapping type (dumb example -- getting a sum of the perimeters of a generic set of shapes in an externally-defined collection type) -- you are forced to work around it with runtime type-switching. There are all sorts of arguments you can make about simplicity but this is an objective shortcoming of Go that is directly caused by generics being added to Go long post 1.0.__

I'm a bit intrigued by this: how would that work with compatibility between libraries, separate compilation and what not? My first instinct is that it would not be a good idea but I might be missing something..?

Fair enough. Primeagen did a video recently renouncing his love of Go over the concerns you've raised.

That said, I'm assuming much of this "wobbly" functionality will live in libraries and will not be common in day to day coding (much as I've seen with generics so far). It's all optional after all.

I use Go because it's simple, capable, and been my prime language for over a decade and that skill enables me to be valuable enough for a decently paying job.

If I were younger with more energy and time on my hands I'd likely be a rustacean but I think I can ride out my career on this. YMMV.

> (dumb example -- getting a sum of the perimeters of a generic set of shapes in an externally-defined collection type)

There's a much more common example: dealing with external APIs that return JSON. Their response is trivially wrapped in Req<T>. Pre-generics Go would force you to write tedious duplicated boilerplate code for each request type, or just "cast to void*" with interface{} and hope for the best.

> adding more stuff to Go at this late stage is just slowly chipping away at Go's uniqueness

Uniqueness should not be the goal of a language.

> "Everything is a trade-off" assumes you're on the Pareto frontier.

100%. it pisses me off so much that i have to hear this idea thrown around constantly.

Somewhat. The trade off is it can be made more complex at the cost of its simplicity. You can argue that some of those tradeoffs don't in fact have to be made because it's not on the Pareto frontier, eg generics, but we'd have to have a specific discussion about specific language features instead of vague generic discission about the language.

I find language wars tiresome at this point. There was no claim that it was a frontier language, or even that it was a great language. My point was that the Go authors do try to consider the impact of enhancements to the language, which I think is appreciated by many that use it.

Yes, just used the word for emphasis :-)

Nothing was broken in the change: there is no need to migrate.

Claude will migrate your whole repo in an hour.

I'm confused by what language regression you are referring to.

> Now developers will waste time migrating the code to stdlib

Why? If it works now it works. Refactoring tools exist, and LLMs make this trivial.

You just seem to hate the language and everything about it, and that's your right but I think your arguments are specious and ignore that most language that go mainstream evolve and that comes with tradeoffs (python2 -> python3, rust in general, etc).

And as far as deliverables go, the code is absolutely foundational to that and Go was made to be maintainable by codemonkeys such as myself.

Anyway, the language and the changes noted in the OP apparently aren't for you and that's ok -- there's plenty of languages out there for everyone's taste.

Reminds me of when Apple finally moved the iPhone to USB-C… they defended lightning for the longest time, but then when when they finally did the switch, all I could think was “the last N years [0] of lightning accessories I’ve bought are now ewaste”… once it became clear USB-C was going to be the future, every year they weren’t using it was another year of future ewaste building up.

Every year go didn’t have generics was another year of workarounds and tech debt building up that would have otherwise been able to be written the right way from the start. Unlike ewaste though, it’s probably impossible to quantify.

[0] I’d probably peg N as the years between when they gave MacBooks USB-C ports for charging, up until the iPhone got them. It’s clear Apple knew they were gonna need to move to it eventually… every year in that period represents a year of lightning cables people bought that could have been still-useful USB-C cables today.

It is not a monolith, maintainers change? Why does it matter so much to you anyway? You can choose not to use generics