I certainly agree with the Go designers about a lot of what is bad and should be left out of the language. The problem is that what they have left is not a good language. I don't want a larger language, but definitely a far more expressive and substantially better designed one.
Conversation
Go interfaces are almost type classes. Drop reflection / dynamic casting / runtime typing. Add type parameters, and allow using interfaces as bounds on them for static dispatch via interfaces. Drop tons of hard-wired special cases due to that. Basically, apply some good taste...
1
1
2
I like the general concept behind Go, just not what they actually created. If they had been deeply familiar with ML family languages, I think there's a very high chance they would have created a language that I'd think is great. It's so close in a sense, yet so far in practice.
2
1
2
I followed development of Go from the announcement, and I'm very familiar. I made the mistake of choosing it for some projects and have written a fair bit in it. The language design cripples library design so much too, so despite a lot of great library design, they're not good.
1
1
3
Drop multiple return values and have proper tuples. Replace UTF-8 by convention with real UTF-8. Make pointers non-nullable and replace null with sum types (compiler can still use null). Remove switches, and provide pattern matching instead. Remove lots of more hard-wired stuff.
1
1
4
it sounds like you basically want to use Reason with Core (since Core makes a point of avoiding exceptions, and I don't think they use classes anywhere)
1
1
(typeclasses, well, there's modular implicits, but I don't know when or if they'll be upstream. it's taking a while, but multicore is also taking a while in spite of being actively worked on, and that's just how OCaml is, I guess...)
3
Strictly speaking, type classes are not really that modular since you have to deal with the possibility of orphan instances, and AFAIK there is no good solution for this problem.
1
I don't think orphan instances should be permitted at all. Rust doesn't permit them. Go doesn't permit defining new methods at all. Go's interfaces are just based on method naming rather than there being explicit implementation so that wouldn't really be an option for it at all.
1
I don't see how orphan instances (or the lack of them) makes type classes not modular... it's just like saying sum types aren't modular because there's a limited set of possible variants, rather than it being open to extension like using type classes as objects or inheritance.
1
Not having things open to extension is a valuable design decision. I'll gladly choose a language where privacy, immutability, preventing inheritance, etc. are default and extension methods can't be added without having either type or type class being implemented in the library.