19 ms·

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser

• _wldu 5y ago
  I agree about placating. Go is fine as it is. I don't need or want generics, but the addition of generics won't stop me from using Go.
  • silisili 5y ago
    It might me, in time. As mentioned, my main interest in Go is in how easily I can read others code. This kinda ruins that, even if I never use it.
    • tengbretson 5y ago
      Learning something is also an option.
      • silisili 5y ago
        Thank you.
      • jshen 5y ago
        Learning things outside of complex computer science topics often adds more value to the world. The ability to write useful programs without dedicating ones life to esoteric comp sci topics is a net positive for the world.
        • rustc 5y ago
          Are generics really considered as "esoteric comp sci topics"?
          • jshen 5y ago
            If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.
            • jagger27 5y ago
              I’m not sure Go has ever been a great language for non-CS people, but it’s been a very long time since I was new to programming. Go is pretty clearly a “get shit done” language catered to developers: a productivity tool. Why should it have its capabilities restricted? English is used in both reality TV shows and scientific journals. The vocabulary used in the latter doesn’t prevent it from being useful in the former. Go will still be usable the exact same way it is today after generics are brought in. It’s not like all the existing more approachable code written without generics won’t just disappear overnight. That said, I agree with GP. Generics aren’t that complex anyway.
            • c-cube 5y ago
              If people can understand functions, they can understand generics. Nothing more complicated, generics are just functions on a few type arguments.
              • jshen 5y ago
                Here’s an example from this very thread that shows how complex generics get relatively quickly. https://news.ycombinator.com/item?id=28255738 https://news.ycombinator.com/item?id=28255738
                • jagger27 5y ago
                  That example is essentially the most basic use of generics. There are much more complex examples that would support your argument better. What do you find confusing about that code?
  • dmitriid 5y ago
    > I don't need or want generics I do need and want generics. So... Whose needs and wants are more important?
    • silisili 5y ago
      Neither, of course. I'll leave so you can join. I don't think either of us is wrong.
      • AnimalMuppet 5y ago
        You sound like, for you personally, generics are like a poison atmosphere. You simply can't live in that environment. Why? Why so negative? I work in C++. Generics exist there. I don't use them except for some STL containers. I just... don't use them. I don't have problems where I need them. How does it hurt me if they exist? You may say that someone else will use them, and make your code more unreadable. They may, but... if they really help the code base, use them. If they don't and someone uses them anyway, teach them some taste and discernment. If they can't learn, then you've got worse problems than a language that has generics. If it's borderline, but against your personal taste, then yeah, you're kind of out of luck. On the other hand, personal taste changes over time, often from experiencing new things. You could try it for a while, and see how it goes...
        • silisili 5y ago
          I don't mean to be negative only, and appreciate your reply. But I know what happens in real codebases. Before long, scammy tutorials pop up showing Go as an essentially dynamic language, and that's what bootcampers write. As of today, they are forced to write simple, boring code. I never mind a carefully added thing, for carefully thought of situations, as this probably was. The problem is that I see the abuse from here. And even if not abuse, it changes how you approach problems. And approaches matter as much or more then spec. I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of reason would say...what are you doing? That's not how you do it in Go. Readability goes beyond the syntax. It's a mindset. And now it's not.
  • mountainriver 5y ago
    I didn’t need generics till I wrote a mathematical library, and wow they would be handy
    • _wldu 5y ago
      I've used templates in C++ to do that and I agree that it is handy. I had to write far fewer functions than I would have without them. Sometimes, it's nice to not care or worry about how many bits are in a number.
• puddingforears 5y ago
  How would you write a singly linked list who’s contents are arbitrary? What if you were to map a function over it? Say you want to use this data structure with third-party objects? How do you do that right now?
  • Taek 5y ago
    Find a different way to solve the problem. I've written close to half a million lines of code in Go and the lack of generics has been a pain point in maybe 1% of that? Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be. If you really need generic structures you can use the interface type but generally there's a simpler solution that doesn't require generics.
    • tengbretson 5y ago
      Maybe you could have gotten that work done with fewer than 500,000 loc if you used a language with a better feature set.
      • jshen 5y ago
        And it would have been far harder to read for those new to the generic code base. Complex abstractions make people feel smart, they rarely make code easier to understand or maintain.
        • aptenoforst 5y ago
          How is a generic data structure a COMPLEX ABSTRACTION?
          • jshen 5y ago
            They are complex. I’m guessing you haven’t thought about them much beyond the trivial use cases.
            • 5y ago
