16 ms·

Honest question: Do you think Generics will be an overall win for the Go language, or will they be overused / end up making code harder to read / harder reason

• marcosdumay 5y ago
  Hum, I've never seen generics making code harder to reason about in any language, except, of course for C++, where they are hacked over text. If they will make code harder to read, that's up to syntax. I don't know how all that will look up on the end, but it should be reasonably easy to just write an example.
  • spinny 5y ago
    > Hum, I've never seen generics making code harder to reason about in any language, except, of course for C++, where they are hacked over text. do you mean templates? i was under the impression that c++ generics == templates, but after a google search found out that c++ has both (at least according to microsoft), not surprised https://docs.microsoft.com/en-us/cpp/extensions/generics-and-templates-visual-cpp?view=msvc-170 https://docs.microsoft.com/en-us/cpp/extensions/generics-and...
    • tsimionescu 5y ago
      C++/CLI is C++ compiled to NET CLR IL, so it has all the features of the regular C++ compiler (templates) AND all the features of the CLR (generics). It is an extremely niche language, extremely rarely used even in the .NET ecosystem, except sometimes as glue code. Normal C++, including MSVC C++, has only templates.
      • pjmlp 5y ago
        It is definitely nicer than trying to correctly get P/Invoke declarations or debug COM marshaling issues. This is the kind of tooling that makes me still reach out for C++ when going outside managed languages.
        • tsimionescu 5y ago
          My experience was that P/Invoke is much easier, but of course YMMV. COM I never played around with. I also found a pretty ugly bug in the C++/CLR compiler - if you used in-place initialization for an array (something like auto arr = Object[]{obj1}), it would allocate an array of length 0xC0FFEE and set the elements you specified. They acknowledged the bug but said they will only fix it in a future version of the language. This told me all I needed to know about how popular it actually was.
          • pjmlp 5y ago
            It is popular enough for being one of the major milestones on .NET Core 3.1. P/Invoke can only do so much if a C++ library doesn't provide a C ABI, and WinDev loves to publish COM based APIs since they won the Longhorn dispute.
    • marcosdumay 5y ago
      Yes, generics in C++ are created with templates.
• nynx 5y ago
  I'm certainly not a fan of Go, but I suspect generics will result in the language and ecosystem getting better. I'm not personally a fan of the go generics syntax because I find braces and parentheses to be visually similar, but I'm sure that would go away if I used it more. I'd go for Rust tbh. I think it's a much more coherent language.
  • spinny 5y ago
    Wrote Go code daily for quite some time, also tried Rust. I like Go because of the tooling and simplicity of the language, it's easy to learn and explain. Rust has the borrow checker has a corner stone. The concept mutability and references is easier to understand if you are coming from the c/c++ side of things
• deleted 5y ago
  [deleted]
• crehn 5y ago
  I'm concerned about two things (that I hope I'm wrong about): (1) developers will overuse generics and use poor types or `any` where not necessary, and (2) this marks the beginning of Go's convergence to yet another language with a million choices for abstractions and a million ways to misuse its features.
  • grey-area 5y ago
    I think they did this really quite elegantly by extending the interfaces abstraction. Personally I would discourage overuse of generics in an application codebase as I’d discourage overuse of interfaces, concurrency or channels - they have their place in certain areas (for generics e.g. collections, orms - mostly in library code) but most of the time simply aren’t required.
• ppeetteerr 5y ago
  Not a Go programmer but I can say that Generics were important for me to consider adoption of Go. Now that they are present, it's a legitimate language. Whether they make code messy really depends on how they are being used.
  • choeger 5y ago
    > Now that they are present, it's a legitimate language. I second that sentiment, but I would have to look into the specifics. Generics ala Java aren't really that attractive when Rust mainstreams ML-style polymorphism with Haskell-style overloading.
  • spion 5y ago
    What about `if err return err` everywhere?
    • johnisgood 5y ago
      I like them personally. It is easy to ignore them, and if you want them, they are there.
  • deleted 5y ago
    [deleted]
  • 62951413 5y ago
    I'd wait until we see how the updated standard library looks like. In Java they had to invent Streams. Scala/Kotlin didn't repeat that mistake and so their collection APIs are more natural to work with. Historically golang has repeated most Java mistakes so I don't hold my breadth. On the positive side, now Either/Try-like composable types are possible. So even if they insist on not having exceptions they could clean up error processing.
    • Ericson2314 5y ago
      Go is nothing but Java repeated, as farce.
  • 5y ago
