11 ms·

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At tha

• agumonkey 5y ago
  The cycles and waves in human groups is pretty weird to witness.
• vgchh 5y ago
  Well let perfect not be the enemy of the good. The reality is that Go is wildly successful in practice for good reasons that have been hashed numerous times. As a result tons of Cloud software is written in Go. There is nothing Go needs to be ashamed on. Its mindshare is a result of a good choice people made at a certain point in time. A better language will win at its own merits.
  • masklinn 5y ago
    > Well let perfect not be the enemy of the good. When you have half a dozen generic builtins but reject the idea that builtins are necessary, and can’t even be arsed to provide a working vector type, you’re nowhere near “good”.
    • LaPingvino 5y ago
      They never rejected it. In the very first post launching it they commented that they considered Generics but didn't add them because they didn't find a way that works well with Go's principles. I'm happy it took them the time it did to get to the current design. They did have a vector type before version 1 too, they intentionally removed it for similar reasons.
  • kerkeslager 5y ago
    I'm not letting perfect be the enemy of good, I'm saying Go isn't good. No language is perfect, but there's literally not a single use case I'd choose Go for, because there are a dozen languages that do almost everything better. > Its mindshare is a result of a good choice people made at a certain point in time. Its mindshare is a result of Google using it, and people mistakenly thinking that if Google uses it, it must be good.
    • saturn_vk 5y ago
      That's OK. But saying it isn't good as a fact is a bit misleading. If it wasn't any good, it would not be used and would've faded to obscurity a long time ago. That is not the case, so there must be some redeeming qualities to is
• benhoyt 5y ago
  But the fact remains that it's a productive language with excellent tooling and fast build times, and a lot of people really like working with it (myself included). I believe the reason it has gotten as far as it has without generics is because it did always have them -- but only for the built-in data types (slices, maps, channels). You just couldn't add your own until Go 1.18. I have several medium-sized Go projects that benefit hugely from generic slices and maps, but wouldn't benefit at all from user-defined generics.
  • Cthulhu_ 5y ago
    That's the main use case I think; certain specialized container data types (e.g. a linked list) will benefit from generics, but I don't see it going as crazy as e.g. Java in terms of usage. Which is something the Go team is behind as well; they added it to the language, but they aren't telling people how to use it, and are letting the community come up with use cases over time before they iterate on it.
• joshsyn 5y ago
• throwaway34241 5y ago
  I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense. The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout. Many of the design decisions make no sense without that context. Go can’t simply copy generics from Java or memory sharing from Erlang, since the design decisions made by those languages would introduce too much overhead in a language intended to be lower level. In a lower level language more aspects of how a program executes are specified explicitly, rather than accepting more overhead or guessing what a complex optimizer will do. On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++. I feel like a lot of HN commenters compare Go to higher level languages and find it lacking, which may be a fair assessment for certain problems but isn’t really understanding the niche it tries to occupy.
  • staticassertion 5y ago
    How is Go lower level than C#?
    • throwaway34241 5y ago
      I think C# might be the closest mainstream language, but I’d say explicit pointers, interior pointers, and slices as the default list type might be things that make Go programming a little lower level. There are also other differences that would prevent using C#’s system as is - Go doesn’t have the reference/value type dichotomy or inheritance. I think they also wanted to be able to abstract across float/doubles etc (unless C# added that recently). Anyway I like both languages and I’m not trying claim one is better than the other, just trying to explain the design space Go seems to occupy.
      • pjmlp 5y ago
        Never used unsafe and raw pointers in C#? They exist since version 1.0. Never used ArraySegments in C#? They exist since version 2.0 Abtracting over float/doubles is called generics.
• throwaway894345 5y ago
  > Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It's a shame that this language has stolen so much mind share from more deserving languages. Go steals the mindshare because it focuses on the important problems that other languages neglect in part or in full: performance, tooling, ecosystem, simplicity, readability, learning curve, etc. Much important software has been built in fully dynamic languages (never mind a 99% type-safe language like Go), but it’s a lot harder to build in a language that lacks important libraries or is prohibitively slow or for whom it is hard to find/train developers, or whose tooling is poor, or which is difficult to read/maintain, or etc. So yes, Go is now looking at generics because it’s tackled the more important problems. Not because it was the most important problem and the developers were just too stupid to understand.
  • ctopher7 5y ago
    • dgb23 5y ago
      I‘m sure there are better reasons for people liking Go other than what you described. This reads like a general dismissal.
      • Guthur 5y ago
        Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem
        • masklinn 5y ago
          > But that could be added to pretty much any language ecosystem Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice. Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.
• omginternets 5y ago
  Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.
  • valenterry 5y ago
    I think OP didn't even start using go in practice, so the question doesn't help. But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.
    • omginternets 5y ago
      That's fair, except that I routinely program in: - Go - OCaml - Python - Lisp I think I have a reasonably good sense of what each language offers and what it does not. But OP goes beyond saying "Go does not offer some features that other languages offer"; he effectively says that the language causes severe problems. Where are they?
      • valenterry 5y ago
        "severe" is certainly subjective, so you might disagree. From my perspective, none of the languages you listed allows for good error handling. But that is obviously only my perspective. I would call this a "severe" issue. In fact, all languages that k I know have at least one "severe" issue.
    • masklinn 5y ago
      This actually has a name in programming circles: the blub paradox. I guess in natural langages this would be the sapir-whorf hypothesis. Blub seems like a much stronger effect though, at least anecdotally. But that might be because natural languages are rarely compared in terms of features / capabilities, and even more rarely “ranked” along various such axis.
