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.

Thanks for your experience, really. Here's hoping.

Does Go generics have type erasure? If not, OP can expect and even better journey.

There are two meanings of "type erasure". One concerns the user, the other the compiler writer.

When most users people ask about type erasure, they ask whether types are erased when compiling the reflection information for polymorphic values (like Java does). Go doesn't have polymorphic values, so the question doesn't apply.

Type erasure means something more general than that to compiler people. Type erasure refers to whether you can compile code while erasing its type, and it's generally a useful property. In general statically-typed programming languages are implemented with type erasure, while dynamically-typed languages are not. Of course, since Go has reflection, it can't do type erasure. Interfaces also conflict with type erasure somewhat, though as expected, during the code generation types are erased as much as possible.

As a comparison, Rust does type erasure fully.

So Haskell has type erasure only for data types that do not derive Typeable?

No, because all types have a Typeable instance! Haskell has type erasure, and then using Typeable adds the type information back exactly where it is needed.

No, they don't have type erasure.

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.

> 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?

I was thinking of generic functions rather than (non-generic) methods on generic types. Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken.

> Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken.

The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language).

So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not going to be sad over reflection having never supported toplevel functions in the first place.

What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?

I fail to see what any of this has to do with reflection.

> any script interpreter

What are you even talking about.

> or management RPC server

I would very much expect RPC endpoints to be opted in explicitly and statically.

> or other languages’ FFI?

I fail to see why Go-level reflection would be involved in that in any capacity.

> What good are top-level functions

You can call them? From your go code?

Are you saying rust or C can't be because they don't have reflection? That's a strange position.

When I type at a Groovy REPL, an interpreter is using reflection for nearly everything. Same goes for native code that has to use reflection via JNI entry points to call Java. It’s damn useful. At the heart of every debugger is a half-finished reflection API that deserves to be cleaned up and surfaced for language interop and novel kinds of tools.

Have a look at D and .NET 5 for compile time reflection.

Or in Java's case annotation processors.

Yes, not everything gets exposed, but it also does the job.

Functions are useful because you can call them from your program.

With Java, I didn't find it to be either a huge win or a major loss. And I still don't. It's basically window dressing that lets you avoid casts in certain obvious places where they weren't particularly problematic anyhow.

It's more than window dressing. A year ago I added correct generics to about 50 000 lines of Java, an old module in a bigger program. The change was mostly mechanical, removing casts and adding signatures.

I found a few places where refactoring had left behind a wrong type cast. Production logs demonstrated actual crashes corresponding to these cast. There were bugs in the issue tracker, marked unresolvable.

Interesting, I'd never encountered such bugs, but it makes sense

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.

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?

You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.

While it's true that some find it liberating, a large number don't — personally, I've written a fair amount of production Go code and found it unnecessarily verbose and repetitive in ways that generics would've helped. I imagine some of this is based on problem domain; if you're writing a web application for example, maybe you don't really need generics much. After all, how often do you need a function that logs in a user to also log in... a book you're selling? Not very often. And any advanced data structures probably live in your database: how much do you really need a B-tree in a webapp when you've already got one in MySQL?

That being said for a lot of other uses, you really do want high quality data structures beyond "array" and "dictionary."

Sure, that's true, and it's fine. There are people who find s-expressions both liberating and clarifying, and others who get lost in a sea of parentheses. And there are problems that are especially amenable to s-expressions, or generics, or fine-grained control of memory allocation, or interwoven code and markup, object hierarchies, and those problems sort of "ask" for particular languages. But for the most part, this stuff is subjective.

There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.

I feel like it pretty much always turns out that the things you can't do without generics are, like, second-order things. Higher order functions, type safe custom collections, those are tools. What we care about mostly is what we actually build, and people build pretty much everything in every language, generics or not.

It depends what you’re building. If you’re writing a library to do those things, they may well be first order. Certain extremely useful patterns like parser combinators rely on them. And of course, the current answer is just “do something else instead.” But I don’t really see why this has to be the answer. Surely the decision to leave them out is just as subjective as a decision to add them.

By the same token, functions in general are second-order things - you can build things just fine with GOTO, and plenty of real-world software was built like that back in the day. But we don't do that anymore.

Yeah, but programming is the business of building little tools to help you build what you actually want to build, over and over again. E.g., you might have some API calls in your code and need to implement an error handler on some of them. You could repeat the error handler code on all of them, or you could extract it out to a generic function and just use it as a wrapper for the others:

    let call1 arg = ...
    let call2 arg = ...

    let error_handler call arg = ...

    let call1 = error_handler call1
    let call2 = error_handler call2

Python made this kind of technique famous, but languages with generics can do it pretty well too.

One example of a thing you want generics for is image processing procedures that operate on many different image formats with different color spaces. If you use the built-in image libraries (which is perhaps already a mistake), then you have an image that owns its channels, and you pass it to some resizing method or whatever, and then that resizing method's innermost loop chases pointers to find out which kind of image it was *for every pixel*. For performance reasons, you may not want to chase pointers in your innermost loop. Without generics, you need to copy and paste a bunch of code once per color space.

To add to your point, not using generics in Go is a choice too, even if it’s now an option.

But some people like offloading that to the language: not having it in a language means you don’t have to control for it on your team/project contributors + some 3rd party library.

