If rationality were a requirement for progress, progress wouldn't exist. The beautiful fact of evolutionary processes it's that rationality is not necessary. But I digress...
Needs change with time. In the current context, if Go is an improvement in some tech areas I think it will get some degree of success. Otherwise I think will decline after the first hype.
By the way, I agree with you about writing more code to overcome language limits. The hope here is that using idiomatic Go you will end up, no matter what, with a reasonably understandable code base, even for libraries and tools. It's a goal, I don't know if reachable or not.
I think the language that wanted "to rule them all" was C++, and we all know how it ended.
C++ can be procedural, oop, functional, you have metaprogramming, generics, everything. Everything. C++ is everything. Every pattern, every design philosophy can be implemented in C++.
How much time does it take to compile? How many developers do know every C++ feature and pattern?
I like Javascript. I don't see any problem with the language itself. I see problems with the browser ecosystem as a whole, but that's another story.
I understand the argument "popular != good", but I think that if in the long term a tool raises in popularity this is not random.
There should be reasons for that.
I don't think the whole industry chooses its tools randomly. I think that in the long term, if a tool emerges from the dust it's because of some actual reasons.
If the simplicity of Go will win against the complexity of Rust, for example, I think we should think about the reasons.
In my opinion the problem it's not about Go limits, but instead is about our perspective as developers using our tools. We do really need complexity? We do really need oop everywhere?
If the answer will turn out to be "no", I will need to change my attitude toward Go.
And this is a clever response if you understand their point: messing with the language it's rarely the correct answer.
Do you want to remove some code? How about a function? How about hiding boring details behind more elegant objects? How about using a macro in the editor? And so on...
The answer is not (from their perspective) "put some shit in the language".
The problem with Go is that is very idiomatic. If you want to work with Go you need to learn its way, and somehow you need to accept the trade-offs behind its design.
If you do not see any advantages in any way, probably it's not the right tool for you, and that's ok. No problem at all.
I'm pretty sure at Google they know why they created Go, why they're using Go, and so on...
The assumption that Google reviewers had something against goroutine puzzles me a bit.
Maybe the problem was not about goroutines, but about how they were used... I don't know, I'm guessing...
For example the C++ templates rules are themselves a turing-complete language.
If by generics you meant some really basic features, I think you can do pretty well with interfaces. They're already in the language.
If by generics you meant the full-package, i think you could end up with something pretty complex all the time.
I think that if you begin with the idea that you have multiple conventions and you cannot avoid that, therefore you won't solve the problem with "+" operator.
You have just one more convention.
Type 1 defines: .add(x),
Type 2 defines: .plus(x),
Type 3 defines: operator+,
...
If you assume that you can convince people to adopt a convention, you can use .add(x) and avoid the problem in the first place.
Go for example tries to have always one obvious way to write things. The Go standard library it's the idiomatic Go bible.
About generics, this is highly debatable. This is a design choice, it's not a decision made by accident.
You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple.
Simplicity it's the most wanted feature of Go, from the designers perspective, I think.
In the long term it's preferable to have explicit and simple code, instead of complex magic.
This is a correct view? We'll see.
Honestly I'm starting to appreciate that. They may have a good point.
Mmmm I'm puzzled. I don't think we are consulting the same community... Goroutines are everywhere in all the main go projects. Goroutines and channels are one of the main reasons Go exists.
Moreover, the simulation speed would not be related with any "speed" inside the simulation. If the processing speed decrease, the simulation will be slowed, but inside nobody would possibly notice it. If you stop the simulation, everything is stopped, anybody would be "frozen", and there's no way to detect something like that inside the simulation.
I think this article is a little bit naive. Google sent the email during IO, because the overwhelming flow of Google news simply obliterates any other news. Nobody cares about a Window Phone app while we are talking about new Android Studio, new Google Map, new G+ interface, new Gmail features, new apis, etc... "Microsoft violated YouTube license? Bad for them, now move on and let's talk about Android game development with Google Play Games".
The trap it's defused.
I think most of you guys missed the point. Writing tests is very important WHILE writing code, to write it better.
We MUST write tests not only to catch regressions, to be sure that certain invariants will be manteined. But we write tests to check if we are writing good code.
I need to write a class to do some stuff. The test is the first user of this class. If I cannot write the test very fast, and I see that I'm spending a lot of time doing it, this means that my class is poorly designed, is not flexible, is not very reusable. Maybe I'm doing something wrong with my app design. If I'm writing good code, reusable and clean code, testing is easy and fast.
Testing help me to check immediately what's going wrong with the code, not only in term of bugs.