8 ms·

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

• gameswithgo 8y ago
  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.
  • dagss 8y ago
    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.
    • gameswithgo 8y ago
      >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.
      • thethirdone 8y ago
        > 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.
        • int_19h 8y ago
          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.
  • IshKebab 8y ago
    Templates are generics.
    • gameswithgo 8y ago
      They are sort of a superset of generics.
    • int_19h 8y ago
      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.
• nine_k 8y ago
  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.
  • dagss 8y ago
    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?
    • weberc2 8y ago
      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.
• fasquoika 8y ago
  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
  • dagss 8y ago
    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.
• vorg 8y ago
  > 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 !