I felt Go filled this minimalist category well. It’s always nice having a modern mainstream option doing so, not just a niche one on the fringes (ala LISP), even if I’m not personally a fan.

I guess it’s hard to keep saying no.

Yeah, we should have kept using macro assemblers instead of needless abstractions.

If you believe that absolutely, the way you imply here, then we're all just chumps for not working in Haskell.

I feel like I should probably admit that I am just generally a fan of functional programming and I do think there are big benefits to it, most of the time (of course, some algorithms are just more elegant with loops and mutation). But my day job is writing services with Elixir, so ultimately complaining about generics in Go is a little rich coming from me.

At the end of the day, whatever gets the product built is what matters. I just fail to see how generics could be a hindrance.

Not necessarily Haskell, although it would be nice, there are already enough ML influences in modern languages, with exception of Go.

Confessions of a used programming language salesman

https://dl.acm.org/doi/10.1145/1297027.1297078

> As a result, functional programming has finally reached the masses, except that it is called Visual Basic 9 instead of Haskell 98.

Sure, but programming languages are also tools. Why bother having this discussion at all, if you don't care about tools?

You can absolutely write type-safe higher order functions without generics. You can't write generic higher order functions, but that's a tautology.

Also higher-order functions are a moot point. Higher-order functions give you convenience, but no increase in expressive power (defunctionalization is an homomorphism).

Of course, generics give you a true increase in power.

> if you're writing a web application for example, maybe you don't really need generics much

All our microservices return a { result: ... } or a { result: ..., nextPageToken }

We would definitely benefit from generic SingleResult<T> and PagedResult<T>.

Instead, you copy-paste the same definitions over, and over, and over, and over again for every call.

I think I see what you're doing. Right now, each result type implements NextPager, which returns information about how to fetch the next page. You client can implement a utility like FetchNextPage:

    type NextPager interface {
        NextPage() PageSpec
    }
    func (c *Client) FetchNextPage(ctx context.Context, current NextPager) (interface{}, error) {
        ...
    }

Then for each type of paged object, you write:

   func (c *FooClient) FetchNextFoo(ctx context.Context, current Foo) (Foo, error) {
       next, err := c.client.FetchNextPage(ctx, current)
       ...
       if n, ok := next.(Foo); ok {
           return n, nil
       }
       return Foo{}, fmt.Errorf("unexpected type: got %T, want Foo", next)
   }

That's annoying. But, this problem has come up before with `sql`, which has rows.Next() and rows.Scan() to iterate over arbitrary row types, and you could use that as a model:

    pages := client.Query(...)
    defer pages.Close()
    for pages.Next() {
        var foo Foo
        if err := pages.Scan(&foo); err != nil { ... }
        // do something with the page
    }
    

Generics would let you enforce the type of `foo` at compile time, but it wouldn't save you many lines of code. I think you still have to write (or generate) a function like `func (c *Client) ListFoos(ctx context.Context, req ListFooRequest) (Paged[Foo], error) { ... }`. We hand-wave over that in the above example with a "..." passed to query (potentially possible if you retrive objects with a stringified query, like SQL or GraphQL), but that sounds like the hard and tedious part.

Let me conclude with a recommendation for gRPC and gRPC-gateway as a bridge to clients that don't want to speak gRPC. Then you can just return a "stream Foo", and the hard work is done for you. You call stream.Next() and get a Foo object ;)

> Generics would let you enforce the type of `foo` at compile time, but it wouldn't save you many lines of code.

You literally showed that "for each type of paged object, you write <multiple lines of entirely unnecessary code>".

Where with generics you just have a single generic function.

> We hand-wave over that in the above example with

The problem is: there's no hand-waving in reality.

I'm traveling, so can't properly expand on what I said, but without generics the choice was:

- repeat unnecessary bolierplate code for every single return type

- skip types completely and use a function that accepts interface{} as a parameter and assigns whatever to that variable

Neither are really acceptable in my opinion. And both will be greatly simplified and improved by generics.

You say "verbose and repetitive", I say "easy to read without any surprises".

The verbose patterns (if err!= nil for example) make the code predictable to read, you notice the code smell of missing error handling really fast.

I think readability has multiple dimensions, and it really depends what you are looking for.

For example here's a code in Go to look for a Prime:

    func IsPrime(n int) bool {
        if n < 0 {
                n = -n
        }
        switch {
        case n < 2:
                return false
        default:
                for i := 2; i < n; i++ {
                        if n%i == 0 {
                                return false
                        }
                }
        }
        return true
    }

It's readable as it is simple to understand what each line does.

Here for example is a code that does the same thing in Rust:

    fn is_prime(n: u64) -> bool {
        match n {
            0...1 => false,
            _ => !(2..n).any(|d| n % d == 0),
        }
    }

It's might seem more complex at first (what does match do, what 0...1 means, !(2..n) what is any() doing. But if you understand the language it actually this seem much simpler and you can quickly look at it and know exactly what it is doing. And because it is less verbose it is easier to grasp the bigger code.

I also noticed that while individual functions in Go are simple to understand and follow, you can still create complex, hard to follow and understand programs in Go.

Go is crazy verbose. Even Java can do it much more simply:

    static boolean isPrime(int n) {

        return switch (n) {
            case 0, 1 -> false,
            default -> !IntStream.range(2, n).anyMatch(i -> n % i == 0)
        }
    }

