Live data from Hacker News

Proposal: Go should have generics

github.com

381–390 of 439 posts

Re: Proposal: Go should have generics

#381

Earlier quoted context omitted.

Your comment is illustrative of a lack of awareness of context. You don't specify the context, but it seems like you're stuck in this academic/language theory mindset. From that standpoint, I rather like generics. It's clear to see how they can enable DRY if used judiciously. (Clear from even a freshman CS undergrad perspective.) However, as a professional who gets paid to wrangle C++, I find the "Tragedy of the Comm…

Ah, so you can't argue with me, so you're going to try the ol' appeal to authority ("i've worked on such big code bases that you'll never see"). You seem to assume I'm some naive recent grad. I've worked on more than a few 500k LOC applications. I'm a lead at a very large tech company (Fortune 50). The idea that '"clever"' programmers is a thing is incorrect. There are good programmers and bad programmers. It doesn't…

Ah, so you can't argue with me, so you're going to try the ol' appeal to authority ("i've worked on such big code bases that you'll never see").

Uh, no. I asked if you understand such a context and if you have such data. Going by what you state, you do. A simple "yes" would have sufficed, and you could have left out the projection. Thank you for including the projection, as it is another valuable "signal."

The idea that '"clever"' programmers is a thing is incorrect.

There are good programmers and bad programmers.

Bad code causes technical debt either way, and I've seen both done quite often.

You do understand the use of quotes, then? "Clever" programming is thought to be clever by the perpetrator, but is actually bad programming and comprises technical debt. So either you are contradicting yourself above, or you are implying that "bad programmers" know they are bad, but do bad things anyways? This doesn't fit my experience.

Re: Proposal: Go should have generics

#382
post #6

Earlier quoted context omitted.

It's not so much "let's all talk about it", but "here's how detailed a proposal needs to be to make it worth considering".

Sorry, I mean the opening of a Github issue regarding generic programming by the Go team itself is the beginning of a new stance.

It isn't a new stance either. For years people have been posting their ideas for Go generics to golang-nuts, and the questions inevitably lead to asking how they'd implement it, how it would interact with interfaces, and so on. Most of the time the proposer hadn't thought it all the way through in those regards. The point of publishing these proposals is to help speed up that process: now the first response can be to point at these and ask for a similar level of thoroughness.

Re: Proposal: Go should have generics

#383

Earlier quoted context omitted.

How do you cope? Weirdly enough I started my career writing selenium test in clojure and got used to (reduce (map (filter ... way of doing things. Then we moved to python and still I was at least able to do (modified(x) for x in xs where satisfies(x)) Then I needed to do some C# work and I really liked LINQ. Now I work in javascript and still can at least _.chain(thing).map().filter().value() It seems that we will us…

Hi there, I feel you :) The way I've coped with this so far is to embrace it and just work through the given task - less warm-fuzzy-feeling and more "manual work" and time needed for sure but it wasn't that big a deal once I just let "go"... Not having list comprehensions definitely is one of those things which makes me feel more like a "stupid coding monkey" but again you can be productive with less elegant tooling…

Well, we shall see how this will end up :)

If everything we would do are just simple micro-services, I think I would actually kind-of enjoy it.

Re: Proposal: Go should have generics

#384

Earlier quoted context omitted.

It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. Golang is doomed to relearn these lessons.

We also have the hard-earned lessons of taking DRY to its extreme (left-pad). Where you draw the "copy a little code" line is subjective.

The left-pad debacle was due to tools encouraging a badly non-hermetic build process and devs not being wise enough to resist, not DRY. Only depending on one third-party library won't save you if you "upgrade" to a broken version without testing.

Re: Proposal: Go should have generics

#385

Earlier quoted context omitted.

>> But, really, is that so much worse than this? names = [m.Name for m in machines] You can take that code and interpret that as database query, like C# LINQ. you frist example is 'how' vs 'what' of second example. Once you stop telling the computer how to do things and just tell it what you want all kinds of things become possible.

But then you have no idea what the computer is actually doing . There's a big performance difference between an in-memory loop and querying a database. This is one of the things I like about Go... what the computer actually does in response to any random line of code is pretty obvious (except for function calls, which of course can do anything). When you hide away the loop inside a map statement, you get people doing…

What the computer actually does is dramatically different between reading a register and reading a block of a mapped file, but I value concisely expressing the intent rather than elaborately repeating mechanics that might change (e.g., I could optimize machines.__iter__ without rewriting all the statements).

Re: Proposal: Go should have generics

#386

Earlier quoted context omitted.

Generics introduce more complexity in the type system which in turn makes the compiler slower. Generics introduce more complexity for the reader of the code because it's another abstraction to understand. It's debatable but when your brain is thinking about generics or context-switching because it has to wait on the compiler to finish, it's less time making progress on the actual thing that needs to be done.

The whole point of abstractions is that you don't have to worry about as much. Generics take away complexity, that's the whole point.

The whole point of abstractions is that you don't have to worry about as much. Generics take away complexity, that's the whole point.

Sure. Abstractions are perfect, and you never have to think about their costs. Generics always take away complexity. Gotcha.

Re: Proposal: Go should have generics

#387

Earlier quoted context omitted.

He who takes his examples of generics from C++ and Java has a huge blind spot. The FP crowd came up with simple and useable generics (Hindley-Milner type inference) in 1982 . It's like Go's creators haven't even read Pierce's Types and Programming languages . This is inexcusable. Even more so from Rob Pike and Ken Thomson —you'd expect better from such big shots.

It's like you assume that, since they didn't do it your way, they're either stupid, ignorant, or malicious - which I also find to be pretty inexcusable.

Well… I have seen generics that (i) don't blow up the compile times like C++ templates do, (ii) are very simple to use, and (iii) are relatively simple to implement. (I'm thinking of Hindley-Milner type inference and system F.) So when some famous guys state they avoided generics for simplicity's sake, yeah, I tend to assume they missed it.

