[maurys]

I wonder if over time, Golang will pick up more type features like Java and other languages have.

The general consensus seems to be that powerful type systems are very effective.

Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem.

Once generics are implemented, I can imagine people requesting for the next "missing" thing.

[SeanLuke]

> I wonder if over time, Golang will pick up more type features like Java and other languages have.

I hope it doesn't pick them up like Java did.

When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it.

When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java's broken local variable closure semantics]. Sun (Oracle? forget) again picked the worst of the two proposals. Now we're stuck with a real monstrosity.

Java has an amazing history of picking the wrong way to do things and permanently saddling developers with it.

[hota_mazi]

Type erasure was the best of these options, and it's one of the main reasons why Java became even more successful than it already was, and also the main reason why there are so many languages created on top of the JVM (as opposed to .net, which supports reified generics, which complicates enormously writing languages on it, especially for interop reasons).

More details: https://www.beust.com/weblog/erasure-vs-reification/

[mauricioc]

Since type erasure was mentioned, it's worth noting that Philip Wadler (of Haskell fame) was involved both in the design of Java generics [0] and of Go generics [1].

(Perhaps I should clarify that I don't have a strong opinion on type erasure.)

[0] https://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla... [1] https://arxiv.org/abs/2005.11710

[wtetzner]

> When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it.

Though using type erasure may have made the JVM a better target for other languages.

[kaba0]

Any objective reason for thinking either feature is bad?

[015a]

I think I'm ok with this as well.

The developers behind Go have a really strong culture of taking a ton of time to implement any major language changes; very reminiscent of Java and C++. Talk around Generics began, well, when the language was first created, but even more seriously like five years ago, and it'll probably be another year before it hits production.

I love this. Language changes need to be thought through considerably, with all angles considered, and by going slow it gives major developers time to give feedback, prepare, and most critically not always feel like the code they write will go out of date in three months. By comparison, writing anything in, say, Rust (and JavaScript ~four years ago, its better nowadays) feels exhausting, because its a constant battle with changing culture and evolving best practices.

My favorite feature of Go is its characteristic of not carbon-dating codebases. Go written a decade ago looks almost the same as Go written today; Contexts would be the single major pseudo-language-level feature added in that interim which may give away newer code. Adding new features is still important, balance in all things etc, and code written after generics will give another epoch of carbon dating. Go strikes this balance in a way that should be a model for every other language.

[AnimalMuppet]

> Once generics are implemented, I can imagine people requesting for the next "missing" thing.

Perhaps. But there is (currently) no other feature that people have been whining about nearly as much as they have been whining about generics. So I think it's going to be a while before another need is felt to the same degree.

[novok]

Golang is google's backup to java if oracle didn't let them have java anymore, with some additional design goals for large companies like fast build times, better memory usage and something jr engineers can pickup without much trouble.

They both have garbage collection, they both perform about 3x slower than static C and they're both mostly used for network services, which is the same as Java at google.