You changed function signatures from int->bool to uint->bool, which changes how long the functions are.

That seems unfair when comparing:

Removing negatives from the Go implementation removes 6 out of 16 lines, bring it from 3x Rust to 2x Rust in line length.

I used code from: https://endler.dev/2017/go-vs-rust/ good point, I overlooked that.

Anyway in Go (ironically because of lack of generics) if you use any numeric type other than int, int64, float64 you will be in the word of hurt. Rust doesn't have that issue.

So in practice you will likely use int, and I suppose you can add an assertion.

BTW: I only see that it would remove 3 lines though, where are the other 3?

I don't follow. I use unsigned ints in Go all the time. I've never been in a world of hurt with them. Mandatory explicit integer conversions (and the way Go consts work) are something Go gets right.

Ok, so you like that. I myself really hated when I used float32 and had to do this when I was doing calculations:

    result = (float32)Max((float64)a, (float64)b)

I ended up switching the type to float64, and wonder why they even offer float32 if it's practically unusable. I had similar experience when I needed to use int8 or int16 etc.

An alternative was to make own version of Max/Min and other math functions, but this is what generics would solve.

I'm not sure I follow, because Rust is also (thankfully) fussy about integer types.

I think what they mean is utility functions (e.g. min/max here) tend to only be implemented for one type, so if you’re using an other you keep casting back and forth.

Rust is very fussy about types and some operations are bound to a single one (e.g. stdlib sequences only index with usize) but utility functions tend to either be genetic or be mass-implemented using macros (or by hand probably for f32::min and f64::min though I did not check).

I don't have problem with being strong typed, I like that as well. The problem is that the stdlib doesn't really support other types and that's mostly due to lack of generics, so using uncommon types becomes quite annoying.

TBF the float Min/Max issue has nothing to do with generics, there isn't a "floating-point" generic class, and the entire reason why Go has an f64 Min/Max in the first place is that floats are not fully ordered[0], so you "can't" use regular comparisons (which you'd be told to do for integers) and thus you could not have a generic min/max relying on that even if there was one (e.g. in Rust `f32` and `f64` are not `Ord`, which `std::cmp::{min, max}` require, hence both `f32` and `f64` having their own inherent min/max methods).

So what your issue comes down to is Go's designers couldn't be arsed to duplicate the entire `math` package to also work on `float32`. Some members of the community did rise to the challenge[1] tho.

[0] well recent revisions of IEEE-754 have a total ordering predicate but I wouldn't say that it's really useful for such a situation as it positions NaNs on "outside" of the numbers, so a negative NaN is smaller than a negative number and a positive NaN larger than a positive number

[1] https://github.com/chewxy/math32

I'm aware of it, in the example given I used float32. Anyway Max/Min was just example I used other functions from math as well.

Anyway my point was that with generics, they wouldn't need to copy anything, the math package would work with both float32 and float64 and many functions likely would also work on all integers.

The difference here is that I can hand off the first code to any random freshly hired CS grad or cheapest outsourced coder and they can grok the code quickly. This is the advantage Go has to all other languages.

The Rust code needs maintenance coders of way higher caliber, not something you'd usually find. It's super fun for the top-tier developers who love to be expressive and concise with their code, but all code is pushed down to maintenance mode eventually when the hotshots move on to the new shiny project.

Go has removed pretty much every footgun by sticking to the basics. You have one way to do a loop, one way to do comparisons etc. There are very few ways to hide non-obvious functionality.

It _is_ possible to create complex programs, that are hard to follow but that's a larger design problem. Not something the language can force on developers.

That was one of the points from Java 1.0.

Thing is, care with what you wish for when easy to outsource is a goal, a welcomed feature mostly relevant to IT managers that don't care about the final quality of delivery, nor what consequences it makes to the home job market.

So yeah to all Wipros, Infosys, TCS, .....

Personally I find code with generics just as easy to read as (largely duplicated) implementations for each type. I might consider Golang again when this drops and there are things to be like about how low level it is…

Or use Option or Result, so your error handling is small and forcibly correct.

Error handling in Rust isn't always small or straightforward. I miss both options and match expressions when I switch back to Go from Rust, but there's also tangles of or_else's and maps and the fact that everyone uses third-party libraries to work out the types for errors. There's tradeoffs everywhere you look.

Zig is probably a better comparison for this:

https://ziglang.org/documentation/master/#Errors

In rust you have to swallow an error quite explicitly. In go it’s extremely easy to swallow one "err”, by assigning to some previous one which was already checked.

You're right that a templating language would reduce the code and make it easier to read.

Yeah, that's why Kubernetes had to develop code generators. So focused.

I wouldn't know, I don't use K8s. But I did write a code-generating ORM for a Go project and found it in a bunch of ways superior to the ORMs I'd used in dynamic languages, like ActiveRecord. And I've also worked with heavily parameterized Rust crates that kept 20 tabs open in my browser just trying to work my way through a couple function calls.

Don't get me wrong, I'd take Rust generics over codegen 8 times out of 10. But that ORM worked well, and was the only time I ever needed to write a code generator in Go.

Sorry but there's a bit of bias, every author of a library thinks that their approach is better than of their competing libraries.

If they didn't, they would just not create another solution.

