Hacker News Reader

Comment by dagss | Hacker News Reader

I am disappointed that go seems to follow Java and C++ with generics support instead of taking a more LISP-like turn like e.g. Julia.

I would much rather have powerful hygienic compile-time macros to generate code. Then I would have the power to do all thay generics does but also a lot more.

Just having those powers at compile time evaluation would be rather good, don't need to go all the way to Julia/Lisp.

We know what mess C++ became, with people abusing the template system to do compile-time metaprogramming. Much better to simply provide a good macro system.

View on HN

generics are immune to much of the mess that templates cause. It is a somewhat different thing. They are also less powerful, but that is fitting with Go's desire to avoid language constructs which let people make really confusing code, I think.

If you want cool meta programming abilities, there is Rust, Nim, Lisp, Julia, F# and others to choose from. No need for Go.

By that logic, then currently, if you want cool generics abilities, there is Java for you. No need for Go.

But then there's this spec for generics, so obviously one wants to develop Go further. And I think it's a valid question why generics in particular is chosen instead of other ways of solving the same problem.

>By that logic, then currently, if you want cool generics abilities, there is Java for you. No need for Go.

Java has one of the least good generics implementations of modern languages. I suggest C#, or even better, F# if you want to make heavy use of them =)

Generics compared to templates keep the language simpler, solve the most common cases of code repetition, and can easily provide good error messages and runtime performance.

> Java has one of the least good generics implementations of modern languages. I suggest C# ...

What are the particular differences that make you suggest C# over Java generics? As far as I am aware they are nearly identical for practical use (as language constructs). Things like Java using type erasure don't actually affect the language much only the particular compiler implementations.

They affect the language a lot in non-trivial applications. For example, you can't implement the same generic interface with different type parameters, even when it is perfectly meaningful: suppose we have an interface Convertible<T> that objects that can be converted to T should implement - why can't an object implement Convertible<int> and Convertible<string> at the same time?

Ditto with overloads - suppose you have a family of functions like frob() that apply to ints and doubles - so there's frob(int) and there's frob(double). So far, so good. Now, you want to add helpers to do the same for collection - and so there's frob(Iterable<int>) and frob(Iterable<double>)... except that doesn't work, because you can't overload on a generic interface, since the method signature has that information erased entirely.

And then, of course, it breaks Reflection. Which is not so common in application code, but has many valid uses in the libraries.

Templates are generics.

They are sort of a superset of generics.

They're in that weird middle ground between macros and generics, but arguably still closer to macros. The original pre-Standard C++ templates were pure macros. Then two-phase lookup was added in C++98, which muddied the water.

What is the type safety story of the macro-based Lisp-style code generation?

Macro-like code generation is what the compiler does when it processes type-parametrized functions. It's more restricted that way, but it also prevents type-unsafe macro expansions due to mistake.

I am not sure if I understand your question. If a macro expansion violates typing rule then you get a compile time error of course.. is it a question about the quality og error messages?

Crafting good macro error messages is really hard. Naively, they point into the expansion which is user-hostile. It's a fair bit easier (though still difficult) with certain implementations of generics.

> I would much rather have powerful hygienic compile-time macros to generate code

There's still a place for this, even in a Go with the proposed generics.

There's 3 main styles of generics, each with different speed/space trade-offs:

* use interface{}, which runs slower and has no compile-time checking, but can be faster to code

* use the proposed type-safe generics compilation, which generates compact code, but which require more detailed coding

* use the hygienic compile-time macros, which run fast, but can generate lots of bloat when compiling

There's a place for all three being available. So perhaps Go 2 will get macros one day !

I don't really understand your example. Julia has both macros and builtin parametric polymorphism. Unless you expect user code to implement its own type system (technically possible, e.g. Racket does it), then macros aren't a solution to the same problem as generics

If I could do

SortSliceOfIntFunction := MakeIntSorter!(int)

...then I would not need generics to sort a slice of ints. I just generate code that I would have written without generics to implememt the case for ints.

You need to instantiate for all cases you need manually... but today we are using go without generics entirely and it sort of works.

I agree it is not the same.

Reply on news.ycombinator.com