One thing I don't get in #Rust and #Go is that #Java and various #JVM -languages have pretty much delivered backend all the goodies that the newer languages promise to deliver 🤷 I call this Yogurt syndrome because it is a product that never really changes but still new versions arrive to the market.

@jarkko
Not sure I understand what you mean...
Are there any JVM languages that delivered memory safety without a garbage collector?

@orizuru @jarkko By definition, no. The JVM itself has the garbage collector. No JVM language can ever be as fast as rust or run without a gc, although one could fundamentally make one as safe as rust. But even then, the entire stdlib is infected with and drenched in nulls and Exceptions, so a rewrite of that would be needed.

@TudbuT @orizuru Thanks for the qualitative opinion that I will ignore without reading it properly :-)

@jarkko I remember hearing the same about Smalltalk in the late 90s ;)

@mhd Its ideas became big through Objective-C kind of and influenced quite many languages over the years. World would not be the same without Smalltalk even tho it itself was not great success.

Java on the other hand is the most field-tested industry strength language in the backend. And its JIT is heavily optimized by the engineers of the CPU companies involved. It is not that great in the client and but there's no server workload in existence that would not have gone though the "Java exercise".

That said my fav desktop application Bitwig Studio is made with Java ;-) https://www.bitwig.com/

@jarkko You mean the repurposed Smalltalk JIT? ;)

I just meant to say that it's always easy to say that #nutech isn't necessary, because we already have #oldtech at home. Just like it's always easy to find minor differences to justify #nutech ("It doesn't use begin/end statements", "It uses actors/coroutines/threads not threads/actors/coroutines!")

(I'd also say that Java's direct competitor is Go, whereas Rust just seems like new source for JNI bits & pieces, I don't want to digreess too much)

@TudbuT @orizuru @jarkko

Hm, the typical response to "it never can be as fast a compiled language X" is "it could be faster because the JIT compiler can apply knowledge at runtime, that enable optimizations impossible for aheaf of time compilers".

@mhd Rust seems to have found its place as defacto for wasm, which I think appropriate use for it too.

I.e. security barrier involved with direct user input.

@jarkko

@TehPenguin i also ignore all meme pic's, sorry ;-) i don't care about em.

@jarkko I was asking for some context for your comparison.

Rust is making inroads to kernel dev, where Java will never be able to go.

Java has a rich set of GUI libraries, whereas the GUI story for Rust is... lacking.

Rust provides a lot of useful mechanisms for safe concurrency, but Java only provides some very basic primitives.

So, when you say "all the goodies", what do you mean?

@TehPenguin In the backend it JVM does provide safe, concurrent and secure ecosystem and huge track record to back it up. I don't see any actual business reason to switch.

It neither has not made waves yet in the kernel, and it is not likely it will before GCCRS is in par with LLVM. Not saying that it never will but zero defconfigs is not a strong standing point.

The business interesting use I've seen has been WASM so far.

@jarkko Oh yeah, because Java has easy, safe parallelism and no garbage collection overhead...