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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

201–210 of 670 posts

Re: Toward Go 2

#201

Post by int_19h »

JepZ wrote: post #37
masklinn wrote: post #23

Earlier quoted context omitted.

> I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts. > Yes, I am sure there are more container formats First, you f…

So if generics in java don't do anything beyond 'get typechecked, and insert implicit casts.' the empty interface is enough for all use-cases in go?

Yes, in a sense that structured loops don't do anything beyond inserting implicit if/goto, and so the latter is enough for all use-cases.

Re: Toward Go 2

#202

Post by amluto »

phillipcarter wrote: post #33
Analemma_ wrote: post #8

> For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must…

We have a similar viewpoint w.r.t Higher Kinded Types in F#. Much of the motivation for HKTs comes from people wishing to use them how they've used them in other languages, but we've yet to see something like this in our language suggestions or design repositories: "Here is a concrete example of a task I must accomplish with , and the lack of HKTs prohibits me from doing this in such a way that I must completely re-t…

This is a fair point. OTOH, just punting entirely seems like the wrong reaction.

Rust, for example, has been thinking about HKTs for a while, and they might not fit well in the language. Rust wants to solve the problems that HKTs solve, and it looks like the solution is converging to ATCs (associated type constructors).

It's taking a while, but Rust is newish, and it isn't taking anywhere near as long as Go is taking to get generics.

Re: Toward Go 2

#203

Post by nightski »

didibus wrote: post #177

I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory fo…

Nearly every item on your list is available with OCaml.

Re: Toward Go 2

#204

Post by slantedview »

callesgg wrote: post #113
weberc2 wrote: post #95

Earlier quoted context omitted.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

In my specific case it was the fact that i could not have one insert function or one update function. I would need one for each and every struct(table). These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler So from the ORM perspective we (as the community) have worked around it.

The idea that we don't need generics because we can generate code is kind of ridiculous, and certainly doesn't pass the simplicity smell test.

Re: Toward Go 2

#205

Post by spyspy »

pmarreck wrote: post #141
camus2 wrote: post #127

Earlier quoted context omitted.

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

15 Million to 17 Million is not an order of magnitude.

Re: Toward Go 2

#206

Post by vram22 »

tomovo wrote: post #9
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.

"2 Hell with generics", or "Go 2 Hell with generics"

/jk 2

Re: Toward Go 2

#207

Post by [deleted] »

Spiritus wrote: post #36
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

[deleted]

Re: Toward Go 2

#208

Post by logn »

bad_user wrote: post #48

Java`s generics have had issues due to use site variance, plus the language isn't expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it's a case of missing the forest from the trees). But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design. My gue…

My guess as to why people in Java use generics so much and switched to them so quickly is the squiggly yellow lines in their IDEs. A lot of Java code is easier to read/write with explicit and implicit casting and no use of generics. And the type erasure makes for sometimes unintuitive behavior at runtime. Being familiar with Java, I appreciate Go's skepticism toward generics because maybe just maybe they'll figure out a way to add them after the fact in an elegant way.

Re: Toward Go 2

#209

Post by resf »

matthewowen wrote: post #92
HarkMamilton wrote: post #10

Earlier quoted context omitted.

I think this is too little, too late. Anyone who saw an advantage to using generic programming is already using something else. They've already invested resources in something besides Go; why spend the effort to switch back for what will, at best, probably be very mediocre support for parametricity compared to whatever they're already using?

Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.

The opposite side of that coin is that other programming languages do already exist.

Any new language is already playing catch-up to reach the state of the art. Go is 10 years old and in those 10 years has made astonishingly little progress at implementing basic features such as error handling, because the designers cannot escape their bubble.

The most sensible thing to do is to kill Go, not to improve it. The root problem is not the lack of this or that feature, but the bizarre beliefs of the people running the project.

Re: Toward Go 2

#210

Post by spion »

didibus wrote: post #177

I get that everyone would love to have a functional language that's eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory fo…

OCaml might become this once multicore happens.
Post reply on HN