Having said that you might be right with ORM though. One of great reasons why ORM might be superior on statically typed language is that you can rely on the type system to ensure you writing correct code (you also get benefit of autocompletion, refactoring in IDE etc). The problem though is that the type system including generics might not be sufficient to express it. So code generation could be still superior here.

The JOOQ (not exactly ORM though) generates java code, even though Java has generics.

BTW: I personally think though that actual proper way to handle this problem is to what JetBrains did. They integrated DataGrip into their IDEs (I think it's available in the paid version though) after you connect IDE to the database, it starts detecting SQL statements in the code and treat it the same as rest of the code (i.e. auto completion, some refactoring (they still need to improve that more) etc). It makes an ORM no longer necessary for me. I think that's probably the way to solve the impedance problem.

Is your ORM open source?

That made that to themselves, the original prototype was in Java and changed to Go thanks to some recently joined team members that were very munch into Go.

> You wouldn't

As someone who hasn't used Go, what would I do, then? The question about a generic data structure was very practical, your response was philosophical, and I still need a linked list.

You would use a slice as your non-associative container, and you would write a loop over it. You just wouldn't use a linked list.

And honestly, 9 times out of 10, I'm better off rebuilding the list because vectors have lower memory overhead and the memory is contiguous. But that one time... I've also been spoiled by Java's very rich set of collections.

Linked lists aren't the best example because they're almost never the right tool. But in the last month alone on a rust project I'm working on I've used:

- Option, Result, and other stuff from the standard library.

- My own B-Tree implementation w/ domain specific enhancements, in about 4 different contexts

- A heap based priority queue

- A custom 2 level vec, to support arbitrary insert & delete without shuffling elements around. (This turned out to be faster than my b-tree but less memory efficient.)

- Several different custom iterators, and iterator combinators. Eg, I have an iterator over some data which gets computed on demand. I have an iterator which consumes and run-length encodes each item in another iterator. And so on.

All of this stuff has generic type parameters everywhere. The b-tree is generic not just over the stored data, but also over the way its index works. I can specialize it to do a bunch of different tricks by just changing a type parameter.

All of this code is fancy and hence difficult to read for the uninitiated. And that isn't the Go way. But there's a big, valuable middle ground here. I'm glad Go is adding some options to let people lean a little bit into cleverer code when it becomes appropriate for the problem domain. Emulating generics with interface{} seems worse than just adding generics into the language.

And even if you assert that the use cases for generic structures are limited (which is debatable but why not) there's definitely something to be said for generic functions over existing generic types e.g. currently if you want to build utility methods over slices or maps (like… set operations because everybody uses maps but maps don't have set operations) you have to pick between:

* manually instantiating (handrolling) every version, possibly duplicating it if you don't realise somebody else did

* same except using codegen, which is easier to maintain but has more semantic overhead (now you need to add codegen to the project and there's an extra build step to consider)

* or manually type-erase and cast back, risking type safety and most likely performances

A flagrant example from the stdlib is the `sort` package with its weird and alien interface (and Interface), inability to use key functions, and which can only work in-place.

Talking about in-place but circling back to generic structures / collections, a big use-case I expect to see for generics would be type-safe (immutable) concurrent collections e.g. HAMT, RRB, …. Current Go significantly limits the ability to "share by communicating" (as well as safely "communicate by sharing") as there's no good way to build and make any sort of high-quality concurrent collection available, whether persistent or mutable.

It's not like this is some kind of new or unfamiliar experience. Many programmers had to deal with something like that in Java or C#, back when they didn't have generics. There's a reason why both got them eventually.

The anti-generic folks usually ignore that the industry was built with non generic languages, and largely decided to adopt generics.

It isn't as if we never coded without generics before.

I could not have said it better myself, despite trying. Thank you.

This is one of the best definitions of 'minimalism' I've seen.

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.

It's not as if it's a niche problem requiring a niche solution though. The problem is "how do I write my own data structures" and to the best of my knowledge Go's answer is: copy-paste everything and edit for each concrete type, use code gen, or pay runtime cost for interfaces. All of those solutions seem more complex than just having a type parameter.

They seem more complex compared to a type parameter when you are only thinking about this narrow situation. However, generics are not limited to this narrow situation and will cause complexity far beyond what you are imagining.

Having said that, I honestly don’t know if generics are a net positive or not. What I can say is that go is one of the few languages where I can jump into an arbitrary go code base and make sense of it relatively easily. Risking that is a scary proposition for me.

I'm well aware when they are useful, I've been using them in languages for the past 10 years. By the same token though, leaving type parameters out of the language has had far reaching implications outside of this "narrow" situation (I'll put forth that implementing a data structure isn't a narrow situation). Error handling and the lack of sum types also seem particularly egregious and are heavily influenced by the lack of generic types.

> Having said that, I honestly don’t know if generics are a net positive or not. What I can say is that go is one of the few languages where I can jump into an arbitrary go code base and make sense of it relatively easily. Risking that is a scary proposition for me.

I don't see how type params would make this harder, I daresay I can think of a lot of instances it's much easier. The caveat is that you simply don't understand them, in which case it's a good thing to learn as many languages do have them.

In any case all these arguments are well trodden so I'm probably wasting my breath re-hashing here.

I’ve been using them for the past 30 years and have come to a different conclusion. You have plenty of languages that do what you want. I hope go doesn’t lose what made it different

Oh sorry, you were saying lack of generics were the reason you could make sense of code easily, implying that if a language has generics you can't make sense of it. That seems juxtaposed to having used them for decades. In any case I can tell you're passionate about this so I think we can just agree to disagree.

That said I don't think there's much "hope", from the looks of things it is coming to Go.

I'm hoping that Go still keeps it's relative simplicity. It's lack of inheritance gives me hope that generics won't be as complicate as it is in other languages.

I understand generics well, I just find code bases that use a lot of abstractions harder to read than Go.

You know? Original Java was a fairly simple language :) Generics were added in 2004 in J2SE 5.0.

