I don't think Go has simple or minimal language design. It has a lot of special cases and hard-wired solutions to problems, rather than elegant features fitting together well. It's the opposite of having small, reusable solutions to problems like composability of *nix utilities.
Conversation
The spirit of Go is hard-wiring special-cased features into the language, in a way that programmers cannot implement themselves. The Go designers can make generic types like arrays, slices and maps, but you can't. They can do product types (multiple return values), but you can't.
1
2
10
It's hostile towards code reuse and programmers. It's deliberately bad, and aimed at what they think fits the lowest common denominator, but I don't think it succeeds at that. The language not providing solutions doesn't make the problems go away. Sometimes worse is just worse.
1
5
9
The features it has are awkward to use together and don't compose well. It's everything that they claim is bad about languages with good type systems. Interfaces end up being awkward and force a lot of boilerplate and repetition. Those are so close to being great, but they fail.
2
4
5
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.
1
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.
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
Show replies