Hacker News Reader

Comment by _wldu | Hacker News Reader

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.

View on HN

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?

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

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.

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

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.

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

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.

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.

Reply on news.ycombinator.com