Just call it parameterisation, it's less scary then. The unknown is always scary but having the ability to parameterise - including types - is well traveled ground.

This can be said for any programming language and any community: there will always be bad code written by someone.

Generic data structures are provided in many programming languages and there are many people that are very experienced in writing some of these, so being able to reuse, it's precious.

In general the lack of generic price surfaces when you write libraries, not applicative code. But libraries are a big portion of a codebase.

I’ve been coding for decades. I’ve used all the fancy functional languages, written production code at scale with complex type systems, etc. my experience, they don’t add a lot of value compared to the costs. In my old age I’ve grown to prefer go for it’s simplicity. I hope we don’t lose it, and you all have the option of using the myriad languages that already do what you are looking for.

I think you misunderstood my point (maybe): I totally agree with you. I've been coding for many years and coming from Ruby where you can do "the worst stuff you can think off" (really bad stuff: monkey patching, building DSL etc.), I came to Go exactly to get relief from all of that. I don't trust people having their hands on all that power.

Still in my short Go career, I worked on at least 4 libraries, one of those needed generics to gain a huge performance boost, the other worked around the lack of generics, but I still wish it had it (a special kind of logger). In applicative code, the main issue with lacking of generics is the lack of generic slices functions (map/select). Initially I thought it would be fine, but then I wrote a piece of code that was visibly involved in copying data from one slice to another with some changes and that "shadowed" the "central" part of the code behind a bunch of loop codes. In those cases, to improve the ability to easily scan through the code, I wish I had some generic slice function to deal with it. I appreciate doing loops, but sometimes they are verbose enough to hide the interesting part of a piece of code. This is especially visible in applicative code where usually performance is not as important as much as the business logic.

Go has some "special" built in functions like len() that work across different structures. What if instead of adding generics they added more of those special functions for working with slices as you describe? Would that have solved your problem?

Of course, but remember that `len` has constant return type, while in case of slices you'd have a return type that's different on the input slice

I see. I guess I assumed that the category of special "privileged functions" would have their powers extend to cover stuff like that (I haven't used Go, I'm just going off of what I've read)

I'm very intrigued by the no-generics idea, so I'm prodding at what might've made it workable enough that this reversal wouldn't be necessary :)

All good!

Well in Go the assumption is that you jump to interface{} (equivalent to Object in Java or void* in C) when you start having these kind of problems, but there is a performance penalty in doing that, which shouldn't be there if generics are present (and makes the code DRAMMATICALLY worse with all the casting)

> Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be.

That's pretty laughable considering the language designers included type-parameterized collections in the language. Apparently they recognized the need for them; they just didn't think you were smart enough to make your own. After all, Go was explicitly designed for programmers who are, in the words of its creator, "not capable of understanding a brilliant language".

Probably a bunch of that code was needless boilerplate you could have gotten away with not writing if you had abstractions such as parametric polymorphism.

Maybe you could have gotten that work done with fewer than 500,000 loc if you used a language with a better feature set.

Lines of code is a complete red herring. It takes me less time to read and review 500 lines of Go than it does 100 lines of JavaScript.

Sometimes - especially in other languages - you see a piece of "elegant" code that does something complex in line 3 lines, and you think "hmm, this is a puzzle, and I'm going to be staring at it for 20 minutes before I'm convinced that its 100% correct."

We actively tell our engineers not to be clever. Write boring code that is obviously correct, and don't worry if your boring code is 25 lines when the elegant code is 8. It takes you longer to write the elegant code, and it takes the reviewer longer to read it, and often times (though not always ) it's also more difficult to test.

I love Go because of how boring and consistent and easy to read it is. The language and the task of "programming" melt away and instead you get to focus on solving problems.

Study after study has shown people fail at repetitive tasks, it is likely you do a much poorer job reviewing that 500 lines of Go code than your javascript.

Using generics isn't 'clever'. It's like saying a loop is clever. It's abstraction, the opposite of clever.

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.

Optimizing for people that are new to a codebase seems like a mistake to me: onboarding costs are relatively minimal and finite (per developer) whereas maintenance costs have no fixed bound: if generics let you exclude invalid states by design (and they do: this is one of the biggest advantages of parametric polymorphism vs. interfaces), they will be useful for keeping maintenance costs under control.

You definitely want to optimize for people who are new to a codebase. Over enough time, the codebase grows to a point where essentially _everyone_ is new to each area of the code, because nobody has touched that code in 2-3 years and the person who wrote it may not even be with the project anymore.

Even for your own single-person projects - if you get fancy with the code, 6 months later you find it's a lot harder to get back into and mess around with than if you had written the code as though you were presenting it to a beginner.

Management is responsible for making sure that doesn’t happen, by retaining experts and demanding documentation and investing in ramping up new experts. Making the code bigger because each line does less is not going to save us from nobody understanding prod, and a short learning curve puts a low limit on the value of our staff (who quickly run out of tools and stop improving in clarity and productivity).

