It's also a necessary "evil" to demonstrate that languages should have the right amount of features, no more and tools are part of a language, along with ease of deployment. It's is questionable whether Go strikes the right balance when it comes to features vs "simplicity" though, but it might inspire better solutions in the future. I think MSFT is trying to follow the same path with .net core and its tool chain, I hope they succeed as C# and F# are vastly superior to Go.
>I hope they succeed as C# and F# are vastly superior to Go.
In number of features, yes. Everything else and you come off as opinionated. I cannot comfortably write C# from my Linux workstation since all the tools are Windows-first.
C# is a language where everything must be done in classes and inherits a C++/Java school of OOP which I find abhorrent as it tends to favor monstrosities of abstraction upon abstraction. I can almost always read a Go codebase and get a good general sense of what it's doing in a few minutes, I can't say the same about C# codebases, and I have worked with C# for around the same time I've worked with Go.
These things aren't clear cut for everyone the same way.
I wrote C# professionally for 7 years. IMO, it's in almost way inferior to Go:
* requires a separate and quite heavy run-time
* still too windows-centric
* Enforces a class-based OOP style
* Functional programming elements feel very tacked-on
* Feels heavier, slower, more bureaucratic
* The async/await Task-based concurrency features are still not as flexible as Go's concurrency.
I find Go much more light-weight, easer to get into, enjoyable, and fun. So, how exactly is C# "vastly superior" to Go?
The semantics of Go are fine for the most part. My only problem with Go is manipulating slices. The rest is just awesome and it requires a lot of taste to simplify semantics without taking away the languages power.
