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

111–120 of 273 posts

Re: A Proposal for Adding Generics to Go

#111

Post by grey-area »

jacques_chester wrote: post #25
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,…

If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically insta…

Don’t do that then.

Re: A Proposal for Adding Generics to Go

#112

Post by EugeneOZ »

egeozcan wrote: post #21
skrtskrt wrote: post #14

Earlier quoted context omitted.

I like Go, but I too in the meantime have dipped my toes into Rust and it's just so much better without being that much more complex. The learning curve is real but quite a bit overstated I think.

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.

It really depends on what you are going to do with Rust. Sometimes it can be really tricky, but for simple tasks where we used to use scripting languages Rust can be similarly simple.

Re: A Proposal for Adding Generics to Go

#113

Post by ramoz »

shadowgovt wrote: post #98
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,…

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

Re: A Proposal for Adding Generics to Go

#114

Post by randomdata »

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,…

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.

Re: A Proposal for Adding Generics to Go

#115

Post by moocowtruck »

cratermoon wrote: post #28

I look forward to generics in Go. Yes, it's possible to do it with reflection, interfaces and interface{}, but it's not typesafe, it's not fast, and it's prone to code bloat. I'm a fairly late-comer to generics, I never programmed seriously in C++, I avoided generics in Java initially, and I wrote a lot of code in less statically-typed languages. Ever since the first serious talk of generics in Go 2.0 I've endeavored…

generics in go will be a great addition, also it is important to realize generics in java and go are different such that go uses structural typing vs nominal

Re: A Proposal for Adding Generics to Go

#116

Post by johnnycerberus »

zenlot wrote: post #88
johnnycerberus wrote: post #71

Earlier quoted context omitted.

Java, Go, OCaml, Typescript (>=3.9) are in their own league when it comes to compilation speed.

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.

Re: A Proposal for Adding Generics to Go

#118

Post by ed25519FUUU »

__jem wrote: post #80
ed25519FUUU wrote: post #76

I'm really mixed about this. As a developer I would love having generics in Go. I can think of a few places in my code I can greatly simplify if they were implemented now. However, as someone who reads other people's Go code, I'm not a huge fan. One of the greatest things about Go is that a developer can usually one-shot read and understand almost anybody's code because there's a simplicity "forcing-function" applied…

In other words, go is the language you want your coworkers to write, not the language you want to write. :)

I agree totally with this sentiment. I love reading other people's Go code but not always writing it, which is basically the opposite of virtually every other programming language I've used.

Re: A Proposal for Adding Generics to Go

#119

Post by seeekr »

hackyhacky wrote: post #37
peawee wrote: post #31

Earlier quoted context omitted.

And that's (part of) why C needs to go.

Sure. But why not replace it with something that is type-safe AND already has generics, like Rust? Why are we trying to get a do-over on Go?

Rust and Go both aim to create safe, performant, modern languages suitable for use from the systems layer up, differing in some of their primary goals:

Rust is a sane C++: Zero-overhead abstractions, not afraid of language complexity.

Go is a modern C: Simplicity, stability.

They have some overlap in what they're best at, but they both take on unique and important missions that both need to be targeted, in our rapidly expanding universe of software engineering.

(edit: formatting)

Re: A Proposal for Adding Generics to Go

#120

Post by tick_tock_tick »

andolanra wrote: post #46
johnnycerberus wrote: post #19

Earlier quoted context omitted.

I would say that in the case of Rust, generics are on the list of those "few other bonuses". There are other things in Rust that are more attractive and innovative. Rust is as complex as C++ (which is not a compliment) but saner and safer, without undefined behavior. Though, at the rate they add new features, I can see it becoming rapidly a kitchen sink.

Rust is a reasonably complex language, but—having programmed professionally in both—I don't think it's nearly as complex as C++. Rust features for the most part are orthogonal to each other, whereas C++ features tend to have weird interactions with each other that are really hard to track and understand. (The one place where Rust starts to get messier in terms of feature interactions is async Rust, but luckily you ca…

I agree I just have to assume people comparing Rust to c++ never really used c++ professionally for any length of time. Rust is incredible simple coming from c++ there is normally only 2 or 3 ways to do something vs 5 + 4 more via templates. It takes longer to learn the symbols for lifetimes then to get a grasp of what you need to do to keep the borrow checker happy.
Post reply on HN