11 ms·

Go: Support for Generic Methods

311 points by f311a 5mo ago

p0w3n3d 5mo ago
what's wrong with `#define`? <laughing hysterically> nah I'm kidding <after 55 seconds> Seriously, what's wrong with `#define`?
h1fra 5mo ago
slowly implementing all the things they said we didn't need
- TheChaplain 5mo ago
  It's not a bad thing to realize that one can be wrong and then strive for change.
  - a-french-anon 5mo ago
    Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
    - ramon156 5mo ago
      So which language had it right from the start? is there a language that has a very low rewrite status?
      - bbkane 5mo ago
        I'd particularly like examples of statically typed languages that "got it right" (since I love me my types)
        galangalalgol 5mo ago
        Ocaml maybe? Multi threading didn't seem necessary and introduced the possibility of data races.
      - maccard 5mo ago
        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
        blanched 5mo ago
        I'm not familiar with D, but Zig and Rust are well-known for continuously evolving. Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329 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.)
        Maxatar 5mo ago
        D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.
        Kapendev 4mo ago
        Really? Wow, this is like Zig and I love Zig!
        sunsetSamurai 5mo ago
        what's a big project built with D? I feel it gets mentioned a lot on hackernews but I've never run into any project using it in the wild.
        Kapendev 4mo ago
        Flutter
        sieabahlpark 5mo ago
        [dead]
      - poncho_romero 5mo ago
        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.
        sunsetSamurai 5mo ago
        Elixir is missing static types though, it's hard to go back to work on dynamic languages.
        shakow 5mo ago
        Hopefully, it's coming. https://elixir-lang.org/blog/2023/06/22/type-system-updates-research-dev/ https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
    - ndr 5mo ago
      "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Greenspun's tenth rule He had some lack of conviction to scope it so narrowly.
    - bbkane 5mo ago
      I know Go is justly criticized for many of its design decisions, but it still feels well-designed and "small" to me in day to day usage when many other languages don't.
      - a-french-anon 5mo ago
        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 https://rosettacode.org/wiki/Multi-dimensional_array for more).
        nish__ 5mo ago
        Doesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing?
        School-Cotton 5mo ago
        An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. 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.
        nish__ 5mo ago
        I see. That makes sense.
        j_w 5mo ago
        Isn't an array of arrays by definition the sequential implementation? Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be. They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array. Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.
    - xscott 5mo ago
      Scheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive.
      - rootnod3 5mo ago
        Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`?
        xscott 5mo ago
        Heh, I'd probably take R4RS with define-syntax :-)
        rootnod3 5mo ago
        I mean, good choice, but you see the point, right? As much as ANSI CL has it's flaws, it has a standard, as much of a mixed bag it might be. Scheme is just a general potpourri of "we kinda have a guideline, but do whatever". 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.
        xscott 5mo ago
        > you see the point, right? Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown". The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better".
      - 5mo ago
    - rootnod3 5mo ago
      ANSI CL is such a breath of fresh air nowadays. Does what you need, doesn't get in your way, comes with batteries included. And conditions are just god-tier.
      - shakow 5mo ago
        > comes with batteries included I like CL, but I can't agree that a stdlib that doesn't even have a string split function is batteries-included.
        nobleach 5mo ago
        And to bring it full-circle, this is the exact same thing I run into with Go. When I mention how nice it is that Lang X has feature Y, someone is quick to point out that either, "You can BUILD that in Go" or, "You don't really need feature Y". We've proven that we don't really NEED compilers either... but I would hate to have to do my job without them.
    - boxed 5mo ago
      I liked Objective-C (except the C parts). Such a breath of fresh air coming from C++ which was grown like a cancer with tons of features and you felt trapped by every one of them. Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done.
    - iosjunkie 5mo ago
      "properly designed" - ah yes, programming languages are famous for universally agreed upon design philosophies.
    - fhn 5mo ago
      so make your own and let's see how you do
      - rootnod3 5mo ago
        Have you?
      - chlorion 5mo ago
        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.
        ratrace 5mo ago
        [dead]
    - pizza234 5mo ago
      It isn't realistic to expect a design to be "proper in first place" because requirements change; my opinion is indeed the opposite - I find it natural for programming languages to have a (sort of) lifespan, and for new ones to (sort of) take their place.
      - someone_19 5mo ago
        Indeed, in 2012, it was not clear to anyone that generics were needed /s
      - array_key_first 5mo ago
        Sure but literally everyone and their mom said these features were needed and then Go team said "nuh uh!!!" But, as it turns out, they are needed because they solve real problems, and are not just fake complexity like some people strawman. Hopefully next they can add some error handling syntax and controls.
    - skywhopper 5mo ago
      You may be tired of languages evolving over time, but there is no other way to build a rich and useful language.
  - tux3 5mo ago
    I don't think anyone admitted any wrong or had any big change in philosophy. It's always a good thing to learn something along the way. But the current message seems to be that this was the plan all along, and it just took some time to design properly. 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.
    - galangalalgol 5mo ago
      Type hinting seems like the worst of both. You pay the cost on refactor to go change them all, where dynamic typing or static type inference avoid that. You also don't have any of the benefits of static or dynamic typing. My strong preference is static typing with good inference and an ide that shows the inferred types everywhere when asked. Dynamic typing can make some tasks dramatically easier, I'm just not capable of using them without making hideous mistakes.
  - maccard 5mo ago
    There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
    - Jleagle 5mo ago
      Sounds like you want this feature, and you just got it. Not sure how that's wrong. You don't add in every feature from the start.
      - maccard 5mo ago
        I wanted it 10 years ago.
    - whoiskevin 5mo ago
      Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
      - 9rx 5mo ago
        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.
      - jeswin 5mo ago
        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.
        amazingamazing 5mo ago
        This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?
  - layer8 5mo ago
    It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.
    - someone_19 5mo ago
      ...and Java didn't even have basic enums or sum types from the beginning. But it had null. 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) https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY
      - layer8 5mo 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.
      - symaxian 5mo ago
        That is an interesting read, seems some were having a hard time grasping the benefit of having compiler checks for potential null dereferences. Having worked with null safety in TypeScript and Kotlin the extra bit of strictness is nice.
      - pjmlp 5mo ago
        The biggest design issue with adding value types and non nullable to Java, is that the number one design requirement of any solution is not to break Maven Central. Every compiled JAR out there has to keep working as always on a JVM with updated semantics, and worse code has to be compatible, when passing class instances around between old and new code. Then there are the guest languages on the JVM as well.
  - ivanjermakov 5mo ago
    Worst thing a programming language can do is introduce core semantics changes after 1.0. See Python 2 -> 3 and Zig's *gates.
    - metaltyphoon 5mo ago
      Except Zig is not 1.0
      - ivanjermakov 5mo ago
        Of course, just a good case study of how radical languge changes are received by users.
- 9rx 5mo ago
  Of course, if you go back and watch the original Go announcement it said that it would need generics once they figured out how to do it. And when the first version of generics landed it was said that generic methods would be added later, once they figured out how to do it. So that isn't applicable here. The need was always recognized.
  - zarzavat 5mo ago
    If Go had just taken an off-the-shelf implementation of generics in 2009 then they could have spent the last 16 years deliberating over something useful, rather than attempting to reinvent programming language theory. The impression I have always gotten from Go's designers is that they are rather arrogant and averse to the idea of using other people's work. They want to develop everything from first principles, but by so doing end up with poor reinventions of well-studied concepts.
    - 9rx 5mo ago
      > and averse to the idea of using other people's work. They did use someone else's work, though. If you recall, Philip Wadler (of Haskell fame) designed Go's generics. > but by so doing end up with poor reinventions of well-studied concepts. Which is funny as there is probably nobody on earth that would be more capable than Wadler to get the job done. His pedigree in that area of work is pretty astounding. If he couldn't do more than create a poor reinvention, what hope did the laymen working on the Go core team have? Answer: They had no hope. It's not like they weren't trying. Ian Lance Taylor, for instance, is well known for beginning work on generics in Go before it was even first released to the public. He, among others, quite simply, were unable to figure it out. Everything looks easy and straightforward when observed comfortably from an armchair, I suppose.
      - pjmlp 5mo ago
        Yes, the same guy that supported the effort to add generics to Java, a decade beforee Go came to be, talk about not getting language design history. Stop excusing them, they were the first to acknolowdge being wrong in first place, "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." -- https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
- CamouflagedKiwi 5mo ago
  They didn't say they never wanted to do generics, but that they did want to take their time and do them right. 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).
  - tines 5mo ago
    From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".
    - deleted 5mo ago
      [deleted]
    - skywhopper 5mo ago
      Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.
      - stouset 5mo ago
        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.
- Cthulhu_ 5mo ago
  Where did "they" say "we" didn't need generics? That sounds like a bad faith / misinterpretation / straw man; as someone else pointed out, they postponed generics until they figured out the use cases and whatnot. Remember that the generics implementations in other languages (like Java) take up half the spec + implementation - that's not something that Go wanted.
  - tines 5mo ago
    From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".
    - entrope 5mo ago
      You keep posting that. Do you understand the difference between that and "we anticipate that Go will never add generic methods"? What they actually said shows epistemic humility and recognizes that they might change their mind.
      - tines 5mo ago
        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!
        ncruces 5mo ago
        Do you understand the difference between generics and generic methods? We already had generics when they wrote "we don't anticipate adding generic methods."
- fhn 5mo ago
  complaining about things given to you for free
  - doodpants 5mo ago
    I frankly don't buy into this trope that a lack of monetary cost should shield something from criticism. Anything created by humans for other humans, especially tools meant for getting work done, should certainly be open to evaluation/judgement/critcism, regardless of whether the creator chooses to charge for it. 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.
- zarzavat 5mo ago
  Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.
  - 20k 5mo ago
    Its very funny watching certain segments of the programming industry rediscovering incredibly basic programming principles, after railing against them for so long. The AI people are starting to try and create formal specs to force the AI to generate an exact output, which is absolutely hilarious to me Dynamically typed/untyped languages finding that strict and visible typing is actually good is another
    - jimbokun 5mo ago
      I feel like there was a name for formal specs that produce an exact output, but it escapes me…
    - pjmlp 5mo ago
      Another one, WebAssembly people recreating application servers, and networking object models.
  - pjmlp 5mo ago
    Thankfully we already have Java, so using Go is really for the scenarios where it cannot be avoided.
    - Mawr 5mo ago
      Thankfully some of us have taste.
      - za3faran 4mo ago
        Which is why we use platforms and languages that offer superior GCs, optimization, speed, and observability, like the JVM and Java.
- jimbokun 5mo ago
  Because they refuse to do something until they figure out how to do it well. I respect that.
  - tapirl 5mo ago
    Go's generics design is the most clunky one among popular languages.
    - matthewmc3 5mo ago
      Exactly. We heard for years they wouldn't do generics it until they could do it right, and that was perfectly fine with me. Who wouldn't want a well thought out implementation? Then they released generics and it was like, "this is what you thought was the right way to do it?!"
    - jimbokun 5mo ago
      What’s the approach they should have used instead and how would it be better? Especially in terms of keeping fast compile times and overall performance.
      - tapirl 5mo ago
        [dead]
- MrBuddyCasino 5mo ago
  What did they say about proper enums.
  - someone_19 5mo ago
    You already have iota. Type safety is not needed by design: > Go intentionally has a weak type system... Go in general encourages programming by writing code rather than programming by writing types... https://github.com/golang/go/issues/29649#issuecomment-454820179 https://github.com/golang/go/issues/29649#issuecomment-45482...
    - MrBuddyCasino 5mo ago
      Theres a whole universe between proper enums and go becoming Ada. Same with null safety.
      - someone_19 5mo ago
        Ada is the lost knowledge of a past, more advanced civilization.
        pjmlp 5mo ago
        Thankfully not everyone has forgotten. https://www.adacore.com/case-studies/nvidia-adoption-of-spark-new-era-in-security-critical-software-development https://www.adacore.com/case-studies/nvidia-adoption-of-spar...
kardianos 5mo ago
This is great. Will be useful for data access methods! 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.
- dude250711 5mo ago
  Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot?
  - rob74 5mo ago
    In day-to-day usage, the (fast) compilation speed matters much more than the (slow) implementation of new features.
    - christophilus 5mo ago
      I totally agree, but I'd go further and argue that slow implementation of new features is itself a desirable trait. It's one of the reasons why why I like both Go and Clojure.
      - aktau 5mo ago
        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.
  - cookiengineer 5mo ago
    > Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot? The slow turtle wins the race against the overly eager rabbit... so I'm okay with that
    - 5mo ago
nasretdinov 5mo ago
Lack of generic methods was really surprising to me when I was first trying to use generics in Go. Nice to see it being actually implemented
- ncruces 5mo ago
  To be replaced by the surprise when you figure out these methods don't implement interfaces. Still, in this case, half the feature is better than none at all, IMO.
  - nasretdinov 5mo ago
    Generic interfaces are going to be implemented later too if I'm reading correctly. So no real surprises there :). I guess the only surprise yet is that generic interfaces aren't supported, so generic methods physically can't satisfy any interface
    - ncruces 5mo ago
      I didn't see anything beyond "this doesn't prevent us from doing it" yet. Did you?
    - kbolino 5mo ago
      Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1]. [1]: https://doc.rust-lang.org/reference/items/traits.html#r-items.traits.dyn-compatible.associated-functions https://doc.rust-lang.org/reference/items/traits.html#r-item...
      - tialaramex 5mo ago
        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).
reactordev 5mo ago
This resolves a big gap in generics for most people coming from other languages to go so I completely approve this direction. Not saying use it everywhere but if you must use it, it’s better to have it on the struct than call a module level generic func.
binary132 5mo ago
Chasing a perceived gap between language features and user expectations has been and continues to be the greatest error in the leadership of Go.
- pizzafeelsright 5mo ago
  The nagging imperative requires a stronger response than the capitulation of identity.
- MrBuddyCasino 5mo ago
  They should have blocked generics forever and instead have a proper enum. Unpopular opinion, I know.
throwpikerob 5mo ago
A sad day for Go, the pHDs have won, simplicity has died.
- valyala 5mo ago
  Agreed 100%. https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1a620 https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...
- Cthulhu_ 5mo ago
  It only died if you actually applied it in your own codebase - as with any feature, using it is optional.
  - 9rx 5mo ago
    Code is written to be read, and typically for other people to read. So, in practice, it is only optional if everyone else agrees to not use it.
- sdevonoes 5mo ago
  It certainly makes readability of Go code harder.
  - EdwardDiego 5mo ago
    If generics replace code generation or hand coding a concrete implementation for specific types or... operating against interface{} and then switching based on runtime type, then I strongly disagree that it makes reading Go code harder, it makes it, IMO, easier. But that's the thing, it's just IMO.
samber 5mo ago
OMG. I'm going to recode some of my libraries.
mackross 5mo ago
What a happy surprise today! The amount of times I’ve had to do weird janky package APIs so the API was still reasonable is more than I can count.
xena 5mo ago
This will finally let me make the monad library I've been dreaming of for years. Be afraid.
- nasretdinov 5mo ago
  We already have monads at home (return X, err)
- bonesss 5mo ago
  A monad library in go can really on have one name… …
  - oh_fiddlesticks 5mo ago
    Go nad or go home
    - digitaltrees 5mo ago
      Underrated
  - zephen 5mo ago
    Mo-go?
  - throwaway894345 5mo ago
    Mongo
    - WesolyKubeczek 5mo ago
      (is appalled!)
  - whaleofatw2022 5mo ago
    Strife
    - uproarchat 5mo ago
thayne 5mo ago
> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently. I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against using runtime reflection is mostly that it's slow. But that runtime reflection is exactly how you would work around it today. For the Identity example, could the interface be compiled to be basically equivalent to: Identity(any) any and then at the callsite add a cast of the return type to T? I suppose primative non-pointer types add a bit of a wrinkle but even if it generic methods was restricted to pointer types, that's better than nothing. And the number of those types is relatively small, so when the implementation is compiled it could just instantiate method implementations for all the primative types, if they apply, and then maybe remove them if they aren't needed at link time. Of course it's also possible there is some detail I've missed. [1]: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
- whaleofatw2022 5mo ago
  > Of course it's also possible there is some detail I've missed. Can't speak too deeply for Go specifically, but I do know on .NET one of the big reasons generic methods where T is a structure gets monomorphized per type, is so that stack size is adjusted and potentially even arg passing (i.e. large struct) as far as the caller/callee.
- Merovius 5mo ago
  > but the reason against using runtime reflection is mostly that it's slow. More specifically, it is that it would introduce surprising performance cliffs – code becoming surprisingly slow due to seemingly unrelated changes. Though BTQH I think an even more important argument is that you would need to have effectively two generics implementations, one working at runtime and one working at compile time. That's a lot of complexity, with surprising failure modes if these two are not bug-compatible. > But that runtime reflection is exactly how you would work around it today. I think the overwhelming majority of people will "work around it" by just not trying to use generic methods.
pjmlp 5mo ago
Go becoming a proper 21st century language, is like pulling teeth. It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere. Then the design ends up half way there versus being done properly from the beginning.
- piekvorst 5mo ago
  “Done properly from the beginning” means explaining why a particular feature is either included or not. In this sense, Go is done properly from the beginning. It would be wrong to add every popular feature uncritically.
  - pjmlp 5mo ago
    "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." Yeah very critically.
    - piekvorst 5mo ago
      You can’t be omniscient, I think.
      - pjmlp 5mo ago
        It is sufficient to actually care about history of programming languages design, acknowledge the paths trailed before since FORTRAN came up in 1958, no need for omnisciency. Less "we know better", more "actual history".
- zerotolerance 5mo ago
  Your comment could have been, "I've never agreed with the design philosophy behind Go." I've always appreciated the apparent Go design philosophy and feel like it most matches my lessons learned from 20 years in software. Feature minimalism is a feature for languages targeting organizations with thousands of programmers. If by 21st century language, you mean one that has become unrecognizable through multiple generations of fashionable feature and ecosystem thrash then I'm all for Go not becoming a 21st century language. Language should be boring if the target environment is large teams with varied skill sets. Plain speak. Low jumpy behavior. No cream, no syntactic sugar. Get the job done.
ethin 5mo ago
Watch as this gets rejected for nonsensical reasons just like the issue about adding uint128, which also has been open for an extremely long time and they keep moving the goalposts as to reasons why it can't be done...
- piekvorst 5mo ago
  It’s accepted.
  - ethin 5mo ago
    Now there's a surprise. I've generally been very disillusioned with Go after they absolutely stonewalled everybody on uint128 (and continue to do so) for absolutely no reason (and ignoring that it would make many things in the language easier to express).
    - MrBuddyCasino 5mo ago
      > it would make many things in the language easier to express Like what?
      - ethin 5mo ago
        Like IPv6 addresses, UUIDs, the list goes on. Does it mean anything that Go themselves had to invent a custom uint128 type in the standard library because they didn't want to add it to the language? There's a very long list of instances of them stonewalling it here: https://github.com/golang/go/issues/9455 https://github.com/golang/go/issues/9455
        MrBuddyCasino 5mo ago
        I agree with their reasoning, you don’t typically do math with a UUID, 128 bit cryptographic hashes are insecure and outdated anyway, and IPv6 is kinda valid but rare and still doable with slices.
msaher66 5mo ago
Since they can't implement interfaces, Generic methods are just syntax sugar for generic functions. I'm surprised they actually accepted this proposal for sugar.
- tapirl 5mo ago
  Yes, the sugar is just to make chain calls with parameter types possible. The sugar reflects the limitation of the basic of Go generics design. Now they would make the language even more complex for such a small need. In facts, there are more problems in Go generics need to be solved earlier than this: https://go101.org/generics/888-the-status-quo-of-go-custom-generics.html https://go101.org/generics/888-the-status-quo-of-go-custom-g...
  - msaher66 5mo ago
    Thanks for sharing. I had no idea Go's generics had this many limitations.
klik99 5mo ago
I remember lack of generics being pitched as a feature of Go initially, not a lack. The original design goal was simplicity. I don’t use Go, so have no opinion on this, just interesting that it’s going in this direction.
- matthewmc3 5mo ago
  Generics being omitted wasn't pitched as a feature that I ever saw. The discussion was mostly around "hic sunt dracones" with generics. The Go authors were very aware from the get-go that generics are an incredibly difficult thing to implement well, and the commitment was always to not do it until they were really ready to tackle it. The bizarre thing to me is that when they did tackle it, they left this massive implementation gap, and then what little they did implement didn't seem useful enough that anything meaningful was added to the standard library. So all this talk about generics for years was a big nothing-burger. That is, I hope, until 1.27 when this gets released. Flags is one in particular I think is in desperate need of proper generic methods.
apatheticonion 5mo ago
I wrote Go professionally for years. I don't know how many hours I've spent debugging and reviewing nil pointer bugs and race conditions. Generics were sorely needed but the initial implementation was lacking. I moved to Rust professionally 4 years ago and haven't looked back. Mutex<T> Option<T> Result<T, Err> are all phenomenal. I've written everything from web backends, frontends (hurry up wasm, seriously), to Node.js and Python extensions. Web backends use under 1mb of memory and can support hundreds of thousands of concurrent users on a $2/m VPS. Frontends can be beautifully multithreaded. Native extensions can dance between OS threads and multi-threaded runtimes. When I review code I focus only on the logic, not sidetracked by reasoning about race conditions or anything. Great when you review the work of less experienced contributors. The ultra strict compiler is extremely helpful with LLMs. You bounce back and forth until it compiles and, if it compiles, it's usually correct. It's at the point where I can't really see a use case for another language - and yet, no one uses it! It's madness!
- root-parent 5mo ago
  I have nothing to add to your comment, but it matches so eerily my exact experience, that I just wonder if your alias is a second account of mine :-)
- davidatbu 5mo ago
  By frontend, do you mean wasm in the browser? I'd have expected multithreading there, especially in wasm, to be extremely unergonomic. Maybe you mean to refer to concurrency?
axod 5mo ago
And so the cycle will continue. Always a shame when languages cave like this and add extra unnecessary complexity and error prone hard to parse syntax. It'll be interesting to see the next language that comes along rejecting bloat in favor of simplicity, and then we can all start again.
xuanlin314 5mo ago
[flagged]

311 points by f311a 5mo ago

what's wrong with `#define`? <laughing hysterically> nah I'm kidding <after 55 seconds> Seriously, what's wrong with `#define`?

