4 ms·

The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics. Most useful typesystems wi

by fpoling 10y ago

The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics. Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code with less things to learn.

bad_user 10y ago
> One can say exactly the same about generics No, it's the same language with a bigger vocabulary and grammar, on which everybody agrees. And generics can be quite sane, as exemplified by the languages in the ML family, which have been around for decades. Java also didn't have generics. They added them eventually, much later in version 5, but then due to backwards compatibility concerns they added them with invariance at the declaration site and complex wildcard rules at use site. So the irony of this situation is that Go will add generics, it's inevitable for a (quasi) static language once it grows in usage and ecosystem. But when they'll do add those generics, they'll be broken due to backwards compatibility concerns, becoming yet another counter example for generics, picked up by the next Go / Java that will reinvent the wheels again.
- fpoling 10y ago
  The ugliness of Java generics comes from type erasing. It allowed to stay compatible with JVM. Go has no such restrictions and I do not see why a truly minimal generics in a style of Virgil cannot be added to Go at some point.
  - bad_user 10y ago
    No, type erasure is actually an (unplanned) feature, because it didn't cripple the runtime for other languages. On this one people miss the forest from the trees. dotNET type reification is about introducing runtime meta-data and checks, which you only need when your type system is not strong / expressive enough, which makes you want to do `isInstanceOf` checks. Well, guess what, needing to check that an instance is a List<int> is a failure of the language ;-) This issue is also mixed with specialization for primitives. But that's actually unrelated because you don't need reification to do specialization. And actually you don't need runtime support either, as specialization can be compile time. Also, in actual practice with Java, type reification is only a small usability issue. The real clusterfuck have been those wildcards for expressing use-site variance. > It allowed to stay compatible with JVM. Go has no such restrictions That's circular logic, given the JVM release cycle is tightly linked to Java the language and has had evolved in response to new features of Java. No, the actual reason was to preserve compatibility with older code that weren't using generics (e.g. List vs List<int>) without forking the standard library in pre- and post-generics functionality (like .NET has done). Go will have exactly the exact same problem.
    - kuschku 10y ago
      Luckily, Java’s generics are actually changing with Java 10 towards a more powerful system even. It’s disappointing how Go, in every way, is just Java 2 with a handful of additional libraries. Simply using Java 2, adding some libs, and compiling with GCJ would net the exact same binaries, with far less work.
camus2 10y ago
> With code generation I can program my types using the same language I use for code with less things to learn. With code generation you are introducing your own compiler, DSL and all that bullshit that becomes yet another dependency you have to manage. That's busy work, that's bureaucracy, that's brittle. Now your codebase depends on pragma statements, manifests and obviously a specific syntax that aren't even managed by the default compiler, that's the opposite of simplicity. At least C has standard macros, and most developers uses the same syntax for them. Go is an extremely divisive language, a fact which will hinder its adoption as criticism of that language will get harsher since more people get exposed to it. The good thing is, as Google relies more and more on Go, peer pressure from other googlers might force changes in the language.
- fpoling 10y ago
  In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics.
  - camus2 10y ago
    > In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics. You answer addresses none of the points I was making. Your custom DSL is something you have to maintain on your own, and it obviously yet another thing that fragments the go community. Imagine if C had no macros and everybody would use its own pre-processor that you need to download before compiling a C lib. Go is exactly in the same situation. It's obviously "not a feature", nor simple, nor readable, nor smart, nor practical.
rbehrends 10y ago
> Most useful typesystems with generics are Turing-complete. The easy solution for that is to put parametric polymorphism in the module language, not the type system. ML, Ada, Modula-3 all did it successfully.

by fpoling 10y ago

bad_user 10y ago

> One can say exactly the same about generics No, it's the same language with a bigger vocabulary and grammar, on which everybody agrees. And generics can be quite sane, as exemplified by the languages in the ML family, which have been around for decades. Java also didn't have generics. They added them eventually, much later in version 5, but then due to backwards compatibility concerns they added them with invariance at the declaration site and complex wildcard rules at use site. So the irony of this situation is that Go will add generics, it's inevitable for a (quasi) static language once it grows in usage and ecosystem. But when they'll do add those generics, they'll be broken due to backwards compatibility concerns, becoming yet another counter example for generics, picked up by the next Go / Java that will reinvent the wheels again.

fpoling 10y ago
The ugliness of Java generics comes from type erasing. It allowed to stay compatible with JVM. Go has no such restrictions and I do not see why a truly minimal generics in a style of Virgil cannot be added to Go at some point.
- bad_user 10y ago
  No, type erasure is actually an (unplanned) feature, because it didn't cripple the runtime for other languages. On this one people miss the forest from the trees. dotNET type reification is about introducing runtime meta-data and checks, which you only need when your type system is not strong / expressive enough, which makes you want to do `isInstanceOf` checks. Well, guess what, needing to check that an instance is a List<int> is a failure of the language ;-) This issue is also mixed with specialization for primitives. But that's actually unrelated because you don't need reification to do specialization. And actually you don't need runtime support either, as specialization can be compile time. Also, in actual practice with Java, type reification is only a small usability issue. The real clusterfuck have been those wildcards for expressing use-site variance. > It allowed to stay compatible with JVM. Go has no such restrictions That's circular logic, given the JVM release cycle is tightly linked to Java the language and has had evolved in response to new features of Java. No, the actual reason was to preserve compatibility with older code that weren't using generics (e.g. List vs List<int>) without forking the standard library in pre- and post-generics functionality (like .NET has done). Go will have exactly the exact same problem.
  - kuschku 10y ago
    Luckily, Java’s generics are actually changing with Java 10 towards a more powerful system even. It’s disappointing how Go, in every way, is just Java 2 with a handful of additional libraries. Simply using Java 2, adding some libs, and compiling with GCJ would net the exact same binaries, with far less work.

camus2 10y ago

> With code generation I can program my types using the same language I use for code with less things to learn. With code generation you are introducing your own compiler, DSL and all that bullshit that becomes yet another dependency you have to manage. That's busy work, that's bureaucracy, that's brittle. Now your codebase depends on pragma statements, manifests and obviously a specific syntax that aren't even managed by the default compiler, that's the opposite of simplicity. At least C has standard macros, and most developers uses the same syntax for them. Go is an extremely divisive language, a fact which will hinder its adoption as criticism of that language will get harsher since more people get exposed to it. The good thing is, as Google relies more and more on Go, peer pressure from other googlers might force changes in the language.

fpoling 10y ago
In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics.
- camus2 10y ago
  > In Go one can use template library to add custom generics using already known syntax. Essentially it will be Go source with familiar template annotations. Surely it is still a non-standard language, but the setup is trivial and extra flexibility of custom DSL may suits some projects better than hypothetical Go-with-generics. You answer addresses none of the points I was making. Your custom DSL is something you have to maintain on your own, and it obviously yet another thing that fragments the go community. Imagine if C had no macros and everybody would use its own pre-processor that you need to download before compiling a C lib. Go is exactly in the same situation. It's obviously "not a feature", nor simple, nor readable, nor smart, nor practical.

rbehrends 10y ago

> Most useful typesystems with generics are Turing-complete. The easy solution for that is to put parametric polymorphism in the module language, not the type system. ML, Ada, Modula-3 all did it successfully.