4 ms·
> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of
by aikah 12y ago
> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go
Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive.
Or why expose this interface {} feature and allow people to use it in a statically typed language?
People who chose Go obviously want type checking (along with CSP that makes go so awesome), or they would be using something else.
- mrweasel 12y agoAre generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.
- kasey_junk 12y agoYou can say the same thing about every language feature there is. Of course it is possible to develop software without some particular feature, it's whether the benefits of the feature out way it's costs. With generics, most of the world has decided to land on the side of wanting them. Even golang has them, just not for users.
- TazeTSchnitzel 12y agoJava would be a lot nicer to work with had it had generics from the beginning.
- protomyth 12y agoThat's one of the big problems with adding major features later, the standard libraries don't get rewritten to fully use the new feature.
- danieldk 12y agoThat's not Java's major problem. It's that generics were implemented using type erasure to stay source and binary compatible with older libraries.
- Iftheshoefits 12y agoDepends on what you mean by "important." You noted yourself that "life got easier" once the language you used introduced generics. Generics can drastically reduce the time required to implement features because less time is spent on re-implementing (nearly) identical algorithms for different data structures and more on simply using them to write something that works. The cost paid for this is usually in the form of minor efficiency hits because data-specific efficiencies aren't exploited. Also, consider me complaining about C's lack of generics. It is in fact the primary reason I prefer C++. If C had robust generics with reasonable syntax I'd strongly consider using it instead of C++.
- dalke 12y agoC11 added the _Generic keyword, so someone must have complained. A common complaint is the desire to have, say, cos(x) work on floats, doubles, and long doubles rather than calling respectively cosf(), cos(), cosl().
- stephencanon 12y agoHuh? C has had the <tgmath.h> header for 15 years, which lets cos(x) do exactly that, and work on complex types besides.
- dalke 12y ago_Generic makes it easy to implement things like tgmath yourself.
- jbooth 12y agoIf you read the article, he puts forth a few examples where generics make code re-use possible, where it was impossible before. This not only means less effort, it means fewer bugs.
- coldtea 12y ago>Are generics really that important? For the kind of work we do in 2014, yes.
- AnimalMuppet 12y agoFor some of the kinds of work we do in 2014, yes. For others, not really; for still others, not at all.
- NateDad 12y agoI've been working on juju (http://jujucharms.com http://jujucharms.com) for 18 months and have not missed generics. I have 16 years of development experience in C++ and C#, so it's not like I don't know what they're good for.
- Retra 12y ago> C still doesn't have generics and I never heard anyone complain. People who would complain already know not to bother using C.
- sacado2 12y agoTo be more fair, I'd say people using C are not people solving abstract problems that can profit from a generic approach.
- Pxtl 12y agoC has macros, which allow you to create something close-enough to generics. And as somebody who developed in Java and C# before generics, those languages were awful before those features were added.
- ominous_prime 12y ago> Or why expose this interface {} feature and allow people to use it in a statically typed language? `interface{}` isn't anything special, or something akin to `void*`. Interfaces are a core part of the language, and `interface{}` is just the literal form for an "interface with no methods", which happens to match anything since all types can fulfill an empty method set. It's no different than using this `Something` for exmaple: type Something interface { }
- TheHydroImpulse 12y agoI'm assuming he meant why would they expose or promote the use of a construct that bypasses type safety in a statically typed language. Although `interface {}` is not some sort of special feature, it's still circumventing the type system.
- ominous_prime 12y agoYou don't lose "type safety", as interfaces retain all type information -- you're not casting `void*` pointers (without the unsafe package), and type conversions are limited and well defined. It however does pass the type checking to run-time instead of compile-time, which is a trade-off that some feel is worth the language simplicity.
- TheHydroImpulse 12y ago> It however does pass the type checking to run-time instead of compile-time That's absolutely still loosing type safety. Reflections don't substitute type safety.
- ominous_prime 12y agoNo, it's still type safe (http://en.wikipedia.org/wiki/Type_safety http://en.wikipedia.org/wiki/Type_safety), memory safe, and free of undefined behavior. There's is no way to use a type contained in an interface as the incorrect type (without the unsafe package, but that wouldn't need an interface anyway), or to inadvertently access or modify arbitrary memory. I also wouldn't consider Go type assertions to be in the same class as reflection. A type assertion is the way you extract and check the underlying type from an interface, and is quite common even when using more complex interfaces. There's also no way to make use of the underlying type from an interface without first asserting it as that type.