Go generics are not bad • Hacker News Board

Re: Go generics are not bad

#191

Post by IshKebab » Sat, Jul 09, 2022, 11:17 AM UTC

grumpyprole wrote: post #142

sangnoir wrote: post #107

Earlier quoted context omitted.

> Academia on the other hand will make great languages that never reaches critical mass Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.

> my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day Why would they? Many are designed meticulously to address the issues industry has. I've worked on a multi-million line Haskell code base in a financial institution and it scaled better than e.g. C++ or Python. In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data t…

God what's the compilation time of millions of line of Haskell?

> In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

There are plenty of industrial languages with algebraic data types and immutability. Not as many as I would like with purity but I doubt it will take 30 years.

Re: Go generics are not bad

#192

Post by nyanpasu64 » Sat, Jul 09, 2022, 11:25 AM 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,…

Having used trait-based generics, I think that trying to piece together what's going on in typenum, the GAT stabilization process, https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-..., num-traits, and variance and https://github.com/rust-lang/rust/issues/25860 is absolutely bogging me down. I feel (and observe as people try modeling contracts in traits) that trying to build code which plays well with open-ended type parameters is inherently more difficult than building a correct solution for a single type. Generally I'd prefer a more focused less generic solution which corresponds to a single function in the generated machine code (modulo inlining), except in cases where generics (over a small or open set of types) provide a clear benefit (collections are a clear example, IMO point-free .iter().map().sum() style is usually a regression in readability).

Re: Go generics are not bad

#193

Post by goto11 » Sat, Jul 09, 2022, 11:33 AM UTC

Numeric types are weird in Java and .net. I'm more familiar with C#, but in C# adding two int's result an int, but adding two short's also result in an int. So addition is not polymorphic the way you would expect it to be. C# has a large number of numeric types, but below the hood it only supports arithmetic operations on three of them.

The problem is not with the implementation of generics per se, the problems is numeric types in those languages is a really leaky abstraction.

Re: Go generics are not bad

#194

Post by bborud » Sat, Jul 09, 2022, 11:41 AM UTC

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…

"Shit show" is a bit imprecise. What would you say are the major shortcomings in Go and how do they manifest as problems in practical reality?

Also, it would be interesting to hear your take on why you think languages that are, as you say, from "a sound theoretical foundation" tend to struggle with adoption?

Could it be that you fail to take into account that the things that make a language appealing in an academic sense may not make the language a particularly practical language?

Re: Go generics are not bad

#195

Post by bborud » Sat, Jul 09, 2022, 11:45 AM UTC

grumpyprole wrote: post #140

truffdog wrote: post #108

Earlier quoted context omitted.

Ian Lance Taylor worked on generics for like a decade, and the final design was heavily based on the Featherweight Go paper, which had formal proofs of the design given a simplified version of the go language. This is a very odd complaint around this feature.

Yes retrofitting is hard. However, "Generics", also known as parametric polymorphism is well understood and goes back to Milners ML from the 70s.

While something may be well understood in an academic sense doesn't mean that the application of that understanding to implementation humans will take a liking to is well understood.

If you look at the programming language landscape I think one wouldn't be unreasonable in pointing out that very little is understood in terms of how you go from good ideas to widely adopted language.

What affects reality is important.

Re: Go generics are not bad

#196

Post by ratww » Sat, Jul 09, 2022, 11:53 AM UTC

Matl wrote: post #189

laerus wrote: post #156

Earlier quoted context omitted.

No it's simpler than that, they hate Go cause it's a half-assed language. The creators didn't respect developers enough to make it consistent and complete cause "devs are not smart enough". The argument about "getting things done" is like saying the language is Turing complete.

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), but there's still a long way to go.

Also: just because someone isn't forced to use it, doesn't mean it's immune to criticism, no matter how vague it is. And also, some people are forced to use it at their day job. Again, just because they can quit their job, doesn't mean the language is immune to criticism. I would suggest some introspection if criticism of something you like is causing you to dismiss their arguments and attack them, no matter how bad they are. There was no attack to you.

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.

Re: Go generics are not bad

#197

Post by e12e » Sat, Jul 09, 2022, 11:59 AM UTC

anonymoushn wrote: post #150

e12e wrote: post #138

Earlier quoted context omitted.

>> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays > More likely they install a 3rd party generic sum function and don't have to write their own at all. Well, in the case of a sum function it's probably only 15 minutes to write to generic version I'm not sure "sum over an array of int" is a great "…

> This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language. What's the result of adding two i32 then? Is it an i64? Doesn't the accumulator need to get wider on some additions, since adding an i64 to an i32 might also overflow an i64?

Actually, the default is overflow I now realize. But there is also automatic promotion, so:

    0 + typemax(UInt8)+ typemax(UInt8)
    510

While adding UInt8 first, then an implicit Int64 causes overflow:

    typemax(UInt8)+ typemax(UInt8)
    254

(ie: 255 overflows to 254 - or is promoted and sums to 510)

See: https://docs.julialang.org/en/v1/manual/integers-and-floatin...

Try: https://julialang.org/learning/tryjulia/

Re: Go generics are not bad

#198

Post by morelisp » Sat, Jul 09, 2022, 12:01 PM UTC

ericpruitt wrote: post #190

morelisp wrote: post #187

Earlier quoted context omitted.

Your understanding is correct. That's also what you will effectively get with C or C++ on Linux anywhere you would have had a choice between C++ and Go to behind with.

Since when do heap allocation failures on Linux result in an abort? In C, malloc(3) will return NULL on failure and set errno accordingly. Sure, if overcommit is enabled, you might get a fault if you try to access memory that was allegedly allocated, but there is no strict "malloc failure === fatal error" relationship.

malloc never fails on normal Linux configurations except in very rare instances not applicable to this discussion (e.g. allocating a single structure larger than your virtual memory space).

> if overcommit is enabled

This is the case on ~all systems.

Re: Go generics are not bad

#199

Post by maffydub » Sat, Jul 09, 2022, 12:04 PM UTC

I don't seem to be able to post on his blog (400 Bad Request), so posting here instead...

Interestingly, it looks like Rust (and C via clang) both generate something like the following as their one-at-a-time main loop:

.LBB5_14: addl (%rcx), %eax addq $4, %rcx cmpq %rdx, %rcx jne .LBB5_14

It's one fewer instruction than the Go version (because it has combined the MOV and the ADD), although I don't know whether that would actually result in higher performance.

I say their "one-at-a-time" main loop, because they actually seem to generate lots of code to try to take advantage of AVX or AVX2 to add 4 or 8 values at a time if available and the array is long enough!

It might be cheating, but summing an iterator over numbers is built-in to Rust, so summing an array is just: v.iter().sum()

The fun thing with this is that it's not just generic over number types, it's also generic over any type of iterator, so I can even use it to sum over the values in a HashMap: hashmap.values().sum()

Re: Go generics are not bad

#200

Post by bborud » Sat, Jul 09, 2022, 12:17 PM UTC

wyuenho wrote: post #36

The title says Go generics are not bad, and then in less than a page this guy only compared one use case with Java's generics. I'd expect a CS professor to be able to add a little more rigor in a blog post but I guess everyone is losing patience to read and write these days, even for the supposedly erudite.

If someone doesn't know how to address an audience you can hardly blame the audience for not responding. Academic papers are written to further academic careers. Their audience is not developers, but other people who are also not developers.

Of course there is going to be an impedance mismatch. What makes people important, effective and useful isn't what silly snobbery they use to put other people down, but whether they can effectively communicate their ideas to the audience.