• 13415 5y ago
  In my opinion, there are plenty of good alternatives to Go such as Nim, or Python if performance allows, and even languages like Zig, V, CommonLisp, and D depending on the use case. I don't get why people keep mentioning Rust in threads about Go. It's perhaps a replacement for C, C++ and Ada - though for the latter only if you're okay with switching from self-documenting code to unreadable gibberish. Rust's philosophy is pretty much the opposite of that of Go, and it is neither designed nor suitable as a high productivity, easy to use language. IMHO Go generics are simple and useful, particularly for container libraries. They are fairly readable, unlike template programming and macros in other languages. Together with the any type alias for interface{} they will make code more readable. I do hope that Go stays at version 1, though, or that it at least takes a long time to add new substantial features and get version 2. Slow change is one of the many advantages of Go and I'd rather see them improve the compiler in hidden ways.
• spinny 5y ago
  While generics are definitely useful to implement container types, it seems that the Go design seems to prevent that. It seems to me that generics get overused when the language allows you operator overloading for example. Go is a "one way to do thing X" language, it doesn't give much room to write "creative" code
• cloudfifty 5y ago
  I'm not so sure it will be an overall win. Will it be nice with generics for carefully crafted and cherry-picked use-cases? Absolutely. Will it make the average large codebase less readable after a dozen coders have been doing their own cleverness with generics 3-5 years down the line? In my experience, most definitely. Of those two, I'm much more afraid of working with the latter than missing out on the former. It sometimes feel like we as devs have a habit of optimizing for the individual dev's convenience (not to mention what's fun) rather than for the collective effort's best interest - like the long-term maintainability/coherency of the code base. To some extent I assume that's just being human, but in other professions I think it would be seen as a bit lazy and thus more stigmatized.
