Hacker News Reader

Comment by AnimalMuppet | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com