And it's not hard to miss either. When you google "generics", you tend to stumble upon Java, C#, and maybe C++. The FP crowd talks about "parametric polymorphism". Plus, if you already know Java, C# and C++, 3 mainstream examples of generics, fetching a fourth example looks like a waste of time. I bet they expected "parametric polymorphism" (ML, Haskell…) to be just as complex as "generics" (C++, Java, C#).

On the other hand, when you study PL theory, you learn very quickly about Hindley-Milner type inference and System-F. Apparently they haven't. Seriously, one does not simply make a language for the masses without some PL theory.

Re: Proposal: Go should have generics

#388
post #257

Earlier quoted context omitted.

Given that .NET and Java already had a PHENOMENAL standard library for networking by the time Go came out, I really bet in the Google bias.

Your theory fails to account for the lack of success with respect to Dart; so, it seems more like something you have an urge to believe (despite a lack of evidence).

Dart has been abandoned by Google the day that Angular team has chosen Typescript instead of believing in Dart, thus sending to the world the message that the company doesn't believe in it.

Whereas there are a few production examples of Go at Google.

Re: Proposal: Go should have generics

#389

Earlier quoted context omitted.

> Single small binaries are easy with go With static linking? I don't think so.

Compared to a JAR with many dependencies and no option for LTO?

Putting a jar on your classpath works just like depending on a shared library but with much stronger compatibility guarantees and better chances for optimization.

Re: Proposal: Go should have generics

#390

Earlier quoted context omitted.

It's like you assume that, since they didn't do it your way, they're either stupid, ignorant, or malicious - which I also find to be pretty inexcusable.

Well… I have seen generics that (i) don't blow up the compile times like C++ templates do, (ii) are very simple to use, and (iii) are relatively simple to implement. (I'm thinking of Hindley-Milner type inference and system F.) So when some famous guys state they avoided generics for simplicity's sake, yeah, I tend to assume they missed it. And it's not hard to miss either. When you google "generics", you tend to stu…

> On the other hand, when you study PL theory, you learn very quickly about Hindley-Milner type inference and System-F. Apparently they haven't.

Again you assume that, since they didn't include it, they must not have known about it. You keep claiming that. Given the breadth of these guys' knowledge (it's not just Java, C#, and C++, not by a long shot), I really struggle to see any justification for you assuming that.

I know you think that system F is all that and a bag of chips, but it is not the only reasonable way to design a language! Assuming that they did it wrong because they didn't do it the way you think is right... that's a bit much.

But I'll ask you the same question I asked aninhumer: How fast does Go compile compared to Haskell? And, is that a fair comparison? If not, why not?

Post reply on HN