It's important to remember how simple Java was in 1999. 10-15 years from now it's likely Go will have all the features that people have been asking for. The earlier these features are added the better. As a project gets larger it gets much harder to make large changes. Do it now and while they're at it they should fix the lack of good exception handling and a few other things that they will most likely have to address eventually.
10-15 years from now it's likely Go will have all the features that people have been asking for.
If this hapoens, the entry bar will be high again. The tooling will get slow, and runtime will become more complex.
To me, Go is all about that simplicity that comes with the lack of features. Though I think it can probably provide a little more in terms of generics, it also has to be careful not to become Nim or D.
Comments
It's important to remember how simple Java was in 1999. 10-15 years from now it's likely Go will have all the features that people have been asking for. The earlier these features are added the better. As a project gets larger it gets much harder to make large changes. Do it now and while they're at it they should fix the lack of good exception handling and a few other things that they will most likely have to address eventually.
What will distinguish Go then? From say Nim, D, Rust, OCaml, Haskell, etc?
Better runtime and tooling plus lower entry bar hopefully.
Pervasive custom generics will raise that entry bar significantly.
Why? It doesn't have to be the mess java generics are. Just look at scala. Well, don't dig too deeply
If this hapoens, the entry bar will be high again. The tooling will get slow, and runtime will become more complex.
To me, Go is all about that simplicity that comes with the lack of features. Though I think it can probably provide a little more in terms of generics, it also has to be careful not to become Nim or D.