• buu700 5y ago
  I personally think this will be a great thing for the quality of the language (no typed higher-order functions is a massive pain point as-is), but at the same time one could argue that this is an equally massive bait-and-switch for all the developers who prefer Go's original take on "simplicity".
  • pm90 5y ago
    Go is still pretty “simple”. They didn’t introduce a while loop. Adding generics would arguably “simplify” the language even further since you would presumably throw away a lot of duplicated code.
    • mseepgood 5y ago
      They can simplify code, but they don't simplify the language.
      • masklinn 5y ago
        The langage which already had generics except special-cased to builtins the langage authors really wanted to be generic and they know better than the peons so they have the intellectual capacity to make this determination?
        • mseepgood 5y ago
          you sound bitter
          • masklinn 5y ago
            I'm just believing what Rob Pike told me about his target users for Go.
    • Zababa 5y ago
      > Go is still pretty “simple”. They didn’t introduce a while loop. What are you talking about? There is already a while loop, it's just under a different name. I don't think reusing keywords for other purposes is an example of simplicity.
• aptenoforst 5y ago
  If anything generics will make go code simpler. No more copy pasting everywhere and the possibility of making useful collection methods like map, filter and reduce.
  • barsonme 5y ago
    More concise, yes. Simpler? Maybe[0]. And for the record, I'm mostly in favor of adding generics to Go. [0]: https://talks.golang.org/2015/simplicity-is-complicated.slide https://talks.golang.org/2015/simplicity-is-complicated.slid...
    • sascha_sl 5y ago
      It also depends on your use case. Kubernetes and its pile of code generators will be much much simpler.
• nerdwaller 5y ago
  I fully agree, after writing go for the last 7 years. I recognize that generics solve some problems, but there’s a cost in doing so. In that period I’ve had only a few cases where I wish I was back in a language with this feature (Java being my previous typed language), however most of the time the interface with an application specific data model was more than sufficient. Obviously you need to wrap that abstraction for typesafe code, but that’s pretty trivial.
  • vorpalhex 5y ago
    Without generics, I have seen terrible and unreadable golang code. There is no tool that can not be mis-used. Generics are adding a tool to the toolbox. They can be used well or they can be mis-used. I recently wrote a gui app in Golang using Fyne and I really wish I'd had generics for some of the UI handling - instead I ended up having to write some really ugly and not simple code to handle the case. The end result was worse and less-simple than if I had been able to use generics.
    • jshen 5y ago
      Can you give an example of terrible unreadable go code due to a lack of generics? I’ve grown to love go because it’s one of the few languages where I can jump into a new code base and relatively easily understand what is going on.
      • kmm01 5y ago
        Because you will already have seen that precise piece of code in a thousand other contexts?
      • dmitriid 5y ago
        > Can you give an example of terrible unreadable go code due to a lack of generic https://news.ycombinator.com/item?id=28254411 https://news.ycombinator.com/item?id=28254411 The "solution" to this is copy-pasted boilerplate code with casting for every call.
    • theshrike79 5y ago
• bogota 5y ago
  If i wanted or needed generics i would use another language. I have been able to write great code without them for 5 years now though. But now i get to defend my codebases from the unneeded introduction of them from largely developers who think they are too smart.
  • silisili 5y ago
    Same here. But I think it's more laziness than 'too smart.' I like to liken it to house construction. Imagine if a number of people demanded that natural gas and water be combined. Why do I have to make two separate pipes? They even look the same!
    • jolux 5y ago
      There are just things you can’t do without having generics in your language. User-defined collections, for one. Statically typed higher order functions, for another. To paraphrase (I believe) Bob Harper, you either have a statically typed language with generics, or you have a dynamically typed language. That’s the result of not having generics. Code that needs them becomes more dangerous and error-prone.
  • takeda 5y ago
    You can totally do fine without generics depending what you do. It mostly affects code that supposed to be reusable, especially libraries.
  • lamontcg 5y ago
    you sound like you're too smart for generics.
    • bogota 5y ago
      No I’m likely too dumb for them but my code base is clean and easy to onboard people to. I take great pride in new hires telling me something is easy to do after only working in it a week And like i said generics have a place its just a way smaller place than many people think
• infogulch 5y ago
  I can sympathize with this concern; constraints can force authors to just write simpler code which has some very nice benefits. But that leaves out some legitimate use cases like collections that were terribly served by genericless-go. Yes there will be some pockets of libraries where authors take generics to an extreme. Besides being a bit of fun, it's good to explore the edges of what you can do with the language, so this exercise will be valuable even if you don't use them regularly in your projects. But I don't really see pervasive gratuitous use of generics becoming a big problem for the average lib, Go devs tend to lean practical on potentially abused features like this, and there will be many users like yourself that will still prefer simpler interfaces. I guess we'll see over time. Really, Go's lack of generics for so long wasn't an ethos (despite many taking it that way) but more that the right implementation just hadn't revealed itself yet. I think the one they chose is a pretty good match for Go, and I hope that it makes Go more complete.