h1fra 5mo ago

slowly implementing all the things they said we didn't need

TheChaplain 5mo ago
It's not a bad thing to realize that one can be wrong and then strive for change.
- a-french-anon 5mo ago
  Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
  - ramon156 5mo ago
    So which language had it right from the start? is there a language that has a very low rewrite status?
    - bbkane 5mo ago
      I'd particularly like examples of statically typed languages that "got it right" (since I love me my types)
      - galangalalgol 5mo ago
        Ocaml maybe? Multi threading didn't seem necessary and introduced the possibility of data races.
    - maccard 5mo ago
      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
      - blanched 5mo ago
        I'm not familiar with D, but Zig and Rust are well-known for continuously evolving. Zig has the (in)famous "Writergate": https://github.com/ziglang/zig/pull/24329 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.)
      - Maxatar 5mo ago
        D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.
        Kapendev 4mo ago
        Really? Wow, this is like Zig and I love Zig!
        sunsetSamurai 5mo ago
        what's a big project built with D? I feel it gets mentioned a lot on hackernews but I've never run into any project using it in the wild.
        Kapendev 4mo ago
        Flutter
        sieabahlpark 5mo ago
        [dead]
    - poncho_romero 5mo ago
      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.
      - sunsetSamurai 5mo ago
        Elixir is missing static types though, it's hard to go back to work on dynamic languages.
        shakow 5mo ago
        Hopefully, it's coming. https://elixir-lang.org/blog/2023/06/22/type-system-updates-research-dev/ https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
  - ndr 5mo ago
    "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -- Greenspun's tenth rule He had some lack of conviction to scope it so narrowly.
  - bbkane 5mo ago
    I know Go is justly criticized for many of its design decisions, but it still feels well-designed and "small" to me in day to day usage when many other languages don't.
    - a-french-anon 5mo ago
      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 https://rosettacode.org/wiki/Multi-dimensional_array for more).
      - nish__ 5mo ago
        Doesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing?
        School-Cotton 5mo ago
        An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. 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.
        nish__ 5mo ago
        I see. That makes sense.
        j_w 5mo ago
        Isn't an array of arrays by definition the sequential implementation? Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be. They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array. Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.
  - xscott 5mo ago
    Scheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive.
    - rootnod3 5mo ago
      Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`?
      - xscott 5mo ago
        Heh, I'd probably take R4RS with define-syntax :-)
        rootnod3 5mo ago
        I mean, good choice, but you see the point, right? As much as ANSI CL has it's flaws, it has a standard, as much of a mixed bag it might be. Scheme is just a general potpourri of "we kinda have a guideline, but do whatever". 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.
        xscott 5mo ago
        > you see the point, right? Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown". The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better".
    - 5mo ago
  - rootnod3 5mo ago
    ANSI CL is such a breath of fresh air nowadays. Does what you need, doesn't get in your way, comes with batteries included. And conditions are just god-tier.
    - shakow 5mo ago
      > comes with batteries included I like CL, but I can't agree that a stdlib that doesn't even have a string split function is batteries-included.
      - nobleach 5mo ago
        And to bring it full-circle, this is the exact same thing I run into with Go. When I mention how nice it is that Lang X has feature Y, someone is quick to point out that either, "You can BUILD that in Go" or, "You don't really need feature Y". We've proven that we don't really NEED compilers either... but I would hate to have to do my job without them.
  - boxed 5mo ago
    I liked Objective-C (except the C parts). Such a breath of fresh air coming from C++ which was grown like a cancer with tons of features and you felt trapped by every one of them. Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done.
  - iosjunkie 5mo ago
    "properly designed" - ah yes, programming languages are famous for universally agreed upon design philosophies.
  - fhn 5mo ago
    so make your own and let's see how you do
    - rootnod3 5mo ago
      Have you?
    - chlorion 5mo ago
      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.
      - ratrace 5mo ago
        [dead]
  - pizza234 5mo ago
    It isn't realistic to expect a design to be "proper in first place" because requirements change; my opinion is indeed the opposite - I find it natural for programming languages to have a (sort of) lifespan, and for new ones to (sort of) take their place.
    - someone_19 5mo ago
      Indeed, in 2012, it was not clear to anyone that generics were needed /s
    - array_key_first 5mo ago
      Sure but literally everyone and their mom said these features were needed and then Go team said "nuh uh!!!" But, as it turns out, they are needed because they solve real problems, and are not just fake complexity like some people strawman. Hopefully next they can add some error handling syntax and controls.
  - skywhopper 5mo ago
    You may be tired of languages evolving over time, but there is no other way to build a rich and useful language.
- tux3 5mo ago
  I don't think anyone admitted any wrong or had any big change in philosophy. It's always a good thing to learn something along the way. But the current message seems to be that this was the plan all along, and it just took some time to design properly. 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.
  - galangalalgol 5mo ago
    Type hinting seems like the worst of both. You pay the cost on refactor to go change them all, where dynamic typing or static type inference avoid that. You also don't have any of the benefits of static or dynamic typing. My strong preference is static typing with good inference and an ide that shows the inferred types everywhere when asked. Dynamic typing can make some tasks dramatically easier, I'm just not capable of using them without making hideous mistakes.
- maccard 5mo ago
  There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
  - Jleagle 5mo ago
    Sounds like you want this feature, and you just got it. Not sure how that's wrong. You don't add in every feature from the start.
    - maccard 5mo ago
      I wanted it 10 years ago.
  - whoiskevin 5mo ago
    Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
    - 9rx 5mo ago
      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.
    - jeswin 5mo ago
      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.
      - amazingamazing 5mo ago
        This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?
- layer8 5mo ago
  It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.
  - someone_19 5mo ago
    ...and Java didn't even have basic enums or sum types from the beginning. But it had null. 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) https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY
    - layer8 5mo 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.
    - symaxian 5mo ago
      That is an interesting read, seems some were having a hard time grasping the benefit of having compiler checks for potential null dereferences. Having worked with null safety in TypeScript and Kotlin the extra bit of strictness is nice.
    - pjmlp 5mo ago
      The biggest design issue with adding value types and non nullable to Java, is that the number one design requirement of any solution is not to break Maven Central. Every compiled JAR out there has to keep working as always on a JVM with updated semantics, and worse code has to be compatible, when passing class instances around between old and new code. Then there are the guest languages on the JVM as well.
- ivanjermakov 5mo ago
  Worst thing a programming language can do is introduce core semantics changes after 1.0. See Python 2 -> 3 and Zig's *gates.
  - metaltyphoon 5mo ago
    Except Zig is not 1.0
    - ivanjermakov 5mo ago
      Of course, just a good case study of how radical languge changes are received by users.
9rx 5mo ago
Of course, if you go back and watch the original Go announcement it said that it would need generics once they figured out how to do it. And when the first version of generics landed it was said that generic methods would be added later, once they figured out how to do it. So that isn't applicable here. The need was always recognized.
- zarzavat 5mo ago
  If Go had just taken an off-the-shelf implementation of generics in 2009 then they could have spent the last 16 years deliberating over something useful, rather than attempting to reinvent programming language theory. The impression I have always gotten from Go's designers is that they are rather arrogant and averse to the idea of using other people's work. They want to develop everything from first principles, but by so doing end up with poor reinventions of well-studied concepts.
  - 9rx 5mo ago
    > and averse to the idea of using other people's work. They did use someone else's work, though. If you recall, Philip Wadler (of Haskell fame) designed Go's generics. > but by so doing end up with poor reinventions of well-studied concepts. Which is funny as there is probably nobody on earth that would be more capable than Wadler to get the job done. His pedigree in that area of work is pretty astounding. If he couldn't do more than create a poor reinvention, what hope did the laymen working on the Go core team have? Answer: They had no hope. It's not like they weren't trying. Ian Lance Taylor, for instance, is well known for beginning work on generics in Go before it was even first released to the public. He, among others, quite simply, were unable to figure it out. Everything looks easy and straightforward when observed comfortably from an armchair, I suppose.
    - pjmlp 5mo ago
      Yes, the same guy that supported the effort to add generics to Java, a decade beforee Go came to be, talk about not getting language design history. Stop excusing them, they were the first to acknolowdge being wrong in first place, "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." -- https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
CamouflagedKiwi 5mo ago
They didn't say they never wanted to do generics, but that they did want to take their time and do them right. 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).
- tines 5mo ago
  From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".
  - deleted 5mo ago
    [deleted]
  - skywhopper 5mo ago
    Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.
    - stouset 5mo ago
      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.
Cthulhu_ 5mo ago
Where did "they" say "we" didn't need generics? That sounds like a bad faith / misinterpretation / straw man; as someone else pointed out, they postponed generics until they figured out the use cases and whatnot. Remember that the generics implementations in other languages (like Java) take up half the spec + implementation - that's not something that Go wanted.
- tines 5mo ago
  From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".
  - entrope 5mo ago
    You keep posting that. Do you understand the difference between that and "we anticipate that Go will never add generic methods"? What they actually said shows epistemic humility and recognizes that they might change their mind.
    - tines 5mo ago
      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!
      - ncruces 5mo ago
        Do you understand the difference between generics and generic methods? We already had generics when they wrote "we don't anticipate adding generic methods."
fhn 5mo ago
complaining about things given to you for free
- doodpants 5mo ago
  I frankly don't buy into this trope that a lack of monetary cost should shield something from criticism. Anything created by humans for other humans, especially tools meant for getting work done, should certainly be open to evaluation/judgement/critcism, regardless of whether the creator chooses to charge for it. 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.
zarzavat 5mo ago
Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.
- 20k 5mo ago
  Its very funny watching certain segments of the programming industry rediscovering incredibly basic programming principles, after railing against them for so long. The AI people are starting to try and create formal specs to force the AI to generate an exact output, which is absolutely hilarious to me Dynamically typed/untyped languages finding that strict and visible typing is actually good is another
  - jimbokun 5mo ago
    I feel like there was a name for formal specs that produce an exact output, but it escapes me…
  - pjmlp 5mo ago
    Another one, WebAssembly people recreating application servers, and networking object models.
- pjmlp 5mo ago
  Thankfully we already have Java, so using Go is really for the scenarios where it cannot be avoided.
  - Mawr 5mo ago
    Thankfully some of us have taste.
    - za3faran 4mo ago
      Which is why we use platforms and languages that offer superior GCs, optimization, speed, and observability, like the JVM and Java.
jimbokun 5mo ago
Because they refuse to do something until they figure out how to do it well. I respect that.
- tapirl 5mo ago
  Go's generics design is the most clunky one among popular languages.
  - matthewmc3 5mo ago
    Exactly. We heard for years they wouldn't do generics it until they could do it right, and that was perfectly fine with me. Who wouldn't want a well thought out implementation? Then they released generics and it was like, "this is what you thought was the right way to do it?!"
  - jimbokun 5mo ago
    What’s the approach they should have used instead and how would it be better? Especially in terms of keeping fast compile times and overall performance.
    - tapirl 5mo ago
      [dead]
MrBuddyCasino 5mo ago
What did they say about proper enums.
- someone_19 5mo ago
  You already have iota. Type safety is not needed by design: > Go intentionally has a weak type system... Go in general encourages programming by writing code rather than programming by writing types... https://github.com/golang/go/issues/29649#issuecomment-454820179 https://github.com/golang/go/issues/29649#issuecomment-45482...
  - MrBuddyCasino 5mo ago
    Theres a whole universe between proper enums and go becoming Ada. Same with null safety.
    - someone_19 5mo ago
      Ada is the lost knowledge of a past, more advanced civilization.
      - pjmlp 5mo ago
        Thankfully not everyone has forgotten. https://www.adacore.com/case-studies/nvidia-adoption-of-spark-new-era-in-security-critical-software-development https://www.adacore.com/case-studies/nvidia-adoption-of-spar...

kardianos 5mo ago

This is great. Will be useful for data access methods! 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.

dude250711 5mo ago
Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot?
- rob74 5mo ago
  In day-to-day usage, the (fast) compilation speed matters much more than the (slow) implementation of new features.
  - christophilus 5mo ago
    I totally agree, but I'd go further and argue that slow implementation of new features is itself a desirable trait. It's one of the reasons why why I like both Go and Clojure.
    - aktau 5mo ago
      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.
- cookiengineer 5mo ago
  > Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot? The slow turtle wins the race against the overly eager rabbit... so I'm okay with that
  - 5mo ago

nasretdinov 5mo ago

Lack of generic methods was really surprising to me when I was first trying to use generics in Go. Nice to see it being actually implemented

ncruces 5mo ago
To be replaced by the surprise when you figure out these methods don't implement interfaces. Still, in this case, half the feature is better than none at all, IMO.
- nasretdinov 5mo ago
  Generic interfaces are going to be implemented later too if I'm reading correctly. So no real surprises there :). I guess the only surprise yet is that generic interfaces aren't supported, so generic methods physically can't satisfy any interface
  - ncruces 5mo ago
    I didn't see anything beyond "this doesn't prevent us from doing it" yet. Did you?
  - kbolino 5mo ago
    Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1]. [1]: https://doc.rust-lang.org/reference/items/traits.html#r-items.traits.dyn-compatible.associated-functions https://doc.rust-lang.org/reference/items/traits.html#r-item...
    - tialaramex 5mo ago
      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).

reactordev 5mo ago

This resolves a big gap in generics for most people coming from other languages to go so I completely approve this direction. Not saying use it everywhere but if you must use it, it’s better to have it on the struct than call a module level generic func.

binary132 5mo ago

Chasing a perceived gap between language features and user expectations has been and continues to be the greatest error in the leadership of Go.

pizzafeelsright 5mo ago
The nagging imperative requires a stronger response than the capitulation of identity.
MrBuddyCasino 5mo ago
They should have blocked generics forever and instead have a proper enum. Unpopular opinion, I know.

throwpikerob 5mo ago

A sad day for Go, the pHDs have won, simplicity has died.

valyala 5mo ago
Agreed 100%. https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1a620 https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...
Cthulhu_ 5mo ago
It only died if you actually applied it in your own codebase - as with any feature, using it is optional.
- 9rx 5mo ago
  Code is written to be read, and typically for other people to read. So, in practice, it is only optional if everyone else agrees to not use it.
sdevonoes 5mo ago
It certainly makes readability of Go code harder.
- EdwardDiego 5mo ago
  If generics replace code generation or hand coding a concrete implementation for specific types or... operating against interface{} and then switching based on runtime type, then I strongly disagree that it makes reading Go code harder, it makes it, IMO, easier. But that's the thing, it's just IMO.

samber 5mo ago

OMG. I'm going to recode some of my libraries.

mackross 5mo ago

What a happy surprise today! The amount of times I’ve had to do weird janky package APIs so the API was still reasonable is more than I can count.

xena 5mo ago

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

nasretdinov 5mo ago
We already have monads at home (return X, err)
bonesss 5mo ago
A monad library in go can really on have one name… …
- oh_fiddlesticks 5mo ago
  Go nad or go home
  - digitaltrees 5mo ago
    Underrated
- zephen 5mo ago
  Mo-go?
- throwaway894345 5mo ago
  Mongo
  - WesolyKubeczek 5mo ago
    (is appalled!)
- whaleofatw2022 5mo ago
  Strife
  - uproarchat 5mo ago

thayne 5mo ago

> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently. I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against using runtime reflection is mostly that it's slow. But that runtime reflection is exactly how you would work around it today. For the Identity example, could the interface be compiled to be basically equivalent to: Identity(any) any and then at the callsite add a cast of the return type to T? I suppose primative non-pointer types add a bit of a wrinkle but even if it generic methods was restricted to pointer types, that's better than nothing. And the number of those types is relatively small, so when the implementation is compiled it could just instantiate method implementations for all the primative types, if they apply, and then maybe remove them if they aren't needed at link time. Of course it's also possible there is some detail I've missed. [1]: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...

whaleofatw2022 5mo ago
> Of course it's also possible there is some detail I've missed. Can't speak too deeply for Go specifically, but I do know on .NET one of the big reasons generic methods where T is a structure gets monomorphized per type, is so that stack size is adjusted and potentially even arg passing (i.e. large struct) as far as the caller/callee.
Merovius 5mo ago
> but the reason against using runtime reflection is mostly that it's slow. More specifically, it is that it would introduce surprising performance cliffs – code becoming surprisingly slow due to seemingly unrelated changes. Though BTQH I think an even more important argument is that you would need to have effectively two generics implementations, one working at runtime and one working at compile time. That's a lot of complexity, with surprising failure modes if these two are not bug-compatible. > But that runtime reflection is exactly how you would work around it today. I think the overwhelming majority of people will "work around it" by just not trying to use generic methods.

pjmlp 5mo ago

Go becoming a proper 21st century language, is like pulling teeth. It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere. Then the design ends up half way there versus being done properly from the beginning.

piekvorst 5mo ago
“Done properly from the beginning” means explaining why a particular feature is either included or not. In this sense, Go is done properly from the beginning. It would be wrong to add every popular feature uncritically.
- pjmlp 5mo ago
  "They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." Yeah very critically.
  - piekvorst 5mo ago
    You can’t be omniscient, I think.
    - pjmlp 5mo ago
      It is sufficient to actually care about history of programming languages design, acknowledge the paths trailed before since FORTRAN came up in 1958, no need for omnisciency. Less "we know better", more "actual history".
zerotolerance 5mo ago
Your comment could have been, "I've never agreed with the design philosophy behind Go." I've always appreciated the apparent Go design philosophy and feel like it most matches my lessons learned from 20 years in software. Feature minimalism is a feature for languages targeting organizations with thousands of programmers. If by 21st century language, you mean one that has become unrecognizable through multiple generations of fashionable feature and ecosystem thrash then I'm all for Go not becoming a 21st century language. Language should be boring if the target environment is large teams with varied skill sets. Plain speak. Low jumpy behavior. No cream, no syntactic sugar. Get the job done.

ethin 5mo ago

Watch as this gets rejected for nonsensical reasons just like the issue about adding uint128, which also has been open for an extremely long time and they keep moving the goalposts as to reasons why it can't be done...

piekvorst 5mo ago
It’s accepted.
- ethin 5mo ago
  Now there's a surprise. I've generally been very disillusioned with Go after they absolutely stonewalled everybody on uint128 (and continue to do so) for absolutely no reason (and ignoring that it would make many things in the language easier to express).
  - MrBuddyCasino 5mo ago
    > it would make many things in the language easier to express Like what?
    - ethin 5mo ago
      Like IPv6 addresses, UUIDs, the list goes on. Does it mean anything that Go themselves had to invent a custom uint128 type in the standard library because they didn't want to add it to the language? There's a very long list of instances of them stonewalling it here: https://github.com/golang/go/issues/9455 https://github.com/golang/go/issues/9455
      - MrBuddyCasino 5mo ago
        I agree with their reasoning, you don’t typically do math with a UUID, 128 bit cryptographic hashes are insecure and outdated anyway, and IPv6 is kinda valid but rare and still doable with slices.

msaher66 5mo ago

Since they can't implement interfaces, Generic methods are just syntax sugar for generic functions. I'm surprised they actually accepted this proposal for sugar.

tapirl 5mo ago
Yes, the sugar is just to make chain calls with parameter types possible. The sugar reflects the limitation of the basic of Go generics design. Now they would make the language even more complex for such a small need. In facts, there are more problems in Go generics need to be solved earlier than this: https://go101.org/generics/888-the-status-quo-of-go-custom-generics.html https://go101.org/generics/888-the-status-quo-of-go-custom-g...
- msaher66 5mo ago
  Thanks for sharing. I had no idea Go's generics had this many limitations.

klik99 5mo ago

I remember lack of generics being pitched as a feature of Go initially, not a lack. The original design goal was simplicity. I don’t use Go, so have no opinion on this, just interesting that it’s going in this direction.

matthewmc3 5mo ago
Generics being omitted wasn't pitched as a feature that I ever saw. The discussion was mostly around "hic sunt dracones" with generics. The Go authors were very aware from the get-go that generics are an incredibly difficult thing to implement well, and the commitment was always to not do it until they were really ready to tackle it. The bizarre thing to me is that when they did tackle it, they left this massive implementation gap, and then what little they did implement didn't seem useful enough that anything meaningful was added to the standard library. So all this talk about generics for years was a big nothing-burger. That is, I hope, until 1.27 when this gets released. Flags is one in particular I think is in desperate need of proper generic methods.

apatheticonion 5mo ago

I wrote Go professionally for years. I don't know how many hours I've spent debugging and reviewing nil pointer bugs and race conditions. Generics were sorely needed but the initial implementation was lacking. I moved to Rust professionally 4 years ago and haven't looked back. Mutex<T> Option<T> Result<T, Err> are all phenomenal. I've written everything from web backends, frontends (hurry up wasm, seriously), to Node.js and Python extensions. Web backends use under 1mb of memory and can support hundreds of thousands of concurrent users on a $2/m VPS. Frontends can be beautifully multithreaded. Native extensions can dance between OS threads and multi-threaded runtimes. When I review code I focus only on the logic, not sidetracked by reasoning about race conditions or anything. Great when you review the work of less experienced contributors. The ultra strict compiler is extremely helpful with LLMs. You bounce back and forth until it compiles and, if it compiles, it's usually correct. It's at the point where I can't really see a use case for another language - and yet, no one uses it! It's madness!

root-parent 5mo ago
I have nothing to add to your comment, but it matches so eerily my exact experience, that I just wonder if your alias is a second account of mine :-)
davidatbu 5mo ago
By frontend, do you mean wasm in the browser? I'd have expected multithreading there, especially in wasm, to be extremely unergonomic. Maybe you mean to refer to concurrency?

axod 5mo ago

And so the cycle will continue. Always a shame when languages cave like this and add extra unnecessary complexity and error prone hard to parse syntax. It'll be interesting to see the next language that comes along rejecting bloat in favor of simplicity, and then we can all start again.

xuanlin314 5mo ago

[flagged]