Replying to my own post because it's too late to edit and I'd like to clarify a bit.
I actually do agree that as software engineers, we're often a bit too eager to reinvent wheels. While I am not a huge fan of Java, if I owned a company, I would probably be more likely to use a JVM language (probably Clojure) than I would to use something like Haskell or Idris, precisely for the reasons you've discussed.
My overall point, though, is that often times languages themselves lag behind the state-of-the-art; there's been a lot of progress made in language design, and Java (and a lot of other languages) can feel crufty in the process. Sometimes the wheel really does need to be reinvented...if we could somehow convince the entire industry to use Lisp, this would (arguably) be a non-issue, since they allow you to abuse macros relatively easily and add language features (see CLOS or core.async for examples), but Lisp hasn't really taken over the world like I wish it would.
Thanks for your two posts, I agree with pretty much all of what you're saying.
When you look at the millions of man-hours that have gone into the "burn it all down and start from scratch" languages (Go, Rust, etc) and you consider what if those guys had written new compilers for JAVA syntax? How great that would be. They could still accomplish many Go and Rust objectives without having to completely invent their own non-Java-like syntax. Even something that was "Java-like" is better than burning it all down every time something new is needed.
I don't think I agree with your last point; I actually think that the Java syntax isn't particularly great, even for the time. I don't think that Java's idea of object oriented design is ideal (I'm more of a fan of the ObjectiveC/SmallTalk model), and that version of OOP is all Java really contributes from a syntax perspective...otherwise it's largely just C/C++'s syntax.
However, in a sister thread I think you mentioned that you are basically alright with languages targeting the same VM, which I think is probably a better path forward for a majority of use-cases. Clojure and Kotlin and Scala all benefit from being more-or-less fully interoperable with each other; as a result, one can feel free to experiment with language design to their heart's content without too much fragmentation.
That said, I don't know that it's entirely fair to completely criticize Rust on this; Rust exists specifically to address issues with C and C++, languages without garbage collection, and whose design doesn't quite allow the same level of compiler safety and goodness that Rust does, though to be fair Rust does have C FFI so it's not necessarily always reinventing the wheel either. I mean, I agree with the blog post we're chatting on top of; Rust might be super awesome for systems-ey stuff, but for anything TCP-or-higher, I think a managed language is kind of better.
I actually do agree that as software engineers, we're often a bit too eager to reinvent wheels. While I am not a huge fan of Java, if I owned a company, I would probably be more likely to use a JVM language (probably Clojure) than I would to use something like Haskell or Idris, precisely for the reasons you've discussed.
My overall point, though, is that often times languages themselves lag behind the state-of-the-art; there's been a lot of progress made in language design, and Java (and a lot of other languages) can feel crufty in the process. Sometimes the wheel really does need to be reinvented...if we could somehow convince the entire industry to use Lisp, this would (arguably) be a non-issue, since they allow you to abuse macros relatively easily and add language features (see CLOS or core.async for examples), but Lisp hasn't really taken over the world like I wish it would.