4 ms·

Well, speaking from experience with a JBoss application layer in a recent software project I worked on: New java versions do break existing libraries or apps,

Well, speaking from experience with a JBoss application layer in a recent software project I worked on: New java versions do break existing libraries or apps, and need to be tested thoroughly. When the company hasn't budgeted for that expense, it becomes difficult to update. Often an architect or software team will insist on using the Oracle JVM rather than the included openjvm. That adds extra steps to download, store as an artifact, distribute, verify, etc etc. The people who wrote the build pipeline have since been laid off, and an updated set of libraries requires a lot of work to trace back through poorly documented and understood code to make changes. (Not to disagree with you here, it's more that I'm trying to illustrate how, with poor foresight, Java dependencies can get difficult to manage)

tzjmetron 8y ago
Not convincing enough.
paulddraper 8y ago
> New java versions do break existing libraries or apps Have you used the Rust compiler? My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Whereas Java apps written a decade ago still compile and run on OpenJDK/Oracle often with zero or near zero changes. > Often an architect or software team will insist on using the Oracle JVM rather than the included openjvm. Yes, you could choose this. But if you have the ability to choose an entirely different language, I guarantee you have to ability to choose OpenJDK if that's what you really want. > build pipeline , an updated set of libraries Doesn't Rust have libraries? In fact, if anything, Java libraries have a longer shelf life and greater compatibility because they don't require integration of build systems. Java libraries can (and do) use 5-year-old compilers, postprocess bytecode for perf (e.g. Hikari) or size (e.g. Proguard), and even use entire other languages like Scala and Kotlin. But the only thing you as the library user need is the JVM bytecode, which is still high-level enough to maintain runtime interoperability but sufficiently low-level enough to achieve strong build-time interoperability. --- Much of the "organizational overhead" seems to come down to "I don't like managing the runtime". And that's not wrong; static binaries are nice. But how much harder is it really to manage/isolate/version your JVM runtime for your server deployment, than manage/isolate/version your Rust compiler for your CI pipeline?
- 0815test 8y ago
  > any Github Rust project not updated in the last two years doesn't work with the latest Rust compiler. I don't think this is correct? Rust introduced an "editions"-based system in 2015, with the very aim of ensuring forward compatibility on a crate-by-crate basis. The aim is definitely that any crate written to be compatible with some "edition of Rust", whether 2015, 2018 or whatever, can be made to compile on a future version of the compiler.
  - db48x 8y ago
    One possibility is that he used something written against the nightly Rust compiler. That code would be very unlikely to compile today.
    - 0815test 8y ago
      Maybe, but you have to specifically opt-in to the nightly toolchain in order to compile something that uses it. It's not something that's included by default, or appropriate for use in production scenarios (unless you're willing to deal with the resulting breakage, of course).
      - db48x 8y ago
        Of course it's not suitable for production, but it was still quite common to look at a rust project and find that it used the nightly compiler.
        paulddraper 8y ago
        It's been awhile, but if memory serves tons of stuff was using the nightly compiler. So, yes buyer beware. But when the whole ecosystem does it...
        db48x 8y ago
        Exactly. I think it's getting better now that some of the cool things people were waiting on have made it into the 2018 edition. Off-hand I know that Remacs switched from the nightlies to 2018.

tzjmetron 8y ago

Not convincing enough.

paulddraper 8y ago

> New java versions do break existing libraries or apps Have you used the Rust compiler? My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Whereas Java apps written a decade ago still compile and run on OpenJDK/Oracle often with zero or near zero changes. > Often an architect or software team will insist on using the Oracle JVM rather than the included openjvm. Yes, you could choose this. But if you have the ability to choose an entirely different language, I guarantee you have to ability to choose OpenJDK if that's what you really want. > build pipeline , an updated set of libraries Doesn't Rust have libraries? In fact, if anything, Java libraries have a longer shelf life and greater compatibility because they don't require integration of build systems. Java libraries can (and do) use 5-year-old compilers, postprocess bytecode for perf (e.g. Hikari) or size (e.g. Proguard), and even use entire other languages like Scala and Kotlin. But the only thing you as the library user need is the JVM bytecode, which is still high-level enough to maintain runtime interoperability but sufficiently low-level enough to achieve strong build-time interoperability. --- Much of the "organizational overhead" seems to come down to "I don't like managing the runtime". And that's not wrong; static binaries are nice. But how much harder is it really to manage/isolate/version your JVM runtime for your server deployment, than manage/isolate/version your Rust compiler for your CI pipeline?

0815test 8y ago
> any Github Rust project not updated in the last two years doesn't work with the latest Rust compiler. I don't think this is correct? Rust introduced an "editions"-based system in 2015, with the very aim of ensuring forward compatibility on a crate-by-crate basis. The aim is definitely that any crate written to be compatible with some "edition of Rust", whether 2015, 2018 or whatever, can be made to compile on a future version of the compiler.
- db48x 8y ago
  One possibility is that he used something written against the nightly Rust compiler. That code would be very unlikely to compile today.
  - 0815test 8y ago
    Maybe, but you have to specifically opt-in to the nightly toolchain in order to compile something that uses it. It's not something that's included by default, or appropriate for use in production scenarios (unless you're willing to deal with the resulting breakage, of course).
    - db48x 8y ago
      Of course it's not suitable for production, but it was still quite common to look at a rust project and find that it used the nightly compiler.
      - paulddraper 8y ago
        It's been awhile, but if memory serves tons of stuff was using the nightly compiler. So, yes buyer beware. But when the whole ecosystem does it...
        db48x 8y ago
        Exactly. I think it's getting better now that some of the cool things people were waiting on have made it into the 2018 edition. Off-hand I know that Remacs switched from the nightlies to 2018.