"unless your new language/runtime is so revolutionary that it reduces development cost dramatically, fracturing the ecosystem is often too high a price to pay for merely a "nice" improvement. "
I agree. Yet I do think both Rust and Go will probably end up meeting the standard.
Go is a great alternative from a technical standpoint from Java. For a Python(2) user like myself, there's a lot of improvements but how easy it is to get started has replaced Python3 with Go for myself when I'm ready to move on someday. For me to make that judgement tells me boring old Go did simplicity as a feature correctly. Rust may also live up to the hype, but more for the C(++) usecases.
Both Java and C++ were getting quite long in the tooth and I feel Go and Rust respectively offer enough to move away from the former two in time.
> Go is a great alternative from a technical standpoint from Java
What? It doesn't require warmup -- that's why it's great for short command-line apps but other than that? It's slower than Java, doesn't have anywhere near the same level of deep monitoring, doesn't have any live code loading capabilities, and has really bad interoperation with other languages. I use it when I need a simple script to run faster than Python, but a Java replacement??
> Both Java and C++ were getting quite long in the tooth
I don't know if you're aware, but OpenJDK's JVM is not only the most advanced runtime environment around by a longshot, but the one that's moving fastest with some really incredible research that's gradually finding its way into production. Even Google is putting more effort into improving OpenJDK than into Go. The JVM is much more modern (in terms of new code and concepts being integrated into it) than Go (whose runtime is almost primitive by comparison).
Go is a great solution for that middleground between a script and a "heavyweight" application, but let's not compare its power to that of the JVM. It is a nice tool -- with excellent beginner friendliness -- but it doesn't offer any technical breakthroughs.
As to Rust vs. C++ -- I'm hopeful, too, but like I said, there's no we can know how big its impact is until it's been used by several organizations in production for quite a few years yet.
" It's slower than Java, doesn't have anywhere near the same level of deep monitoring, doesn't have any live code loading capabilities, and has really bad interoperation with other languages. "
Curious, what projects have you worked on where Go's runtime performance was slow, requiring a Java rewrite?
Link to your scrapped repo or didn't happen.
" I use it when I need a simple script to run faster than Python,"
Same thing, source to a situation where Python was too slow and it necessitated a Go rewrite for you?
"OpenJDK's JVM is not only the most advanced runtime environment around by a longshot,"
Most advanced for memory usage? I'm not sure what your point is about being "advanced". MIT theory at it's worst.
"but let's not compare its power to that of the JVM"
Why not? JVMs are overengineered piles. Simple is better.
"It (Go) is a nice tool -- with excellent beginner friendliness -- but it doesn't offer any technical breakthroughs."
And thank Zeus it doesn't. I think I've had enough "technical breakthroughs" with OpenJDK's JVM, Node.js and whatever else is being sold today.
Few are building new product on Java, other than those already entrenched. Android is the biggest draw and once Go is a 1st class citizen there, expect the life to be sucked out. Even with OpenJDK's JVM being the best thing since sliced bread.
I don't think you know what JVMs do if you think they're overengineered. Go's "simplicity", while great for small apps, means we don't get anywhere near the same level of monitoring we get with Java, slower performance (though not a dramatic difference), and much less flexibility (no polyglotism, no hot code swapping, no dependency-conflict resolution) -- not that you should notice the JVM's "overengineering" if you don't need it. Besides, everything is overengineered until you need exactly what it's engineered to do. A helicopter may seem "overengineered" if all you need is a car, but if you need a helicopter, then a car may be seriously lacking. In the case of JVM vs Go, if you need large data sets in memory, interesting concurrent data structures (even concurrent hash maps), or even if you need to know exactly what your server is doing -- the JVM doesn't seem so overengineered any more. As to new projects being written in Java vs other platforms (Go included), you have no idea what you're talking about. All of Android doesn't even amount to 5% of Java developers.
I agree. Yet I do think both Rust and Go will probably end up meeting the standard.
Go is a great alternative from a technical standpoint from Java. For a Python(2) user like myself, there's a lot of improvements but how easy it is to get started has replaced Python3 with Go for myself when I'm ready to move on someday. For me to make that judgement tells me boring old Go did simplicity as a feature correctly. Rust may also live up to the hype, but more for the C(++) usecases.
Both Java and C++ were getting quite long in the tooth and I feel Go and Rust respectively offer enough to move away from the former two in time.