> A Good Solution: Constraint Based Generics and Parametric Polymorphism
> A Good Solution: Operators are Functions
> A Good Solution: Algebraic Types and Type-safe Failure
> A Good Solution: Pattern Matching and Compound Expressions
People have tried this approach. See languages like C++ and Scala, with hundreds of features and language specification that run into the thousands of pages.
Go was created by the forefathers of C and Unix. They left out all of those features on purpose. Not unlike the original C or the original Unix, Go is "as simple as possible, but no simpler".
Go's feature set is not merely a subset of other langages. It also has canonical solutions to important practical problems that most other languages leave do not solve out of the box:
* Testing
* Documentation
* Sharing code and specifying dependencies
* Formatting
* Cross compiling
Go's feature set is small but carefully chosen. I've found it to be productive and a joy to work with.
You seem completely ignorant of the things you're attempting to talk about. Scala doesn't have "hundreds' of features, nor is the language specification thousands of pages. It's just an outright fabrication to say so.
>Go was created by the forefathers of C and Unix.
Yeah, and it's obvious (and sad) they ignored the last twenty years of PL research and progress.
>They left out all of those features on purpose
Did they? I don't believe this is the case, as I've heard from the creators many times that they want to add generics but haven't figured out the details yet.
Are you really going to sit here and argue that static typing is important EXCEPT for when working with collection? That parametric polymorphism doesn't make things simpler?
Of the 4 you mentioned (Constraint based generics and parametric polymorphism, operators as functions, algebraic types and type-safe failures, and pattern matching/compound expression) C++ really only has 1 (operators as functions).
>with hundreds of features and language specification that run into the thousands of pages.
This describes neither Rust nor Haskell.
>Go is "as simple as possible, but no simpler".
It has mandatory heap usage, garbage collection, green threads. It's more than generous to call that "as simple as possible".
Of the 5 features you mention that Go has "canonical solutions" to (in the form of external tools), I know off the top of my head that Haskell's Cabal takes care of at least 4 of them. I'm not sure about formatting. Rust probably has similar tools, or if it doesn't, they can certainly be added without changing the language.
The newly released 'cargo': http://crates.io/https://github.com/rust-lang/cargo/ (alpha, but quickly improving). This will be Rust's cabal equivalent, almost certainly with support for generating documentation and cross-compiling (it already has basic support for running the tests described above).
(Well, to be precise, the compiler has the '--pretty normal' option, but it's not so good. https://github.com/pcwalton/rustfmt is the work-in-progress replacement.)
* Cross compiling
Already supported, although it requires manually compiling Rust with the appropriate --target flag passed to ./configure, to cross-compile the standard library.
The Scala specification is two hundred and something pages, around a third the length of the Java specification (largely because Scala has, in some sense, fewer features than Java, in the sense that Java has lots of edge cases with their own special handling, whereas Scala has a smaller number of general-purpose features. The complexity comes because it's easy to use all of them at once)
I get what you are saying, but why convolute C++ and Scala? One is a horribly designed complex language with macro-like templates rather than modular parametric polymorphism. The other is much more well designed but, as you say, still complicated. You could have stayed at Scala without degrading into a comparison with C++, which is a universally kicked dog anyways.
It is possible to do type parameters in a way that is simple yet effective. But I can understand why it wasn't done this early in Go's lifetime, especially since Rob Pike isn't exactly well into generics (vs. Odersky's experience with Java/Pizza).
> A Good Solution: Operators are Functions
> A Good Solution: Algebraic Types and Type-safe Failure
> A Good Solution: Pattern Matching and Compound Expressions
People have tried this approach. See languages like C++ and Scala, with hundreds of features and language specification that run into the thousands of pages.
For an unintentional parody of this way of thinking, see Martin Odersky's "Scala levels": http://www.scala-lang.org/old/node/8610
For additional hilarity, note that it is an undecidable problem whether a given C++ program will compile or not. http://stackoverflow.com/questions/189172/c-templates-turing...
--
Go was created by the forefathers of C and Unix. They left out all of those features on purpose. Not unlike the original C or the original Unix, Go is "as simple as possible, but no simpler".
Go's feature set is not merely a subset of other langages. It also has canonical solutions to important practical problems that most other languages leave do not solve out of the box:
* Testing
* Documentation
* Sharing code and specifying dependencies
* Formatting
* Cross compiling
Go's feature set is small but carefully chosen. I've found it to be productive and a joy to work with.