Hacker News Reader

Comment by aikah | Hacker News Reader

> 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.

View on HN

> 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 {
    }

I'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.

You 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.

> 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.

No, it's still type safe (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.

Type assertions happen during runtime, thus using reflections. There is no other way than to use reflections.

Are 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.

You 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.

Java would be a lot nicer to work with had it had generics from the beginning.

That's one of the big problems with adding major features later, the standard libraries don't get rewritten to fully use the new feature.

That's not Java's major problem. It's that generics were implemented using type erasure to stay source and binary compatible with older libraries.

Depends 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++.

C11 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().

Huh? C has had the <tgmath.h> header for 15 years, which lets cos(x) do exactly that, and work on complex types besides.

_Generic makes it easy to implement things like tgmath yourself.

If 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.

>Are generics really that important?

For the kind of work we do in 2014, yes.

For some of the kinds of work we do in 2014, yes. For others, not really; for still others, not at all.

I've been working on juju (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.

> C still doesn't have generics and I never heard anyone complain.

People who would complain already know not to bother using C.

To be more fair, I'd say people using C are not people solving abstract problems that can profit from a generic approach.

C 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.

Reply on news.ycombinator.com