Hacker News Reader

Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others.

There is scope for legitimate criticism of language design based on the expressive power^1 of their features.

In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it.

1. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...

You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature.

When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.

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

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

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.

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

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.

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

The big thing people miss is that while lack of generics might cost them effort worth X, other Go features benefits them Y. The value of Y is pretty large in case of Go, when it comes to concurrency and language level simplicity. It's hard to go wrong in Go.

Whoever designed Go seems to have some experience debugging and maintaining large concurrent systems.

When you design a language, you have to be so careful of things you add. Because otherwise you get C++ (or one of those cute let's-add-all-the-features-we-can-think-of scripting languages). In good and in bad. You can't remove features afterwards, so better not add a feature you can't get right from the beginning.

Nobody is saying Go should rush to implement generics or any other feature.

The issue is more the dismissive attitude towards them.

Citation needed please. Ian Lance Taylor, a core member of the Go team has revised and replied to many of the generics debates on go-nuts.

> This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1.

Isn't that extremely sad though? We finally have a perfectly precise tool, yet we keep building gooey piles of uncertainty on top of it.

Sure we're just imperfect humans, but that is what compilers and tooling are for - to point out our mistakes and help us get it right

I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything.

> I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything.

Unfortunately, they won't. These problems are not a 'bug' of current languages, but the inherent nature of the problem. At some point, the perfectly precise world of computers has to meet the messy world of user requirements. As a programmer, my job is to translate one into the other, within the constraints applied by whoever is paying the bill.

Well right now the messy world of user requirements meets the even messier world of legacy languages and poorly behaving libraries. I'm not under any illusions that the first part would change; my hope only pertains to the second part.

For example, the behaviour of null/nil references in most typed languages mentioned in the article has nothing to do the inherent nature of messy user requirements. Same goes for the lack of sum types: infact they're perfect for modelling messy requirements, much better than simulating them with structs and forgetting a check somewhere (I'm just parroting the article here)

These issues aren't caused by messy requirements but by messy leftovers from legacy languages. Thats fine too, nobody expects us to get it right the first time: but that was 40 years ago and repeating the same mistakes in languages made in 2009 feels really sad.

I half agree. While new programming languages will make solving today's problems easier, there will be new problems that they won't solve, and so in 20 years people will be moaning about the problems the contemporary languages don't solve.

For example, one of the biggest problems with building websites ten years ago was that you had to slice everything into tiny images because of table-based layouts. Now we've got CSS3 with SASS and Compass and that's no longer a problem. But whereas then, 90% of users were using IE6 on a 15 or 17 inch monitor, now my users are on a multitude of browsers and screen sizes.

If your language is versatile enough, has adaptable syntax, and powerful at DSLs, it can adapt to future requirements quite well.

Haskell is great at concurrency and parallelism not because the language was designed around those at all - but because the language is well designed, and focuses at communicating the programmer's intent, rather than implementation details. This intent is more directly translatable to correct concurrent code than an imperative spec which is inherently lower-level.

> my solutions to the underlying problems are fragile ... This is the nature of our business

I think this is a mistake. A lot of business is run this way, though.