Go generics are not bad • Hacker News Board

Re: Go generics are not bad

#231

Post by phlakaton » Sat, Jul 09, 2022, 3:52 PM UTC

vkazanov wrote: post #130

phlakaton wrote: post #99

Earlier quoted context omitted.

At least in the case of PLT Scheme, I recall a conference where there was open hostility to the notion that their academic language might (horrors!) become widely adopted.

And understandably so! Wide adoption means certain academy-hostile rules: backwards compatibility, a lot of user pressure towards certain directions, etc. Academics need freedom, and adoption is not about freedom.

Haskell seems to have muddled through catering to both, though! Not sure whether they see Racket as still in that researchy space.

Re: Go generics are not bad

#232

Post by mayormcheeseman » Sat, Jul 09, 2022, 3:58 PM UTC

silisili wrote: post #167

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

Go is odd in that people constantly complain about what it cannot do or does incorrectly, while having become one of the most prolific languages at the same time.

Makes it seem like we’re living in a bubble while others are getting stuff done, isn’t it?

Re: Go generics are not bad

#233

Post by iasay » Sat, Jul 09, 2022, 4:06 PM UTC

hota_mazi wrote: post #228

iasay wrote: post #162

Earlier quoted context omitted.

That’s actually a brilliant assertion (sorry for the crap pun). The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job. Go makes them deal with it.

Not really. Rust, Haskell, Kotlin, yes. They force you to consider the error path. Go makes it all too easy to just ignore errors and produce crashy code.

Go makes it explicit where the error was ignored so you can go and wring the neck of the bastard who ignored it :)

Re: Go generics are not bad

#234

Post by bediger4000 » Sat, Jul 09, 2022, 4:06 PM UTC

TheDong wrote: post #144

mseepgood wrote: post #100

Earlier quoted context omitted.

I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.

The parent commenter is dismissing generics, and various other features, as something that "bogs people down" and makes them write worse code. This is the essence of the blub paradox, thinking that people who use a feature are simply misusing it, after all in blub you don't have generics and things are fine. They're just making things more complicated than they need to be. The blub programmer isn't necessarily smug,…

I'm not dismissing generics or object orientation or orthogonal addressing modes or 'a x 'a -> 'a functions. I am observing that there's a trap that a lot of people fall into, where they spend inordinate amounts of time making everything as generic as possible at the expense of time-to-market, and understandablity.

A good class or generic is hard to beat. Unfortunately the understanding of the details that make something a good class requires experience and experiments. Maybe I am talking about premature optimization, writ larger, or in design.

Re: Go generics are not bad

#235

Post by blep_ » Sat, Jul 09, 2022, 4:14 PM UTC

maxbond wrote: post #214

blep_ wrote: post #174

Earlier quoted context omitted.

All of the things you said apply equally well to function parameters.

That's an interesting point. From a strictly theoretical perspective you're right. I think it's that generics are more abstract and have a higher blast radius. Eg, you add an argument to a method, you need to update usage of that method. You add a generic to a class, you need to update everywhere that class is used. The fact that arguments are less abstract also I believe tends to prevent them from bubbling all the w…

> you add an argument to a method, you need to update usage of that method. You add a generic to a class, you need to update everywhere that class is used.

You're talking about two different things here, though. What if you add a generic parameter to a function? It'll often be inferred at existing call sites, but worst case, same as any other change to a function's signature.

Re: Go generics are not bad

#236

Post by dmitriid » Sat, Jul 09, 2022, 4:36 PM UTC

yawaramin wrote: post #225

dmitriid wrote: post #157

Earlier quoted context omitted.

Don't buy that propaganda, however well-intentioned it is. At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.

Any moderately complex app is made up of so many moving pieces, I'm amazed that you can pinpoint those failures specifically to the web frontend piece.

I can't find what I wrote at the time, but there were multiple UI/UX issues and logic bugs.

Re: Go generics are not bad

#237

Post by kaba0 » Sat, Jul 09, 2022, 4:38 PM UTC

morelisp wrote: post #208

ratww wrote: post #196

Earlier quoted context omitted.

That was a generic argument, but still a valid one. Go is a language that indeed misses several features, including safety features, that help people perform their job better, and their excuses for that aren't exactly well thought. It is a systemic issue with the language, and criticising it ca feel like a cheap shot, but that's they way it is. It's nice that they're reverting their position on that (re: generics), b…

> Go is a language that indeed misses several features... that help people perform their job better... It is a systemic issue with the language The only language in which "misses several features" is not "systemic" is C++, and having every feature seems also to not really help anyone do their job better. I'm sure your language of choice is perfect, though.

Missing features is not the problem. A language is just as much what it has as much as what it doesn’t have. But the actual feature-set and lack-of-features Go has for it is ripe for plenty of valid criticism as is.

Re: Go generics are not bad

#238

Post by kaba0 » Sat, Jul 09, 2022, 4:42 PM UTC

_ph_ wrote: post #205

pjmlp wrote: post #158

Earlier quoted context omitted.

Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....

Right. My view is: Go brings back a lot of the great traits of languages like Pascal and Modula. Fast compilation speed, a simple static typed language, a modules concept. Adding a few nice things like GC, high order functions and some more. I feel, programming too often lost productivity with quite a few modern languages. Go brings that back and adds a good amount of modern features, but doesn't get too much distrac…

How does it bring back productivity when it has the expressivity of C (at least before generics, it’s a bit better afterwards)

Re: Go generics are not bad

#239

Post by kaba0 » Sat, Jul 09, 2022, 4:52 PM UTC

maxbond wrote: post #88

nine_k wrote: post #71

Earlier quoted context omitted.

AFAICT this is basically how numbers work in Haskell, and I see no particular problems with them. You usually don't need too many number types of different nature.

Generics are great when you need them, but they will cut you badly if you misuse them. Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too. Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that…

How is that different from any other part of a function signature? It’s part of the type system, of course changes have to be accounted for at use sites. But not doing so would be just incorrect.

Re: Go generics are not bad

#240

Post by Matl » Sat, Jul 09, 2022, 5:20 PM UTC

ratww wrote: post #196

Matl wrote: post #189

Earlier quoted context omitted.

Quoted post unavailable.

That was a generic argument, but still a valid one. Go is a language that indeed misses several features, including safety features, that help people perform their job better, and their excuses for that aren't exactly well thought. It is a systemic issue with the language, and criticising it ca feel like a cheap shot, but that's they way it is. It's nice that they're reverting their position on that (re: generics), b…

> I don't understand why this always happens in Go discussions. It's a language with a lot of potential, but people still stoop down to attacking others in order to defend it should be frozen in time.

It's not about wanting it to be frozen in time, it's more about wanting to have an interesting discussion. Repeating the same mantra in every Go thread is cheap, tiring even.

Before it was generics, now is some vague 'long way to go' thing. Again, I'd be happy to see proposals, arguments etc, but 'Go sucks' isn't original or interesting anymore.