Welcome to the world of languages with type systems that don't suck. It's going to be a fun ride, and if you think this is cool, you're going to be really excited by the other languages we've got in here.
It continually amazes me that people are willing to put up with Java.
If you are putting Go in the category of languages with a type system that doesn't suck, you probably need to study more languages.
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.
I wouldn't say it's exactly brilliant - but it's just missing all the really cool stuff, rather than being buggy. It does what it's trying to do, and then stops. It's a bit like C in that regard (and unlike C++, Java, and C#, which tried to do something much bigger and didn't get it right).
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.
Go's type system stays out of the way and adds some useful amount of safety. That's more than I can say of any mainstream language. No reason to tear it down just because it doesn't go further.
Go's type system stays out of the way ... No reason to tear it down just because it doesn't go further.
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.
> 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?
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.
Yes, most of these things are pretty old. Why can't you accept that there are people out there who do not think that these features are unequivocal good ideas or necessary?
I am pretty sure Rob Pike does not fall into that category. My impression is that he is not all that familiar with these features from the ML-derived family of languages. Do you have a quote from him to the contrary (where he specifically rejects these features)?
The Oracle JVM is pretty versatile and has been beaten on in production on an extremely large scale, as much as M$ CLR.
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.
It continually amazes me that people are willing to put up with Java.