You want patterns that are well-known to the maintainers, but this is different from “optimizing for the new”: consistent idiomatic use of a library like XState or Ramda in a JavaScript project can cause a high onboarding cost (because the new developers don’t know the library well) without any corresponding ongoing cost.

I’m guessing you like Haskell and similar languages, because that’s the natural conclusion to your line of reasoning.

I don’t agree with you, but I could be wrong. There are plenty of languages that are aligned with your point of view. I like go because it was going a different direction, and I hope that doesn’t change. You can use Haskell, scala, typescript, etc to get what you are looking for.

How is a generic data structure a COMPLEX ABSTRACTION?

If people would stick to common generic data structures (like a map/list that can handle any datatype), i'd be fine with abstractions.

But some people have a tendency to play code golf with their codebases.

I have, for example, encountered a "generic data structure" that looked like a normal linked list on the surface. BUT, it actually sorted the largest three items in the first 3 cells and the average in the 4th.

That was multiple days of work wasted because someone decided to be cute with their data structures. And that wasn't even the only one of such "generic" monstrosities in the code.

So blame goes to the hammer instead of the carpenter?

What does that have to do with generics? Surely they’d have written the same bad code monomorphised?

Generics (and other abstractions) are not the root cause. Go was a pragmatic defence against mediocre developers. The majority of developers are mediocre by definition, and will abuse _any_ abstractions to create Rube Goldberg contraptions and monstrosities.

20 years ago those mediocre programmers were using Visual Basic and Java, so look for the past to see where future goes.

Well there is a valid point of abuse in abstractions. The ruby world is a disaster because of the power provided combined with people reaching out to all sorts of abstractions the entire time for purely experimental reason.

It's true that applicative code shouldn't need generics in probably more than 90% of the times, however the lack of it affects library authors quite heavily

They are complex. I’m guessing you haven’t thought about them much beyond the trivial use cases.

No, it's relative. For the top 5% - 10% of developers, generics are a useful tool for doing their job efficiently. For the bottom 50% of developers, generics are complex and confusing, and only provides more footguns.

For 0.5%-1% C++ is a powerful tool which allows to quickly (thanks to rich abstractions) to write high-performance code.

For merge mortals it is a tool hard not to misuse full of hidden traps and debugging of code written even by the very best developers (surprise - it has bugs too) is a challenge.

Go just did a step towards C++, even if a tiny one.

Not everyone is entitled to be a sushi master.

And the top 1% of developers know that you are most productive when you stick to the simplest primitives ;)

I jest, but I also don't. All the best developers I know strongly prefer footgun-free libraries and primitives. The advantage is that you don't _need_ to spend brain cycles checking and double checking that it was written correctly, and when you want to make changes you don't need unwind an elaborate abstraction to stretch it further.

