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…
Generics aren't ready for Go
41–50 of 238 posts
Re: Generics aren't ready for Go
#42> 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'…
Re: Generics aren't ready for Go
#43The 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
#44I 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
Re: Generics aren't ready for Go
#45Earlier 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.
> 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
#46I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.
Re: Generics aren't ready for Go
#47This 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…
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
#48I don't understand how not having generics is at all acceptable. But maybe that's because I come from a functional programming perspective.
Re: Generics aren't ready for Go
#49I 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…
But basically lodash is my bread-and-butter. Could such a library even exist in a language without generics?