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

151–160 of 273 posts

Re: A Proposal for Adding Generics to Go

#151

Post by BoorishBears »

johnnycerberus wrote: post #35
tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

Measuring against Kotlin or other languages in this category like Scala is not the right thing to do. Also Kotlin is known for its slow compiler though JetBrains promised that the situation will improve. I would use Scala or Kotlin for everything data but when it comes to low-level networking/infrastructure I wouldn't even touch anything else but Go. Go is in the perfect sweet spot for this task. The Goldilocks Zone…

It's such a truly terrible comparison because they didn't compare Kotlin, they compared Android!

The insane amount of time of overhead an Android project has over a "plain Kotlin" from resource packing to dex stuff to desugaring to ProGuard, it made me question if they're speaking in good faith for the rest of the comment...

My ktor projects on the other hand compile incredibly quickly, and with hot reloading it's even more seamless to iterate

Re: A Proposal for Adding Generics to Go

#152

Post by mseepgood »

switch007 wrote: post #135
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.

This, kinda! But I'm after: - Python's OOP, stdlib, exceptions - Go's fast compilation and binaries - Rust's package manager (never used but I heard it's amazing) - Java's third-party packages & tooling - F#'s expressiveness, FP, type system (never used it, only read a few intro articles, but it looks very nice?) I'm tyring to move on from Python but finding it difficult to decide what to learn next.

> I'm after [...] never used but I heard it's amazing

Really? This is how you form your opinions?

Re: A Proposal for Adding Generics to Go

#153

Post by BoorishBears »

jacques_chester wrote: post #137
stickfigure wrote: post #99

Earlier quoted context omitted.

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

People from the post-1.4 era of Java aren't aware how huge code generation was before generics showed up. And then all that momentum, all the tools, the books, the conference presentations, the code ... all of it. Pop! It died. Because code generation sucks . It is the worst solution to any problem solvable by a type system.

My favorite example of generics wonkiness was when I needed a channel to wrap an untyped channel to avoid "infecting" every call site for a utility function with untyped pointers.

I thought it was madness, but bringing it up to a very large Golang group and get "nope channels are cheap! That's fine! There's repetition but it's easy to follow"

I've said before, my personal take is use Go, get a feel for the Go mentality, then take it with you to another language.

Go is just too stuck between low level and high level for me personally. I'd rather go under with Rust or over with Kotlin or C#

Re: A Proposal for Adding Generics to Go

#154

Post by echelon »

rowanseymour wrote: post #63

I rarely find myself frustrated with the lack of generics in Go and am so glad to never deal with the kind of over-engineered generic madness that is so common in Java, except... When dealing with collections. It's maddening to have to keep duplicating basic functions like getting the keys from a map, or checking if a slice contains a given item.

Aren't collections 30% - 40% of code? (We seldom deal with just one thing.)

That's why I feel generics are so important.

You can build complicated messes with any programming paradigm. It's a matter of discipline to use the tool correctly. Don't hate on generics, but rather the unskilled use of them (which I frankly see far less than abuse of other patterns/paradigms/language features).

The biggest negative with generics is compile time, but the clarity and conciseness of generics is worth it for me.

Re: A Proposal for Adding Generics to Go

#155

Post by anderspitman »

dangoor wrote: post #141
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…

> The impulse to change things is just too strong these days. FWIW, I don't think this impulse is there with the Go team. Go progresses quite slowly, from what I've seen as a user over the past 18 months. Generics have been in discussion for a long time with multiple implementations and no real rush to "just ship it".

I was referring to software culture in general, not Go specifically. Sorry I wasn't super clear.

Re: A Proposal for Adding Generics to Go

#156

Post by dilap »

jacques_chester wrote: post #136
dilap wrote: post #67

Earlier quoted context omitted.

> Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. That's interesting, could you explain this more? Context: I used to use Go a lot, but mostly haven't since Go modules, and I'm curious to know the details of the problem and why it happens.

It doubles down on Go's assumption that git repository === a proper package/module system. It mixes up URLs and URNs. If your git repositories aren't tagged just so , then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequen…

Huh, interesting, thanks for the response.

Does that mean Kubernetes is not following the version tagging policy in its repos? That seems...surprising!

Re: A Proposal for Adding Generics to Go

#157

Post by benibela »

johnnycerberus wrote: post #116
zenlot wrote: post #88

Earlier quoted context omitted.

If anyone wants to check fast compile times try Delphi, RAD Studio has community edition which is amazing. It feels like it compiles while you type :)

I expect anything that has a little Pascal inside to be blazing fast.

And they have already added generics to Pascal

It really makes Go look like a joke

Re: A Proposal for Adding Generics to Go

#158

Post by switch007 »

mseepgood wrote: post #152
switch007 wrote: post #135

Earlier quoted context omitted.

This, kinda! But I'm after: - Python's OOP, stdlib, exceptions - Go's fast compilation and binaries - Rust's package manager (never used but I heard it's amazing) - Java's third-party packages & tooling - F#'s expressiveness, FP, type system (never used it, only read a few intro articles, but it looks very nice?) I'm tyring to move on from Python but finding it difficult to decide what to learn next.

> I'm after [...] never used but I heard it's amazing Really? This is how you form your opinions?

Nope, I'm looking to _learn_ a new language, and I _heard_ it's amazing. I didn't say it _was_ amazing

Re: A Proposal for Adding Generics to Go

#159

Post by randomdata »

TheDong wrote: post #148
randomdata wrote: post #114

Earlier quoted context omitted.

The biggest challenge is avoiding the tricks from languages that allow you to use the language to paper over questionable design choices. Go requires that you get the design right up front and provides few escape hatches to save you if you mess up. Which is a good thing, but makes the language (not just the syntax) difficult to learn compared to others.

Can you give examples of specific language features of go that prevent you from making questionable design choices, that require you to "get the design right up front"? When I hear that, the first things that come to mind are things like haskell's IO monad, which forces you to model IO better than go or most other languages, or haskell's other state monads which similarly force you to model state more explicitly. I t…

> Can you give examples of specific language features of go that prevent you from making questionable design choices, that require you to "get the design right up front"?

No, obviously. I said that Go doesn't give you an escape hatch if you screw up. It does nothing to protect you from screwing up. I specifically said that the challenge was in learning how to not screw up as the language doesn't help you deal with or avoid design mistakes.

Re: A Proposal for Adding Generics to Go

#160

Post by saturn_vk »

ramoz wrote: post #113
shadowgovt wrote: post #98

Earlier quoted context omitted.

> We have a very large Go codebase here at Stream That's exactly what generics are supposed to solve! ;) No, but seriously, I'll be interested to see if they can pull off maintaining the compiler performance while adding support for this new feature. I've had to hand-write a lot of code that I'm excited about a generics solution automating, but automation can have a price, you're exactly right. I've worked on a C++ c…

In our large production project we have a very simple Go arch that enables 15+ microservices. Im not sure I see the value of generics either other than complicating a rather complicated distributed architecture with abstracted implementation. It's beautiful that we still import 6yo packages that are clear, concise, and work as needed. The package landscape with generics doesnt seem great.

I don't think generics will suddenly make your, or anyone else's codebases more complicated. It might simplify code that's currently doing type assertions
Post reply on HN