• mikojan 5y ago
  > Every few years someone gets me to try Go out again and I discover, yet again, that it's still struggling with problems that were solved before it existed. It is not Go that is struggling. It is you. Does literally every language have to turn into Java?
• BatteryMountain 5y ago
  C# generics are delicious. Combined with the strong compiler and super good reflection features, you can do very well indeed with it.
  • socialdemocrat 5y ago
    Nah… if so was embracing C# style complexity I would rather do Swift of Rust. At least they have a clean solution for fixing the million-dollar-mistake. My chief attraction to Go is simplicity. I can be away from Go for years and pick it up again really fast. With simplicity, you naturally need to make some sacrifices, but I think Go team has been diligent about choosing those.
    • kerkeslager 5y ago
      > Nah… if so was embracing C# style complexity I would rather do Swift of Rust. Just so we're clear here, you're using the word "complexity" to describe the situation of not having to copy paste or `go generate` 30 different implementations of the same class for different types because your language lacks generics.
• tsss 5y ago
  • valenterry 5y ago
    It in fact reminds a bit of Angular. I'm expecting a similar revamp of Go at some point - it will share the same name but otherwise won't have to do anything with the original.
  • pjmlp 5y ago
    Sometimes I wish that the Go advocates had not joined Kubernetes project and triggered the rewrite of the prototype from Java into Go.
  • ilovecaching 5y ago
    Considering it was written by a Turing award winner and other members of Bell Labs and Google, who not only shaped modern day computing but have been doing so for the literal 50 years you referenced, maybe you should consider that the reason that Go is popular and used in many settings is because it's good, and you're the one who is A) suffering from a bad case of Dunning–Kruger B) Have yet to learn the lessons that informed Go's feature set and philosophy. Or it could just be that everyone else is wrong. Who knows.
    • dogleash 5y ago
      "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike
      • mnk47 5y ago
        How many times is this gonna get reposted as some sort of gotcha? He's right, and having to deal with juniors or large teams with varying competence isn't unique to Google. I've met many devs who praise Java for how simple it is to parse through for people of all experience levels (once you get used to the verbosity). In fact, two of Java's founding principles was that it had to be simple and familiar. Yet I don't see anyone pretending that's a bad thing. Go has the same goals, just a different approach. Java is too verbose, Go takes the simplicity approach too far sometimes. Neither are perfect but they're definitely useful and worth considering for many projects. The fact that it was made with juniors in mind is a plus.
• simias 5y ago
  I also couldn't help gloat a bit thinking about all these bad faith arguments I heard coming from the Go community over the years about how the lack of generics was not such a bit deal and generics sucked anyway. I especially remember one particular document where some Go devs claimed to make an "unbiased" study of the pros and cons of generics and it was ridiculously one sided (if somebody remembers what this document was I'd love to read it again, especially now that Go has generics). That being said I'm happy to see that Go now attempts to find a tradeoff between generics and compile time, if their approach proves successful hopefully it could lead to improvements for other languages as well.
  • foldr 5y ago
    Does it help to make such vague references to bad faith arguments? If you want to point to something specific that someone said, then fine, but otherwise it seems like you're just stirring up discord. No programming language is loved only by rhetorical geniuses. Of course you can find some people who've said some silly things about Go or generics. But so what? You can also find people who've said silly things about your favourite programming language.
    • kerkeslager 5y ago
      > Does it help to make such vague references to bad faith arguments? If you want to point to something specific that someone said, then fine, but otherwise it seems like you're just stirring up discord. Sorry, but anyone who's been watching Go's development long enough remembers this: it's not being made up. Dischord is good if the alternative is consensus around a backwards language that wastes huge amounts of people's time and money. > Of course you can find some people who've said some silly things about Go or generics. But so what? You can also find people who've said silly things about your favourite programming language. The problem being that in the case of Go, the people saying silly things are the primary developers of the language.
      • foldr 5y ago
        Again, you're just saying that a bunch of people said some unspecified silly things. It's difficult to take that seriously as a critique of Go or any of the people involved in designing it.
• Ginden 5y ago
  > At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. I'm not sure why certain things generate such fanatical community. Eg. I remember arguing with iOS developer in my first work that smartphones bigger than 4.7" are useful. He claimed they aren't and Apple, as company focused on best experience of user, will never ever produce bigger smartphone, because it's totally useless.
• neilwilson 5y ago
  I've had a play around with Go generics, and from what I can tell it boils down to passing the type parameter down the chain, from the concrete to the general, to the point where a function needs to create a structure, and then returning that structure back up again, modifying the structure with functions and methods as you go. Rather than creating the structure and passing it down the chain to be modified via typecasts as previously. Pretty much everything else ends up being limited by interface types being unable to reference structure attributes directly, but requiring method signatures. So it becomes more complicated to reference all types that have an 'ID' attribute for example. With some types I ended up with so many getter and setter functions to enable generics, that it was better to revert back to 'go generate'. Perhaps it works better with pure container types that can take 'any'.
• LaPingvino 5y ago
  Generics were considered at the very release. Go just focuses on getting it right. And I love it for it, because to this day Go is the only language that got OOP right, and now Generics. Go is a language made for the human factor. Go generate by the way is mostly NOT used for generics. Check for example Vugu, which compiles UI documents to pure Go code. Go generate is made to incorporate any random external tool without making it complicated for the humans using it. And it makes sense because the goal was not single pass compilation, it was single pass parsing, which is exactly WHY Go generate is useful. It is still true to the exact way this has been defined. Go is simple in ways that matter.