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

A Proposal for Adding Generics to Go

blog.golang.org

Post reply on HN
Print view View original

101–110 of 273 posts

Re: A Proposal for Adding Generics to Go

#101

Post by systemvoltage »

Varriount wrote: post #97
systemvoltage wrote: post #92

Side tracking a bit: I wish there was a popular programming language like Go with rust-like package manager, Python style syntax and ability to hack, compilable, classic (classes, methods), and fast. Or I wish Go had classic OOP and raise Exception methods. Basically, I want fast statically typed python with better package management. Or other way to put it, I want Go with classic OOP and Exceptions.

You might be interested in Nim ( https://nim-lang.org ). I can't say that it's very object oriented, but it is very flexible.

That's awesome, I will check it out. Just looking at initial syntax, you just made my day!

Re: A Proposal for Adding Generics to Go

#103

Post by bcrosby95 »

nine_k wrote: post #87
anderspitman wrote: post #74

I've been heavy into Go the past year. I love the simple interfaces they've built over some rather complicated things (concurrency, cross-compilation, networking, etc), which really do tend to just work. I fear that Go will eventually turn into something where we look back and realize we've lost something important by gaining a lot of less importants. The impulse to change things is just too strong these days. C89 ha…

With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years. For C+=1, I'd look at Zig; it unfortunately lacks the excellent corporate support that Go enjoys. To me, Go looks much like early Java, only with a much better concurrency and saner "OOP". If anything, generics made Java better in many ways, without sacrificing performanc…

I think they're talking about the simplicity of C.

But yeah, I like to think of Go as a Java for the new millennium.

We're a Java shop and lots of people hate some of the newer changes to the language. And how OOP focused it is. I think Go would be a better fit because it seems to match the philosophy of our team more. But don't really think it's worth the switch for us.

Re: A Proposal for Adding Generics to Go

#104

Post by msie »

"If the proposal is accepted, our goal will be to have a complete, though perhaps not fully optimized, implementation for people to try by the end of the year, perhaps as part of the Go 1.18 betas."

Re: A Proposal for Adding Generics to Go

#105

Post by mikepurvis »

dgb23 wrote: post #70
egeozcan wrote: post #21

Earlier quoted context omitted.

There's this common belief that "rust is too hard", which used to be actually true, but the docs and the language itself came a long way since those times. I'd say: If you can code in C#/TS (or anything like) + go, then it only depends if you have a free weekend.

Rust has quite a few concepts you won't find in (some of) those languages like borrowing, lifetimes, traits, monomorphization, macros, type semantics around concurrency, (partial) expression based syntax, pattern matching and match guards... However you can litter your code with unwrap and clone to reach the finish line quickly, but then you lose the two main value props of the language and likely lose performance an…

New concepts, yes, but I think anyone who has spent any significant time programming in C++ will immediately recognize the problems that they are solving and how the solution works. That significantly eases the learning curve in my opinion.

Re: A Proposal for Adding Generics to Go

#106

Post by Jtsummers »

RHSeeger wrote: post #66
joshlemer wrote: post #62

Earlier quoted context omitted.

I thought the idomatic approach was to represent sets with map[key]bool

As someone who finds "indicating intent in the code" an important thing, I must admit I find this concert slightly horrifying. A Map and a Set are two different things and which one you use conveys some intent as to what you mean by your code. I get that it works, but it would still make me unhappy to do.

Ideally, if the language/standard library provides maps but not sets, and you wanted to use the idiomatic set = map of type -> bool approach, you'd create a wrapper so that intent is preserved but users don't have to know about the backing mechanism. Of course, it's obnoxious if everyone has to do this themselves and the language lacks generics so you have to write this once for each potential type.

Re: A Proposal for Adding Generics to Go

#107

Post by anderspitman »

nine_k wrote: post #87
anderspitman wrote: post #74

I've been heavy into Go the past year. I love the simple interfaces they've built over some rather complicated things (concurrency, cross-compilation, networking, etc), which really do tend to just work. I fear that Go will eventually turn into something where we look back and realize we've lost something important by gaining a lot of less importants. The impulse to change things is just too strong these days. C89 ha…

With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years. For C+=1, I'd look at Zig; it unfortunately lacks the excellent corporate support that Go enjoys. To me, Go looks much like early Java, only with a much better concurrency and saner "OOP". If anything, generics made Java better in many ways, without sacrificing performanc…

> With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years.

We can argue endlessly about which metrics of success are most important.

Zig looks cool. I've seen it mentioned a few times over the years. Looks like manual memory management is the default, yeah? That's important IMO if you're really trying to replace C. Rust is great but I just can't iterate fast enough (yet). Does Zig offer an optional GC?

EDIT: Also I never said Go is a good C replacement. But I'm finding it useful for some of those tasks and suspect it will be less useful for them down the road.

Re: A Proposal for Adding Generics to Go

#108

Post by wejick »

boyter wrote: post #94
wejick wrote: post #45

Earlier quoted context omitted.

I'm curious what's the issue with go routine and what kind of fix ADA bring?

Not familiar with Ada but the inability to stop running goroutines from outside it is annoying and leads to a lot of state telling them to exit. Sometimes I just want it to stop now.

It's not like on pthread where we have a trhead handler, that will complicate many things.

Like you said, We stop the go routine by telling it to exit the function, it's quite straightforward I think. Not more than a channel and switch case (+ context)

Re: A Proposal for Adding Generics to Go

#109

Post by fileeditview »

joshlemer wrote: post #62
fileeditview wrote: post #58

Earlier quoted context omitted.

Yes and that's probably why there is no set in the go std lib. You just can use struct{}{} as (empty) value in a map.

I thought the idomatic approach was to represent sets with map[key]bool

Hehe. It definitely was.. I think this is also still somewhere in "Efficient Go". However this seems to have changed in recent years. I was surprised by this too and personally I still prefer the bool even though it uses a bit more memory.

People argue there are 3 states but it is meaningless in my opinion because you can just ask exists := someMap[someKey] without checking for existence as you do with real maps. Here false is equivalent to not existent.

Re: A Proposal for Adding Generics to Go

#110

Post by anderspitman »

bcrosby95 wrote: post #103
nine_k wrote: post #87

Earlier quoted context omitted.

With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years. For C+=1, I'd look at Zig; it unfortunately lacks the excellent corporate support that Go enjoys. To me, Go looks much like early Java, only with a much better concurrency and saner "OOP". If anything, generics made Java better in many ways, without sacrificing performanc…

I think they're talking about the simplicity of C. But yeah, I like to think of Go as a Java for the new millennium. We're a Java shop and lots of people hate some of the newer changes to the language. And how OOP focused it is. I think Go would be a better fit because it seems to match the philosophy of our team more. But don't really think it's worth the switch for us.

I've used Java and Go. I find Go a far superior experience. Part of that is the standard library which seems to strike a perfect balance providing what you need but not too much.

I also think a lot of it has to do with the culture of the languages. Kotlin is a pretty nice language, but using it for Android still makes me want to hit my computer with a hammer because the over-abstraction of the Java ecosystem is maddening.

Post reply on HN