• flippinburgers 5y ago
  I agree with you strongly. No generics please. It is already hard enough to try to steer a group of developers towards a shared vision without giving them the ability to show off how "smart" they are. Abstractions in libraries? Ok maybe. In the higher level code that the vast majority of programmers actually write? No. Thank. You. Besides, interfaces cover the majority of generic problems on the ground.
  • mikepurvis 5y ago
    Isn't that a fairly easy policy to enforce, though? Basically you blanket ban them in your linter, and only create exceptions for specific cases like containers, parsers, situations where it saves you a cast, whatever. I know that doesn't help you when you have to interact with the larger Go ecosystem on Github, but at least within an org, it shouldn't be terrible. Certainly the culture of golang is well established— millions of lines of it have been written generic-free, so I'd expect that it will only be applied where it really is an obvious improvement.
• lokedhs 5y ago
  Back when generics were introduced to Java I felt the same thing. I had been doing Java for years at that time. I had also been working for Sun, so of course I was exposed to it. I was very negative towards generics and had similar arguments as you. It didn't take long before I changed my mind. I'd never want to write Java without generics again. I'm not saying you're going to have the same experience, but I would suggest you give it a try before dismissing its value.
  • silisili 5y ago
    Thanks for your experience, really. Here's hoping.
  • pkulak 5y ago
    Does Go generics have type erasure? If not, OP can expect and even better journey.
    • mseepgood 5y ago
      No, they don't have type erasure.
      • erik_seaberg 5y ago
        Go is getting monomorphization, separate machine code for each type specialization of a generic function. I assume reflection will choose the one for the args you want to pass, or make you do that.
        • masklinn 5y ago
          > I assume reflection will choose the one for the args you want to pass, or make you do that. According to the spec: > It's impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions. You won't be able to reflect a generic List or List[T] at all which… makes sense, I think? `reflect` works on values at runtime, so it necessarily works with instantiated types as you can't have a value of an un-instantiated (generic) type: what would you give to `reflect.TypeOf` which could return an uninstantiated generic type?
• moth-fuzz 5y ago
  I agree. I feel like generics make more sense in a language like Rust or D or C++ (templates) where you need the performance of compile-time constructs, and generics specifically have that semantic. In Go, it doesn't make as much sense to not simply use an interface for the same purpose since the language is less bare-metal (or, rather, implementation-specific) by design.
  • int_19h 5y ago
    It's not just about performance, or really not so much about performance - e.g. when Java added generics, they didn't make it any faster than it used to be when you had to use Object everywhere. It's about type safety - i.e. catching bugs earlier and more reliably. Every time you have to write an explicit downcast, you are throwing away the benefits of using a statically typed language in the first place. Which is fine, but then why stop halfway, and not just go full dynamic? It doesn't really make sense to have strong typing for scalars but not for collections.
• anothernewdude 5y ago
  No generics, and lack of error handling are why I bounced off Go. Can I write a generic data structure? No. You have to cast from interface{}. Java 1.4.2 is dead, and rightly so. And manual error checking? No. Get that garbage out of my control flow. I'm not going to a language that has worse error handling than C. At least in C you can factor it out.
  • Gibbon1 5y ago
    Writing stuff in C... one thing I would like is an error return keyword. And the ability to set how you'd like unhanded errors to be dealt with. Like unhanded error means program aborts. Let the programmer decide how sloppy he wants to be.
• kbenson 5y ago
  Either a language changes to keep interest up and bring in a new audience, or it's left behind by advances to and the status quo (and what's considered a minimum set of features) and stagnates. Just look at Perl. Stuff written 20 years ago is likely to work without change on the newest release more often than not. For certain work contexts, like system utilities and long life core programs, this can be amazingly useful. And all it will cost you is the slow decay of your community until eventually they're almost all gone, and nobody releases supported libraries for you anymore, and there's not even enough community left to provide community support for many new services and technologies. If you stick around one thing long enough you're destined to be disappointed one way or the other.
  • adamlett 5y ago
    C
    • kbenson 5y ago
      C is only used because it has a widely deployed set of libraries and by it's nature as an underpinning of most foundational software because it was the language of choice when we really started hitting exponential growth in computing. If there wasn't an enormous set of software and source code out there for it already, would there be any reason to use it over anything else? And even then it's latest language standard update was in 2018. You still have to deal with the fact it's changing and keep up with it if you plan to read or use others code. And of you don't, then you can safely not care about advances in C, just as you can safely not care about changes in Go.
    • tephra 5y ago
      C11 introduced type generic expressions.
      • c-cube 5y ago
        Not in the commonly understood sense of "generics", no. You get to switch on a type, but you don't have generic functions or types. A reusable, type-safe Vec or HashMap are still not possible in C...