Or to look at that from another angle, if you were to define a Trait which has generic methods that Trait won't be "dyn-compatible" meaning that you can't do dynamic dispatch with this trait, which may be irrelevant to you (if you don't want dynamic dispatch anyway) or a showstopper (if you needed it, now your project won't compile).

I think your sarcasm detector has gone missing chief.

Um, there is user-level implementation of TCP/IPv4+IPv6 stack in Go [0], developed and used by Google as part of its gVisor.

[0] https://github.com/google/netstack

> I really hope it is more ergonomic error handling.

They've publicly said no more language changes specifically for better error handling are coming, it will at most be the library-level improvements.

Those are fine the way they are. I don’t want the language getting more complicated. Rob Pike has said they’ll never happen. Suggestions like this are extremely against the Go way of doing things. Actually the verbosity is a good thing. It’s explicit.

Spot on. Heaven forbid it turns into a C++ (I'm not a Rust practitioner but from the outside it seems to accrete features pretty quickly as well).

The ease of grokking Go (both reading and writing) are big advantages, and facilitated by the "small" feature set of Go.

I'm not mad, I'm a proponent of stronger type systems. I'm just correcting the record about

> They didn't say they never wanted to do generics, but that they did want to take their time and do them right.

You just can never trust what the go team says.

We care that time and time again, when anyone ever brings up a criticism of the language, they’re told that everything is just fine and it’s not a problem and we just don’t get the Go Philosophy. There’s not a problem, stop trying to make Go like every other language, and changing things would make the language more complicated and worse.

Then when the language is inevitably changed for the better, resolving the complaint, suddenly it was always going to happen and it was just a matter of getting the details right.

Every other language community I can think of is more than willing to acknowledge the shortcomings of their language. “Yeah, this kind of sucks in principle but it’s not something that gets in the way in practice” is a fine perspective. So is “this was a tradeoff; we went in this direction and these are the resulting downsides”. But the golang community practically trips over themselves to constantly argue that obvious shortcomings in the language are actually a good thing and we just don’t get it.

Nobody is saying the language shouldn’t improve. We’ve all been begging the language to improve. But we’re also tired of the constant, obvious, and shameless gaslighting from the community whenever things do get better. You aren’t going to like the comparison, but it’s extremely Trumpian.

All the butt-hurt oracle trolls that roam hacker news are obviously jealous that a decent language has become more popular than java.

Eh, the thing with generics coming late is pretty much what I meant by "organically grown".

My best litmus test these days is support for multidimensional arrays because it's always needed at some point in general purpose languages. CL and Ada had it right from the start while C++ needed C++23/26 to get std::mdspan and we still need to wrap it to pass the underlying/owned memory pool around (https://rosettacode.org/wiki/Multi-dimensional_array for more).

Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`?

Scheme has a coherent and minimalist design, but its ecosystem and abstraction facilities feel too sparse for large applications.

When I started building a Lisp-based machine learning framework, Guile seemed like the right choice because it provides GOOPS and generic functions, yet I still ended up with a lot of boilerplate to compensate for the lack of a strong type system.

Scheme feels to me like C is to C++: not ergonomic for large-scale application development. Go is one of those languages that has both minimalism and productivity.

I think Elixir is a good candidate here. It's small, coherent, and composes well, and (at least to my understanding) the authors consider the language finished, with no new major features planned.

I'd particularly like examples of statically typed languages that "got it right" (since I love me my types)

That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier.

As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right

Indeed, in 2012, it was not clear to anyone that generics were needed /s

I am actually working on my own language, and getting something better than Go is actually not that difficult!

The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have.

Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.

Have you?

Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong.

A good example of where they're kind of stuck is date formatting - it's stupid, unclear, and likely a mistake, but it's not a fundamental flaw; it's just a quirk.

https://en.wikipedia.org/wiki/Worse_is_better

It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson.

If it came out of anywhere else, it might have struggled even to hit the homepage here.

By that logic Windows would be the best operating system ever and perfect in every way, and anyone who disagrees must be wrong about how an OS should be.

So you mean to say that PHP5 and Js from 2007 had a well-founded design?

The basics of a programming language were wrong. The basics of marketing were very right. Those are not the same.

An engineer, of course, understands that there is no such thing as "wrong", only different tradeoffs, but with the rise of "vibe coding" you don't need to be an engineer to play in the world of programming anymore.

cough JavaScript cough

I wanted it 10 years ago.

I remember back in 1995 thinking that it was stupid for Java not to have generics, so instead you had to always cast Vector/Hashtable elements from Object, or implement your own type-specific container classes for every element type (and there wasn’t even a preprocessor to facilitate the latter).

Sum types I didn’t really miss, because you can implement a type-safe equivalent using the Visitor pattern, and retain an interface-implementation separation that native sum types typically don’t provide.

Hi! I'm a human being that is trying to understand the world and make friends along the way. I see you are too! Pleased to meet you.

You asked the question

> Where did "they" say "we" didn't need generics?

And I (re)posted a quote from them, which sounds to me like, at the time, they believed that "we" Go users didn't need generics.

They may have changed their mind, which is totally fine! But I do think it sounds like the person you were replying to wasn't commenting in bad faith or misunderstanding or fighting a straw man as you posted. Seems like a reasonable interpretation of what the Go devs had said at one point. To each his own though!