Reflection and dynamic casting are language features that I dislike even more than exceptions and class-based inheritance, and Go forces people to lean on those even more than a language like Java infested with it. I'm really not a fan of approaches it takes nearly all around.
Conversation
My idea of a good programming language is an ML-based language with type classes. OCaml without object orientation and with their type-generic modules replaced with type classes is pretty much what I want. No class inheritance, no exceptions, no reflection / runtime typing, etc.
1
1
6
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.
1
1
5
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
I am curious how these languages "without exceptions" (of any sort) manage failures of the language's abstract machine (eg, allocation failure and other run-time errors). Go has an exception (panic) and a slightly devious way to recover it.
1
Go doesn't truly handle allocation failures. Also, in a high-level language, I want thread-local heaps and automatic resource management not only automatic memory management. I don't believe in invisible control flow with hidden and rarely if ever tested code paths everywhere.
For a low-level language with meaningful out-of-memory handling, I think Rust's approach to error handling is fine. The issues I have with Rust are really with the standard library. Disabling it via the attribute and using only the core standard library avoids unwinding, etc.
1
I think that's the main issue with it: for many truly compelling use cases, where you actually want a low-level language, a lot of the standard library isn't suitable. It's nice there's a core standard library for use in a kernel, C ABI library, etc. but there should be way more.
1
1
Show replies