Live data from Hacker News

Generics enabled by default in Go tip

go-review.googlesource.com

301–310 of 378 posts

Re: Generics enabled by default in Go tip

#301
post #297

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…

There is no doubt that Go needs generics. Pretty much every Go container and data structure library on github will benefit from generics. The empty interface is used everywhere , leading to all kinds of panicking typecasts, hard to debug errors, and inefficient conversions. The vast majority of these uses can be made type-safe, more efficient, and clearer with generics. There is nothing subjective about the benefits…

There's some pain in writing generic data structure algorithms for sure. It would have been an interesting experiment though if the Go authors would have tried to improve the tooling around code generation and making it easier to use, as an alternative avenue to generics as code generation might satisfy some of the cases likely to trigger those complains.

Anyway, interesting to see how far they will take the generics in the path to Go 2.

Re: Generics enabled by default in Go tip

#302
post #95
post #86

Earlier quoted context omitted.

Are generics really considered as "esoteric comp sci topics"?

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

I learned C++ when I was 13, Haskell at age 15. I don't have a CS degree nor do I work as a developer.

Re: Generics enabled by default in Go tip

#303

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

That’s because “HN threads” represents a lot of different people with different needs and opinions. It’s not a monolithic block at all, and people are more likely to react to complain.

> people are more likely to react to complain.

You hit the nail on the head. This is broadly true across virtually everything--at least in most of Western culture (as this is the only one I'm most familiar with).

Anger seems to provoke a more actionable response whereas satisfaction does not (generally speaking). Is someone more apt to call a business over lousy service or great service? Why is it that giving a compliment to someone in customer service sometimes provokes a brief reaction of surprise? I try to do my part as a positive force when I can, but I usually fall short. Besides, is one happy person likely to make that much of a difference over the course of a day? Maybe, maybe not.

FWIW I actually like the idea of generics in Go and have a few use cases where they'd be exceptionally helpful in cutting down the amount of code I have floating around in some libraries. I just don't feel strongly enough about it to jump into a thread to rush to its defense.

Re: Generics enabled by default in Go tip

#304

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…

I think this derives from the fact that a fair amount of programmers are told what language they will write in and are forced to adhere to the languages semantics even if they liked other language semantics.

The force part comes from a desire for business continuity and efficiency. If you're a large scale Go shop there's a fair amount of specialized infrastructure needed including a goproxy to prevent leakage, some apparatus to view documentation, and probably educational resources.

A large scale Java shop needs extensive artifact storage and a place to host generated Java docs.

If you employ both languages your infra cost is now going up for something a business sees as pure overhead rather than the conduit for innovation. In my experience this leads to language supremacy discussions, bickering over scarce funding, etc.

On my team, we're polyglot. Everything, including docs, are generated and self-hosted internally. We make the best of a brisk situation. What lets me sleep okay at night is that developers have a choice to use the best tool (language) for the job, not just the one that a company hired for ten years ago.

Re: Generics enabled by default in Go tip

#305
post #179

Earlier quoted context omitted.

> Before long, scammy tutorials pop up showing Go as an essentially dynamic language Sorry are you saying adding generics to Go makes Go closer to dynamic languages? Shouldn't that be the opposite? > I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of…

So, mixed typed tuples was the idea, but Go doesn't support either of those things, so it ended up as a [][10]interface{} or some such. So for each item in the slice, type assert all 10 things inside the subarray. Luckily the comments had a key of expected types of each.

Your problem isn’t generics or any other language features; your problem is a lack of effective code review or technical leadership.

Re: Generics enabled by default in Go tip

#306
post #252

Earlier quoted context omitted.

There are two meanings of "type erasure". One concerns the user, the other the compiler writer. When most users people ask about type erasure, they ask whether types are erased when compiling the reflection information for polymorphic values (like Java does). Go doesn't have polymorphic values, so the question doesn't apply. Type erasure means something more general than that to compiler people. Type erasure refers t…

So Haskell has type erasure only for data types that do not derive Typeable?

No, because all types have a Typeable instance! Haskell has type erasure, and then using Typeable adds the type information back exactly where it is needed.

Re: Generics enabled by default in Go tip

#307

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…

For me it's about paradigms the language represents. I try to extend the simplicity of golang all the way to the network architecture. I've learned that it's better to build many very very simple things and connect them. Not for any technical reasons, but because it allows other developers to quickly begin adding to and fixing your systems. You get to leverage the large amount of mediocre programmers when your systems are simple instead of looking for heros. It's definitely easier said than done though to make systems naturally intuitive and simple.

I've also learned that in most cases you don't need to invent some giant application. It's far easier to create extensions or wrappers to existing operations or service tools, with a bonus (again) being easier hiring and delegation. You can hire someone who knows a standard piece of tech and quickly ramp them up on a small extension or wrapper that you wrote. Golang is the language that made me always take this simple approach first and look for something that does 80% of what I need and think about problems very generically.

Re: Generics enabled by default in Go tip

#308

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…

How is it strange? It seems completely natural to me. A programming language is a tool that software devs have to use for 8 hours a day. And even more annoyingly the individual software dev generally doesn't get to decide what tool he gets to use. That means the top programming languages are always under a strong pressure to adopt feature X from Y devs favourite language. Now Go is quite an interesting case I think. It's essentially an ancient language with good tooling support backed by one of the largest companies in the world. Go has now yielded to generics. I don't think Go is capable of becoming modern because the initial design decision have essentially made that almost impossible. I wonder though, what the next feature for Go demanded by the community will be.

Re: Generics enabled by default in Go tip

#309
post #287
post #95

Earlier quoted context omitted.

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

If people can understand functions, they can understand generics. Nothing more complicated, generics are just functions on a few type arguments.

Here’s an example from this very thread that shows how complex generics get relatively quickly.

https://news.ycombinator.com/item?id=28255738

Re: Generics enabled by default in Go tip

#310
post #295

Earlier quoted context omitted.

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

> C++ The parsing rules for templates alone probably make a decent door stopper. They can also trivially kill compile times. The bloat from page long symbol names also isn't something to ignore, just std::map ::find() results in a decent chunk once the compiler is done expanding it. > Java That is a can of worms, haven't professionally worked with Java in some time, but from memory: * Compile time only, reflection or…

Fwiw generics in Java should have less holes once they start releasing things from Valhalla.
Post reply on HN