Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

41–50 of 238 posts

Re: Generics aren't ready for Go

#41

This reads like sour grapes. Basically, this is trying to spin "Popular language missing essential feature" into "But what if it's because they're braintstorming something EVEN BETTER???" Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first. Plus I think the language-obsession is usually cargo-culting and signaling. All good engineers I know…

Lack of generics is a feature imo

Re: Generics aren't ready for Go

#42
post #32

> Go strikes me as one of the most conservative programming languages available today. It’s small and simple, and every detail is carefully thought out. This article is wrong in many ways, but I thought I'd point out this particular one. There are many really weird warts in Go, in fact its about average in "wartiness". Here is one example https://dave.cheney.net/2017/08/09/typed-nils-in-go-2 Go biggest advantage isn'…

Sucks for you, considered very good by plenty of other people who use it daily.

Re: Generics aren't ready for Go

#43
I realize I'm not the audience here, but still -- As someone who isn't terribly familiar with Go, most of what I'm seeing in this article is the shady corners I can't see into.

The generics one, I've seen plenty of pixels spilled on, and I've come to accept that I won't really grok the debate unless I spend some serious time programming in Go. What about the module system, though? Can anyone explain or share an article on what's so great about its module system?

Re: Generics aren't ready for Go

#44
post #17

I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.

using interface{} and reflect is good enough for the many problems of using X datatype

One of Go's tennets is "clear is better than clever", followed by "reflection is never clear". So no, idiomatic Go is not about using reflection, it's what we have to resort to because the language is so limited.

Re: Generics aren't ready for Go

#45
post #34

Earlier quoted context omitted.

Go has a kind of generics that also maps cleanly to machine-level generics: interface{}, which is like void* in C. Whereas all the other kinds of generics, I believe, can't offer this quality. They require a lot of machine code instanciations (like C++'s template system). Or at least, in the case of virtual functions ("dynamic polymorphism" with VTables), they cause more brittle abstraction boundaries. Think how in C…

You don't need to expose any internal details on other languages that make use of generics. Even on C++ this is be eventually a thing of the past, after modules get finally adopted. Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.

Layouts of separately compiled classes/structs must still be exposed to the compiler. You can't hide layouts away, they are part of the interface. With all the disadvantages that dependencies bring.

> Using how C++ currently does as argument against generics is a pretty weak argument, given the various ways to implemente them since CLU and ML introduced generic programming into the world.

I would be interested to know how you think the problem of tighter coupling (a.k.a dependencies) is solveable, because I don't see a solution. For example, I'm pretty sure that typeclasses in Haskell are implemented with either of those two approaches I've mentioned depending on the situation.

(Maybe it's possible if we require more information for the linker? I haven't thought through this.)

Re: Generics aren't ready for Go

#46

I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.

As I understand many Go devs are former python/ruby devs. Its limited static analysis is even great compare their former languages, There are many articles which notice type safety as advantage of Go. So they have easy to learn, very fast language with good support for concurrency/parallelism (Consider what goroutines offer compare to GIL).

Re: Generics aren't ready for Go

#47

This reads like sour grapes. Basically, this is trying to spin "Popular language missing essential feature" into "But what if it's because they're braintstorming something EVEN BETTER???" Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first. Plus I think the language-obsession is usually cargo-culting and signaling. All good engineers I know…

> Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first.

Yet people can write distributed databases, monitoring tools, dns/DHCP servers in go. ANd they deliver stable and performant solutions with thousands of institutional users.

How come, if the basics are not solved?

Re: Generics aren't ready for Go

#48

I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.

You code without them. Ends up making your code clearer in a lot of case, it's pretty good actually. I think a lot of people complaining about generics here are not writing Go

Re: Generics aren't ready for Go

#49

I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.

I programmed in Java and Haskell and have made the switch to Go some time ago for my current position. I don't miss them - it's just a different way of programming but I've not ran into a problem that I couldn't overcome because they are missing. OTOH, I've shot myself in the foot quite a few times with Generics. Honestly, just _try_ it for longer than an exploratory session. Try to build something big with it, and s…

As a rule I don't learn "trendy" things until the fad period dies off (be it a netflix show, a product, an app, a diet, or a language).

But basically lodash is my bread-and-butter. Could such a library even exist in a language without generics?

Re: Generics aren't ready for Go

#50
Been using Go for 4 years. I totally agree. It sucks to have to use your brain to think about alternative ideas on how to do something. However, I’ve come across much much better solutions to my problems than I would have if Go offered a crutch to my flawed thinking.
Post reply on HN