Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go generics are not bad

lemire.me

Post reply on HN
Print view View original

251–260 of 305 posts

Re: Go generics are not bad

#251

Post by germandiago »

kaba0 wrote: post #238
_ph_ wrote: post #205

Earlier quoted context omitted.

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)

I do not think this is true. Async programming via channels in Go is a big win and way more expressive than what any C library can give you. Also, higher order functions and interfaces are good. On top of that they added generics. I think that it is more than enough of a practical language already.

Re: Go generics are not bad

#252

Post by Matl »

ratww wrote: post #243
Matl wrote: post #240

Earlier quoted context omitted.

> 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 'l…

Who cares if it’s cheap and tiring, it’s the truth. When it was missing generica, saying so was also called a “cheap shot”. There’s plenty of proposals of thing that can be improved in this thread alone. Not every post has to contain them to be valid criticism. Sure it could have more but that doesn’t warrant personal attacks.

> Who cares if it’s cheap and tiring, it’s the truth.

You do realize that is a matter of personal opinion, right? There's plenty of developers who like the language, (doesn't mean they're not seeking to always improve it), then there's those who hate it. But a comment from someone who loves Go but says nothing more as to why would be equally as useless as a generic comment from someone less found of it.

They're free to continue posting such comments and I am free to explain why I find them useless. Simple as that.

Re: Go generics are not bad

#253

Post by blep_ »

maxbond wrote: post #241
blep_ wrote: post #235

Earlier quoted context omitted.

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

The reason I'm relating them is that they're both changes to a class, that have different blast radii and different levels of abstraction. In the worst case, adding a nongeneric parameter to a function could have the same impact. I've never heard of that happening though. I'm trying to express how I've observed things working in practice, not the theoretical boundaries of what could happen here. So lets say you add a…

> In the worst case, adding a nongeneric parameter to a function could have the same impact. I've never heard of that happening though.

Can you clarify this? I'm reading it as "I've never heard of anyone adding a parameter to a function" and that's so far from my experience that I'm either misreading or you work in a vastly different field than I do.

> Now when you add that field to that class, it also has to be generic over that type. Now you need to update all the places where that class was used.

Only if you need that to be generic too. If you change an int to a T, and you want to preserve the existing behavior for existing callers, they just call it as f() instead of f(). Languages with good type inference will do that for you without changing the calling code as written.

Re: Go generics are not bad

#254

Post by maxbond »

blep_ wrote: post #253
maxbond wrote: post #241

Earlier quoted context omitted.

The reason I'm relating them is that they're both changes to a class, that have different blast radii and different levels of abstraction. In the worst case, adding a nongeneric parameter to a function could have the same impact. I've never heard of that happening though. I'm trying to express how I've observed things working in practice, not the theoretical boundaries of what could happen here. So lets say you add a…

> In the worst case, adding a nongeneric parameter to a function could have the same impact. I've never heard of that happening though. Can you clarify this? I'm reading it as "I've never heard of anyone adding a parameter to a function" and that's so far from my experience that I'm either misreading or you work in a vastly different field than I do. > Now when you add that field to that class, it also has to be gene…

Apologies, I mean that, if you came up with some kind of pathologically bad architecture, it could encounter the same failure mode when trying to add a parameter to a function (like, the callers need to add a parameter, and their callers, etc). But as you note, adding parameters to a function is routine, and I've never heard of this happening. I've definitely added parameters in a way that was tiresome and required me to go higher up the chain of callers than I would have liked, but not in a way that spun out of control.

I'm not really sure what to say at this point really. I think we're miscommunicating somehow. Would you agree that if we are too abstract with our architecture, we'll end up with a brittle and difficult to maintain architecture?

Re: Go generics are not bad

#255

Post by grumpyprole »

IshKebab wrote: post #191
grumpyprole wrote: post #142

Earlier quoted context omitted.

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

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

It wasn't compiled with GHC, but a proprietary compiler. It could typecheck the entire lot in a few minutes (in parallel) which was usually enough to detect breaking changes.

> There are plenty of industrial languages with algebraic data types and immutability.

A few do, yes, certainly not plenty. But defaults matter and immutability means more than just "const", e.g. persistent collections.

> Not as many as I would like with purity but I doubt it will take 30 years.

Given that big tech is delivering languages that are basically the same as Algol 60, I honestly think it will take at least 30 years.

http://cowlark.com/2009-11-15-go/

Re: Go generics are not bad

#256

Post by grumpyprole »

germandiago wrote: post #242
IshKebab wrote: post #191

Earlier quoted context omitted.

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.

Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.

Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.

Re: Go generics are not bad

#257

Post by grumpyprole »

bborud wrote: post #195
grumpyprole wrote: post #140

Earlier quoted context omitted.

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.

> doesn't mean that the application of that understanding to implementation humans will take a liking to is well understood.

I really like how ML implements it, does that make me somehow less human?

Re: Go generics are not bad

#258

Post by germandiago »

pkolaczk wrote: post #212
germandiago wrote: post #168

Earlier quoted context omitted.

Well, for latency you do have to deal with the GC very carefully, but the investment/ratio in Go is very good. It is just not for absolutely every use case, like everything else in your toolbox.

Investment ratio in Go is only good because of how little you have to invest. In Rust the required investment is bigger, but you get a lot more in return. Not sure about which ratio is really better. GC is only a minor reason I chose Rust over Go for a networking related project. Despite having a GC, Go definitely feels more low-level and less structured than Rust, and leads to code that is longer and harder to reaso…

> Not sure about which ratio is really better.

That is going to depend entirely on requirements. Fast delivery, fast execution, correctness and others. No tool for everything :)

Re: Go generics are not bad

#259

Post by hither_shores »

throwawaymaths wrote: post #229
ratww wrote: post #202

Earlier quoted context omitted.

I personally do. At my company we recently finished adding types to some libraries that were a core part of our system but were deemed "untypeable" by the maintainers of the libraries themselves (we're contributing back), and only band-aids existed. We needed several advanced typing features in our languages for that that weren't available for us a couple years ago. Each time we added more advanced typing to new sect…

That's not theoretical soundness, that's actual correctness. I'm mostly talking about things like io monads.

If your code can run IO operations synchronously and branch on the result of previous operations, you've already got an IO monad. The point of being explicit about that is that it allows you to check that a given piece of code can't do those things. Keeping database calls out of the render loop, for instance, is very much a matter of actual correctness.

Re: Go generics are not bad

#260

Post by blep_ »

maxbond wrote: post #254
blep_ wrote: post #253

Earlier quoted context omitted.

> In the worst case, adding a nongeneric parameter to a function could have the same impact. I've never heard of that happening though. Can you clarify this? I'm reading it as "I've never heard of anyone adding a parameter to a function" and that's so far from my experience that I'm either misreading or you work in a vastly different field than I do. > Now when you add that field to that class, it also has to be gene…

Apologies, I mean that, if you came up with some kind of pathologically bad architecture, it could encounter the same failure mode when trying to add a parameter to a function (like, the callers need to add a parameter, and their callers, etc). But as you note, adding parameters to a function is routine, and I've never heard of this happening. I've definitely added parameters in a way that was tiresome and required m…

I do agree with that, and with the implication that one shouldn't add generics (or other abstraction) where they don't provide enough value for their costs.

But I'm confused because your example (adding a generic parameter to a function) seems to be an example of adding abstraction to code that did not previously have enough abstraction.

Post reply on HN