• fiedzia 5y ago
  > Is it a better bet to move on and go full Rust, rather than bother with wherever the goggle golang train is headed? Ecosystem aside, with Rust you'll get far better language design (generics fully integrated with everything (stdlib, consts, all libraries), sane error handling, sane dependency management, no "any" type, editions, and more. More complexity too though. > Certainly some problems will benefit from the addition of generics, but is it really enough to justify the added complexity? Coming from languages that have them, it's just hard to take Golang seriously, where every library either ditches type safety (more runtime errors I wouldn't have with other language), or forces you to copy-paste code just because you need support for some new type (more boilerplate to maintain == more errors). Or reinvents generics with code generation and aboriginal characters. Once you start using generics, they really aren't complex.
  • LanceH 5y ago
    > Coming from languages that have them, it's just hard to take Golang seriously Some people judge the language on their ability to get work done with it. I get generics, but they really don't come up in daily use with the tasks where I use Go. Yes, it would be nice for writing some libraries but you're going through a laundry list of Rust features which don't hamper my ability to get work done at all. I even like Rust, but if I'm going to write a worker that will read from a queue, do a transformation and write to a few more queues/services upon completion, Go just works and the turn around time is far better than Rust. It's like was Perl was for Unix, but for the cloud instead.
    • choeger 5y ago
      > Some people judge the language on their ability to get work done with it. Really? Safety and correctness aren't relevant for you? Then why even bother with go instead of Python or a Lisp? For me it's crucial that a programming language contains tools that allow me to definitely rule out as many errors as possible. A powerful (and sound) typesystem does just that.
      • cloudfifty 5y ago
• cogman10 5y ago
  > Do you think Generics will be an overall win for the Go language, or will they be overused / end up making code harder to read / harder reason about? Here's my $0.02 from a java background. There will be cases where someone overuses generics. That happen pretty much every time a new language feature lands in any language. However, my expectation is that like java, you will see Go generics in general practice only come up when dealing with things like collections. Once the community settles and stops trying to use generics as a meta-programming language, they will become pretty boring (which is what you want). From a readability standpoint, IMO, generics in Java don't really have a negative impact on readability. Sure, you'll get the random `Map<Map<String, Object>, Object>`... but most people see that as the anti-pattern it is. In short, I'm guessing they'll be a win.
  • Groxx 5y ago
    yeah - generics can get fairly complex for library authors that want to be maximally flexible (which is optional!), but the end result generally tends to be a library that users can use correctly by accident, without needing to understand generics in depth. It's that "correct by accident" part that's hard to have both safe and performant without generics.
• fizx 5y ago
  I use Go because it compiles quickly, the GC is reasonable, the ecosystem is good enough, and it's not rocket science (Scala/Rust/etc). While generics moves Go in the direction of rocket science, it feels like this is solving a problem I always have.
• rackjack 5y ago
  Every language feature gets misused in some way, but if it is overwhelmingly used to clarify and reduce code, I think it is a win. I believe generics will overwhelmingly be used to do this, so I think they are a win. I doubt more complex features than this will be added, considering how long it took to get generics. Rust is a very different language from Go, though it can do similar things. If you have people willing to learn it, you can certainly try, though you might find the ecosystem lacking.
• mseepgood 5y ago
  > Is it a better bet to move on and go full Rust If you don't like generics you shouldn't use Rust. You can't escape them in Rust. The designers repeated the mistake of C++ and made it a language feature kitchen sink. It's an unholy mess. You'll find yourself constantly fighting the borrow checker. Type signatures are littered with lifetime annotations. The type system is Turing complete because they didn't analyze it before implementing it. Go's generics were formally validated [1]. Rust's compile time is slow, and the 'async' story is sad. Async functions are colored and infect everything. [1] https://arxiv.org/pdf/2005.11710.pdf https://arxiv.org/pdf/2005.11710.pdf
  • deleted 5y ago
    [deleted]
  • opnitro 5y ago
    A type system being turing complete really isn't a problem. You bound the recursion depth in practice, and the chance of a real world programming hitting that limit is minuscule. Lot's of other languages have turing complete type systems, subtyping and typeclasses lead towards it.
    • mseepgood 5y ago
      Sure, if you regularly want to increase your #![recursion_limit] or #![type_length_limit] for the next generation of type bloat.
    • socialdemocrat 5y ago
      Hmmm I guess it is all in the eye of the beholder. If you are the kind of person who thinks C++ went wrong with its template system, then you might find issue with any language emulating C++ failures. If you think C++ is a beautiful well deigned language, then I am sure you will not have issues with Rust either.
      • opnitro 5y ago
        Java & Haskell both have turing complete type systems as well. I'm not a particular fan of C++'s type system, doesn't mean have metaprogramming features is bad.
• radlad 5y ago
  As someone who's been writing Go full-time for only about 8 months now, I've repeatedly been frustrated with the lack of generics while building web APIs. For example, the Go GraphQL ecosystem is a bit of a disaster full of type unsafe code and use of reflection or code generation to support simple things like "a resolver that returns FooResult" vs. "a resolver that returns BarResult." Here's a fun one I stumbled on: How do you implement a PUT endpoint where a missing JSON value is treated different than a null JSON value? This ends up being very difficult and requires a boilerplate wrapper type for every single type you might accept. It's even worse when you start accepting slices or maps, or slices of maps... These are areas where generics will help me a lot.
  • masklinn 5y ago
    > How do you implement a PUT endpoint where a missing JSON value is treated different than a null JSON value? Tbf that’s a pain in the ass everywhere unless you’re reifying it as a map (so manipulating a json dom). Iirc in rust the “complete” way to do this for a struct (as opposed to a map) with serde require two options and a bespoke deserializer.
    • radlad 5y ago
      It's much easier to do in dynamically typed languages or by using maps - agreed. Unfortunately we have other design decisions that force us into using structs for deserialization on this endpoint (part of our validation strategy.) The Go answer is a struct that contains an IsDefined boolean (i.e. your first option), and a pointer-to-value (i.e. your second option.) This is fine if you need it, but having to write this same logic over and over again for every type gets old... especially if your validators are tied to your types (i.e. a type per field.)
      • masklinn 5y ago
        > Unfortunately we have other design decisions that force us into using structs for deserialization on this endpoint (part of our validation strategy.) Oh I’m not blaming you, sorry if it came across that way. I’m aware of the issue because i’ve been hit by the exact same (hence having been made aware of the rust workaround), can’t say I was a happy camper.
• cube2222 5y ago
  I share your worries, but I think it will be just fine. There are two reasons I have for that: First, the Go community mainly comprises people who love simplicity and got accustomed to it. I imagine most people who want to go overboard with generics will stay with languages that let them go way more overboard. Second, and more importantly, there's no method parameterization, which saves us from monadland.
• ur-whale 5y ago
  > What previously was elegant and easy on the eyes is now annoying and muddled by the additional layer of abstraction You're just getting old is all. What was once familiar now isn't ... how annoying. If that worries you, don't: we're all walking down that path. Give it a couple of decades and everything in your life will feel like that.
• jjice 5y ago
  I hope that this quote from the article is true: > I’m not sure that most Go developers will be using generics daily, but it’s nice to know that they exist if we need them. Most people won't need generics in Go, and I hope people don't force them into their code where an interface would do just fine. I'm a big fan of good type systems like Rust, but Go doesn't need all that power all over the place. I think generics are a good feature for Go, but I really hope they don't get overused in places that would currently use an interface.
• zemo 5y ago
  having played with generics over the past few weeks: my guess is that there will be a period of widespread misuse, the first six months or so after 1.18 is released. So... between February and August of next year I'm expecting a lot of the Go discourse to be characterized by a very poor signal to noise ratio. I think there's virtually no chance that Go 1.18 will come out and people will use generics well; people will use generics poorly before they use them well. A bunch of people will write libraries that utilize generics in some way that's not very orthogonal to the rest of the Go ecosystem. They'll put these libraries out as quickly as possible, because they want a first-mover advantage in picking up adoption. A handful of people will take their time and learn how to utilize generics in a way that is native to Go. Eventually those people come out of the woodwork, and it turns out that utilizing generics in Go looks different than it looked in some other language, so a lot of the early assumptions about how to use them were wrong. A bunch of those early libraries turned out to be badly designed once actually deployed into the real world, so they fade out of use as their problem domains get written by newer libraries that utilize generics in a manner more orthogonal to the rest of the Go ecosystem. A few of those libraries picked up significant market share, and maybe a startup has shipped stuff that generates revenue with those libraries, so they fund those projects, which continue to exist as a result of pure inertia. So now you have some big libraries written in like ... March of 2022, which are just bad, but people keep promoting them because they have a vested interest in doing so, but the ecosystem at large moves on, and by late 2022, generics will fit in very nicely with Go and not complicate things in an unnatural way. I'm wary of what's coming in the short term, but optimistic of what's coming in the long term as a result of this change.
• horsemans 5y ago
  I have never needed generics in Go, and I've probably been using it since 2017. I've never even once had to resort to any interface{} trickery to express what I want, and I've written Go programs for Fortune 50 companies, as well as complex personal projects such as AST parsers/code generators. I'm pretty disappointed to see generics introduced into the language and every example I've seen feels completely unreadable to me compared to pre-generics implementations. To be clear, it has never been the case that the Golang authors were 100% against generics. It has always been their position that the implementation needed to be good enough to make the trade-offs worthwhile. I just don't think they chose the right trade-offs.
  • qaq 5y ago
    never needed min/max ?
    • horsemans 5y ago
      Would you use generics to write the same implementation of min/max for integers and floats?
      • grey-area 5y ago
        You certainly might use them to write a facade which made life easier for consumers of the math pkg and accept floats,ints or uints even if behind the scenes it splits into different implementations.
        • horsemans 5y ago
          I would not be very happy if every time I called math.Min, I was also, under the hood, calling reflect.TypeOf.
          • danachow 5y ago
            The whole point of generics is to avoid this - why do you think you would have to use reflection?
• amelius 5y ago
  > Is it a better bet to move on and go full Rust, rather than bother with wherever the goggle golang train is headed? If you want to unnecessarily encumber your mind with trivial but tedious memory management puzzles, then choose Rust.
• AtNightWeCode 5y ago
  I have never felt the need for generics but many of my friends complains about the lack of it in Go. The syntax seems to be as readable as any other lang with it. Go is fairly dominant in some areas and Rust is not really a realistic replacement today. Generics will not change that.
• xh-dude 5y ago
  My hunch is that Go packages will still work fairly well for isolating gory details. The guts of a package can get more complicated with generics but there is friction for consuming anything more clever than, like, ‘lists.NewLinkedList[myType]’ outside; further, the path towards cleverer and gorier cross-package APIs mostly goes through interfaces. In this way, underneath some new syntax, the concepts employed when using polymorphic type parameters largely resemble the status quo for dynamic dispatch.
• comeonseriously 5y ago
  > I kind of hate looking at Go code containing generics. Pretty much any mainstream language that supports generics is shit to read. (And I love to read code.)
• coldtea 5y ago
  >I kind of hate looking at Go code containing generics. Perhaps that will change as you get more used to it? And for code you consume (e.g. using a library) Generics will make your life easier and safer.
• nsonha 5y ago
  code might be harder to read but easier to interact with, because the type is more correct. That's my experience with typescript. Generics in typescript is used way too much comparing to other mainstream languages because it's way too powerful comparing to them and I doubt golang will ever go there. However, I think people focus too much on readability often in the sense that's code is a static thing. In reality, we interact with code and poke around and use type inference to discover them.