In martial arts (I'm a second degree black belt), the third move you learn is the round house kick (turned leg kick - the first two moves are the punch and the straight leg kick). At the olympic level, 70% of all points are scored using a roundhouse kick.

The other funny thing about the roundhouse kick is how much you can learn from watching someone do a single one. You can tell the difference between someone with 2 years of experience and 3 years of experience, and you can _also_ tell the difference between someone with 15 years of experience and 20 years of experience.

The point of this story being that masters are masters not because they can do elaborate techniques, but because their command over the simplest techniques is superlative.

I've found in life that this applies to pretty much everything. Martial arts, programming, painting, cooking, and effectively any task that definitively has some people who are better than others.

Generics use the type system to make the compiler check the code for you. It makes the code easier to understand, more correct, and concise if you use them as they were intended. It avoids tedious and error prone duplication of logic. Create ONE efficient debugged implementation and reuse it as much as possible. The crappy workarounds for generics introduce their own complications and issues.

But I know what you mean. I've worked on Scala code for years and seen less mature developers over-engineer things and get way too clever with the type system. Scala is a really practical and powerful industrial language that requires some maturity to use the abstractions sparingly. It's only good for the top 5% of developers.

However, Go doesn't have such a powerful type system. It looks like the Go designers implemented relatively simple generics. You have to draw the line somewhere. If simple Go generics are too confusing and complicated then that developer should probably find another job, as generics are a basic concept in programming. The Go designers are pragmatic people, and they've decided that relatively simple generics will make things easier in mainstream commercial codebases.

so as an example, I've used priority queues a lot. you need them for Dijkstra.. apparently golang has a heap package which lets you push and pop `interface{}`. sure you can cast, and I guess people have to, but why couldn't Go just call `interface{}` object or any? the awkwardness of the convention suggests an unwillingness to accept failure.

Parametric polymorphism is a better fit for container types IMHO. There are some interesting notes here…

In Go prior to generics, interface{} is an escape hatch less frequently needed but not necessarily much safer than void*. Post generics, interface{} is suddenly more useful and will be aliased by ‘any’.

The way the std lib heap works in Go, an implementation doesn’t have to mention interface{}. Using the Go std lib solution is about satisfying a few interfaces, defining some methods for sorting and swapping over the element type. The use of interface{} is internal.

Go’s generics solution is going to have type constraints, which I think will be very familiar to some and probably new to others … So, the Go generics PQ should still require some constraints on elements, not ’any’thing will work. I’ve really enjoyed constraints in languages and it’s not quite natural in C++/Java, but Go’s interfaces already do some ‘constraint’ work conceptually and can be used as constraints in Go’s generics syntax. I’m interested to see how this plays out.

>not necessarily much safer than void*

You can cast void* to anything you want. With interface{} you get a type check, either through an assertion or a panic. That is a big difference in safety.

Fair point. Maybe there are contrived cases that can get nasty (an interface{}-typed variable boxing a function is possible, not so with any non-empty interface ), but in practice the pathology would be ‘panic’ more than ‘here are the keys to the exploit kingdom’, if this is what you were thinking.

I was thinking more about silence where someone expected a greater degree of compile-time type safety than they really had, or relatedly e.g. the subtleties in JSON encoding / decoding where there is silent data corruption that could fall through the cracks - mostly I feel like I avoid these things by not using interface{}; I certainly did not grasp that without some experience with the language.

I also wrote hundreds of stuff from 1986 up to 1994, my first experience with generics, on Turbo C++ for Windows 3.1.

Doesn't mean many of us want to keep living on that world.

I advise reading books like "From Mathematics to Generic Programming"

You don't write singly linked lists of arbitrary data :).

In my 20+ years of development, I've definitely realized everyone's brains and approaches work differently.

You do if you want your language to have a reusable Linked List data structure so that everyone doesn't have to re-implement their own version of it for each content type.

There are languages that do this already though. Use Python. Reusable everything, just wait for exceptions.

I've spent time in C, Python, Go, Js, and some lesser known languages. I was really big into Python. Go seemed restrictive at first, but was immensely more safe and predictable.

Linked lists are the one data structure that you never end up wanting a generic version of. They aren't really used as containers. (Except badly.)

They’re the easiest stack structure to implement. All your operations are against the head of the list and you either have a thing, don’t have a thing, or add a thing. I’d like to be able to maintain a stack of things whose types I don’t have to manually reify and erase. That’s not a tall order, and it’s certainly not “complexity”. It’s markedly weird that I can’t have that same structure and associated operations be usable regardless of the thing I’m working with.

If you want a stack you'll just use a growable array (in Go, a slice). A linked list is suboptimal.

Linked lists serve a real purpose in some situations where you really do want O(1) behavior. One example is when you are performing the operation while holding a mutex. But it's never the sort of thing where the right tool is a linked list generic container.

I agree linked lists might be suboptimal for a stack implementation, but for a different reason: data locality.

You can have O(1) stack with both implementations. Slice-based will be easier to follow, and will bust the cache less often (less pointer jumps).

Singly linked lists are something from CS1 where you learn about data structures. You rarely use them in practice. In most cases slices and maps do the job fine.

They also have absolutely terrible performance due to poor cache locality and putting pressure on GC

There are many ways to implement a list, including backed by arrays.

That is what those CS algorithm and data structures lectures are for.

They make a great stack, though. Cheap to use and easy to implement.

Use a deque at least and amortize the heap allocations...

With generics I could justify the extra engineering work to make such a deque!

Source?

CS201

Ok genius, explain how exactly what the OP meant?

Nobody needs to do that, but it would be nice to have sorted collections without dynamic casting or rewriting half of leetcode in every project.

You can do something similar to container package which has a double impl.

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.

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.

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.

Because you will already have seen that precise piece of code in a thousand other contexts?

> Can you give an example of terrible unreadable go code due to a lack of generic

https://news.ycombinator.com/item?id=28254411

The "solution" to this is copy-pasted boilerplate code with casting for every call.

I have seen terrible and unreadable generic code, people building abstractions just for the sake of abstractions.

Hello-world level projects with 20 class deep hierarchies of generic classes, just to make it "generic" in case you need it later.

I agree. It’s true for all languages. I once had to untangle a small Java app that had about five packages with two classes per package (I refactored it into a single package).

Some people will abuse generics, no doubt, just like my colleague abused packages. But Go has such a strong culture around idiomatic code that I’m not too worried that generics are the end of the world. In fact, I don’t like keywords like “append” and I’m hopeful generics will replace them.

TBH I was more upset about the Go 1.17 ability to panic during a type conversion from slice to array pointer. That one really grates my gears.

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".

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.

> 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.

They can simplify code, but they don't simplify the language.

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?

you sound bitter

I'm just believing what Rob Pike told me about his target users for Go.

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.

For some strange reason many developers lose sight that programming languages are software products just like anything else than one can sell for installing into a computer.

While FOSS might have changed the way to sell those products, they are still products looking for attention, market share, ecosystems, conference talks, consultancy, trainings.....

C

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.

To add to what other people said, the tooling around C has changed a lot since C was created, partially because there's already so much code in C. The Linux kernel is 20/30 millions lines of code of C mostly, Kubernetes is below 2 millions. So at this point you can still change the language a bit. With C it's harder, so instead people invest in tooling (and replacements).

C11 introduced type generic expressions.

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...

Kind of, now that typeof is going to be part of the language, that coupled with the preprocessor, does allow exactly that.

Although in typical C fashion is a bit of kludge.

"coupled with the preprocessor" is a bit of a cop-out :-). Do you have a concrete example of what typeof would enable? Like a basic implementation of a vector type?

True, it is basically //go: generate, before Go was born.

