gendoikari

I'm probably missing the use case. What is the problem that you are thinking of, you can't solve with a Go interface?

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 didn't mean that. I meant that in the next years we'll see if some design decisions were bad or wise.

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.

What do you think about goroutines and channels?

We'll see in the next few years... We'll see...

Overall, it's a good thing. Flash is a proprietary technology from the past. Lets move on guys...