| > Go was never intended to replace C++ As per the creators of the language who claimed that they got the idea of writing a new language while waiting for C++ to compile, it was. You can read up about this from them, they were quite clear about it. They even expressed surprise as to why they didn't get the migration of C++ programmers they were anticipating to golang, but instead got Python programmers. It's not like the lack of green threads stopped people from writing highly concurrent code. Libraries like Vertx, Reactivex, and Akka have existed for a while now. Also, all major platforms have a notion of green threads/coroutines (Java is getting the former and C++ is getting the latter). This was practically the only thing golang had going for it, and once they're implemented for those platforms, it's hard to make a case for golang given it's bad design decisions. > Hassles with dealing with timeouts exposed flaws in their scheduling and message passing abstractions. That's a good point, which is why Java's green thread implementation is superior to golang's. Timeouts and cancellations are designed in from the start, as well as hierarchies of green threads (similar to Erlang's). Again, it just show's that golang does the minimum, and pushes complexity onto the user under the guise of simple language design. > licensing, tooling, interop, etc, was an extremely poor fit for Linux, and in many ways still is. The JVM is open source and has been for a while now. Could you elaborate on why it's not a good fit for Linux? |
So the future invention of something that doesnt currently exist is going to be better than something that does exist is your argument?