> 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?
Re:Generics enabled by default in Go tip
by silisili on Saturday August 21, 2021 @12:04PM
(#28258024)
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.
Re:Generics enabled by default in Go tip
by masklinn on Saturday August 21, 2021 @10:32AM
(#28257327)
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.
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.