Here is an example, https://codereview.stackexchange.com/questions/101816/generi...

ISO C23 is coming up, and until the last UNIX stops working, C's existence is assured.

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.

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.slid...

It also depends on your use case. Kubernetes and its pile of code generators will be much much simpler.

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.

I didn’t need generics till I wrote a mathematical library, and wow they would be handy

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.

> I don't need or want generics

I do need and want generics. So... Whose needs and wants are more important?

Neither, of course. I'll leave so you can join. I don't think either of us is wrong.

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...

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.

> Before long, scammy tutorials pop up showing Go as an essentially dynamic language

Sorry are you saying adding generics to Go makes Go closer to dynamic languages? Shouldn't that be the opposite?

> 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.

Do you have an example of this (code)? What's wrong with tuples with elements of different types? What's the alternative?

So, mixed typed tuples was the idea, but Go doesn't support either of those things, so it ended up as a [][10]interface{} or some such. So for each item in the slice, type assert all 10 things inside the subarray. Luckily the comments had a key of expected types of each.

That would be exactly the thing generics are supposed to fix (except that Go doesn't have tuples yet, but at least you can define your own now and return a generic `Tuple[A, B]`).

Regardless of that, returning a tuple of size 10, especially with different types, would almost always be a bad idea.

Your problem isn’t generics or any other language features; your problem is a lack of effective code review or technical leadership.

Go doesn't even have tuples, where would those even come from?

It sounds to me like the simplicity of the language in this case didn't prevent a bad programmer from writing bad code, and that it was a problem that should have been addressed with code review and training, not by expecting the language to keep things in check.

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.

Learning something is also an option.

Thank you.

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.

Are generics really considered as "esoteric comp sci topics"?

I needed to use C# for some project. Used generics without actually being aware what they were. Helps that C# implements generics without type erasure.

> Helps that C# implements generics without type erasure.

For about 95% of "using generics" that makes no difference, and you'd have had no more issue in Java.

That aside, Go is implementing reified generics (there is no real backwards compatibility concern as the "core" collections are already ad-hoc parametric types, and the rest is not a great loss).

Java had a lot more legacy code using a much higher number of standard but not-generic-at-all collections, I'd bet there were also concerns around the forward compatibility of legacy reflection code, and they'd probably considered a lot of collections-related goodwill spent with Java 1.2's Collections Framework and the deprecation of the limited set of original collections.

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

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.

If people can understand functions, they can understand generics. Nothing more complicated, generics are just functions on a few type arguments.

Here’s an example from this very thread that shows how complex generics get relatively quickly.

https://news.ycombinator.com/item?id=28255738

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?

I don’t find it confusing, but it is certainly more complex than a simple function call. I chose it because it is a basic usage of generics, to highlight that basic generics are more complex than basic function calls.

A code base that makes heavy usage of generics takes more time to understand than one that doesn’t make heavy use of generics. The readability of go is what I love about it, amongst a few other things.

Without generics, you'd have N functions instead of 1. Are you sure N times the complexity of non-generic function is less than 1 time the complexity of a generic function?

No one knows for sure. I’ve seen a study or two that found that reading and writing generic code is a lot harder, while using a generic library is relatively easy.

Writing generic code is indeed harder than writing non-generic code, but what I wanted to point out is that you can't compare generic code to a non-generic piece that handles only one type (which is often what people do), because the functionality is not the same, it is apples to oranges. What you should compare is non-generic code that handles the same cases as the generic one. So the non-generic code would also get a lot of additional complexity due to that - e.g. instance-of checks or repetition that would be absent in the generic one.

I think genericity is like any other abstraction e.g. functions or interfaces. Applying it blindly can lead to more complexity, but in hands of someone who knows what they are doing it can be a great tool for reducing complexity.

“ in hands of someone who knows what they are doing it can be a great tool for reducing complexity.”

It really boils down to this, but what does that really mean? I’ve been coding for a very long time, and go is one of the very few languages where it’s relatively easy for me to jump into a code base I’ve never seen before and make sense of it. Maybe the majority of code isn’t written be people that “know what they are doing”?

I like to think in terms of optionality, the magnitude of possible upside and down side. I’ve come to the conclusion that heavy abstraction has a large magnitude of downside risk and relatively small upside benefit for large teams and institutions.

Proper abstraction can have a huge upside by allowing people to understand a part of the project without the need to understand all of it. We're using abstractions all the time really, you don't need generics for that. An iterator, a collection, a file, a network connection, a database table are all abstractions. You don't have to read N millions of lines of database code to learn how to use a database. Abstractions like these are good.

Abstractions where the description of the usage (API) is just as complex as the implementation are bad, and I bet you can create them in Go quite easily without generics. At least I know it is possible in Java, and also was before Java 5.

Again, a lot is packed into your usage of the term “proper”. I find new code bases in go far easier to read than new code bases in every other language I’ve used. Are you suggesting that most code bases are written by people that don’t know what they are doing, and are improperly using the language features?

I learned C++ when I was 13, Haskell at age 15. I don't have a CS degree nor do I work as a developer.

I learned C++ templates during high school, back when C++ARM book was the official standard.

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.

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.

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.

You can totally do fine without generics depending what you do. It mostly affects code that supposed to be reusable, especially libraries.

you sound like you're too smart for generics.

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

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!

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.

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.

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.

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.

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.