Still, in this case, half the feature is better than none at all, IMO.
As for the detractors, from the first generics proposal this was called out as a "not now", not never. There were questions of implementation. They aren't a super large team, and they try to do things incrementally and do them well.
What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes the meaning.) Those feel much closer to "never" than "not now".)
The post is also subtitled "A change of view".
Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right.
Go has always been a systems language. It was one when we thought it was going to fit nicely for low-level, high performance use-cases. Given that the GC, runtime overhead, lack of control over memory layout, and other issues made it a poor fit for what we historically thought were systems language tasks, it’s still a systems language because we’ve grown to understand that the term “systems program” has always meant network middleware that shuttles around JSON and transforms it.
Dependency management too. Modules were something that nobody argued were unnecessary. None of the language developers ever claimed that “you should always build against HEAD, and if upstream breaks you, that’s a coordination problem to be solved socially”. The community didn’t need to independently invent godep, then glide, then govendor, then dep, before the core team finally shipped modules. That was just enthusiastic parallel exploration of a problem space that everyone agreed was a problem. When modules arrived, everyone was simply relieved that this obvious stopgap was finally replaced.
GOPATH was always understood to be an awkward temporary scaffold that everyone tolerated while the real solution was being designed. The single-workspace model was never defended as philosophically correct or a deliberate feature of the language.
The core team always intended to add builtins for min/max. Nobody ever told you to just write `if a > b { return a }; return b` yourself because it was “only two lines.” The fact that every Go codebase in existence had its own copy of this logic, typically buried in a file called util.go, was not evidence of anything being missing from the language.
Range was always a stopgap before iterators could be implemented. Nobody ever argued that iterators were needlessly complicated and went against the spirit of the language. The slices and maps packages provided important missing features that everyone using the language wanted.
Everyone agrees that errors were anemic from the outset. errors.Is/errors.As are nice additions but everything was Just Fine™ before they were added.
Speaking of errors, having two lines of error-handling boilerplate for every line of code is good, and right, and perfect. It’s not verbose; it’s “explicit”. But when that gets changed to be less verbose, we will all agree that it was always a pain and made reading code unnecessarily more difficult and that everyone always expected this to be fixed some day.
I personally can’t wait to see what next development will never have been “against the Go philosophy” and definitely not something that gophers argued was perfect the way it was any time misguided malcontents and rabble-rousers wrongly tried to suggest the language wasn’t perfect the way it was.
And of course, it was replaced with a more correct implementation that was incompatible with that awful stopgap because semantic correctness trumps all. vendor/ trees and GOPATH were never meant to be remotely compatible, and don't you know -- the Go compatibility guarantee(TM) doesn't apply to misuse of GOPATH to work around shortcomings^Wwell-considered designs of Go, even if it breaks the largest Go project at the time!
(/s It still shocks me that they decided to drop "src" from vendor/src and break compatibility when they finally got around to supporting vendoring despite every tool using it. And symlinks don't work because Plan 9 is the future!!)
Who are we that has always defined that term that way. For any systems programmer golang has pretty much not been a solution.
Systems is below layer 4 of the network stack, it is building the network stack in the first place.
The ease of grokking Go (both reading and writing) are big advantages, and facilitated by the "small" feature set of Go.
The slow turtle wins the race against the overly eager rabbit... so I'm okay with that
Debatable how much they have been "right", although this gets them somewhat closer. And I think they have not been "wrong" in the ways they wanted to avoid (they referenced some issues with Java generics as prior art, although I forget the details).
> The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".
Then when the language is inevitably changed for the better, resolving the complaint, suddenly it was always going to happen it was just a matter of getting the details right.
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. You aren’t going to like the comparison, but it’s extremely Trumpian.
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).
If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient.
Representing it as 1000 separate 1000-element arrays requires 1000 allocations, and pointer-chasing every time we move from one row to the next.
I would very much prefer scheme if the different implementations had a working standard. But I can't take my Chez-scheme code and throw it into Guile-scheme.
But pretty good chance I can take my ECL code and throw it into SBCL or LispWorks.
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.
-- Greenspun's tenth rule
He had some lack of conviction to scope it so narrowly.
As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right
Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329
And besides Rust's high count of RFCs, there are things like async (I'm not complaining about it, but its an obvious large-scale "change"), module system changes, etc.
(To be clear, I like both languages a lot. But I wouldn't call them slow moving or right from the start.)
Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done.
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.
The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums.
Is your attempt at making a point that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically.
iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript.
> Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically.
In a dream world sure we'd have full blown sum types (and that would give a result type which would also solve a lot of the nil-interface-combined-with-error-handling issues that I've ran into when working with go), but I can forgive that. The problem is this - https://www.zarl.dev/posts/enums
The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here:
type Email string
func Send(email Email)
func() { Send("invalid") } // Converted string const does not satisfy Email type expectations
It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". Being able to pass arbitrary values is perfectly in line with a dynamically-typed language. Realistically, the type system in Go is there to give the compiler optimization hints, not to offer type safety. Go was targeted at those wanting to use Python, without the programs being painfully slow to run. How much of a kneecap is implicit type conversion, really, when it is already in line with what the target audience is accustomed to? It is a quirk at best.
If it came out of anywhere else, it might have struggled even to hit the homepage here.
0: https://github.com/carbon-language/carbon-lang#project-statu...
Of course adding generics is not something that every language needs to do. Scripting languages like Ruby don't really need this style of generics. It doesn't fit the design of the language, and it's not even clear what that would look like in Ruby.
But static typing with generics does solve a recurring problem, and we've seen some real convergence towards type hints and type systems even in staunchly dynamic scripting languages. Modern Javascript is now mostly Typescript, and they've successfully retrofitted a very advanced type system in the last place I would have expected 20 years ago.
They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone.
Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm)
Remember that the generics implementations in other languages (like Java) take up half the spec + implementation - that's not something that Go wanted.
> The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".
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!
And it's not like Golang is some freshman student's hobby project; it was created by one of the world's largest tech companies, by people with a strong pedigree in programming language design.