It continually amazes me that people are willing to put up with Java.
It continually amazes me that people are willing to put up with Java.
Go has a few nice things going for it but its type system was clearly designed by people who stopped paying attention to type theory and compiler design in the late 90's.
By that line of reasoning, C is a great language. Better type systems exist to prevent many types of bugs. That Go ignores decades of good PL research is a valid point of critique.
Instead of beating around the bush, would you care to name a few essential, modern features the type system of Go is missing and which could prevent bugs in everyday programming tasks?
To be read as if chanted by some cheerleaders to a rather bored crowd at this point.
How about starting with old features that it are missing, since Go is literally decades behind PL research?
- Parametric polymorphism (plus constraints e.g. in the form of type classes).
- Algebraic data types
- Pattern matching (with non-exhaustiveness checks).
- Enforcing purity via the type system.
- No null pointers.
No, these are not esoteric Haskell features, but have been around in ML since the 70ies. Also, the claim that Go's designers want to keep the language simple is not a strong argument. A language such as ML is simple.
Also, many old(er) imperative languages adopted some of these type system features, such as Ada, C++, Java, and D.
It's also a bit like working with first-order propositional logic - well-founded and with its own unique simplicity, but you can't say everything with it and have alternatives.
So yes, I'd say that the type system of Go doesn't suck. It's not very good, and there are so many better things out there (rust, I'm looking at you), but it's a long way from being a disaster.
Java as a language though was a primary response to over-correct and over-optimize for secure, correct, safe code based on the history of C's shortcomings. There's are many other lessons that have been learned since.
Java is really hard to beat apart from specialized formal methods verifiers (coq, CVC4), strongly-typed functional languages Haskell and similar derivatives for embedded industrial systems. If you're involved in safety critical systems, you should be using the simplest and easiest to understand formal methods tools as possible. If something's too esoteric, fewer people will be able to double-check the work.
For wider participation, it's a tradeoff to use one of the more popular languages that lack correctness aspects because of the absence of a learning curve.
Go is not in that world. It isn't even in the same star system.