[orthoxerox]

Rust is great as a hobby language, as it tickles some previously unutilized brain patterns.

I don't think it's a great replacement for Java/C#. Unless your problem is GC pauses, either language will let you be more productive even when you master the borrow checker simply because their ecosystems are much richer.

I can imagine AAA game engines slowly migrating from C++ to Rust, but enterprise applications are already fast enough in 99.9% of the cases.

[__jem]

Enterprise applications are already fast enough, but memory footprint can still be a real pain. Monitoring and deploying the JVM isn't easy, and I think there is absolutely room in the future for lower footprint deployments in the enterprise space. Golang has already seem some limited adoption, but has a limited type system that doesn't easily allow expressing complex business logic. Rust has the possibility to really shine here, even if it doesn't eat the enterprise world.

[zozbot234]

> their ecosystems are much richer.

The Rust "ecosystem" can seamlessly expand to include any language with a C ABI and FFI. Solutions are also being developed to ease interop with managed platforms like Java/C#.

Contrast this with something like Go, where even interoperability with C does not come out-of-the-box and requires compromising the most desirable features in the language itself.

[iudqnolq]

Can be, yes. Seamless, no. In the best case where the api uses very old fashioned c without many pointers it's an extra afternoon at least. (I've written high level bindings for a few small libraries for hobby projects)

[oscargrouch]

There's no "language to rule them all". Java already tried and almost ruled the world, but reality is that with options languages take here and there to whats important to them, they will never expand to a certain level.

Languages compete in their axes, which for me there are mainly 4 big ones:

a) System/Performance/Control: C, C++, Rust, Zig

b) Application: Java, C#, Swift, Go, Kotlin, Nim

c) Script/Casual: Python, Ruby, Lua, Javascript

d) Domain specific: OCAML, Scheme, Haskell, Matlab

I've never seen a language ruling in two axes at the same time (as in you can use it for the same goals), let alone in all four, or at least three.

The a' axis are very hardcore languages with insane amount of control, but they will never be as productive as the b' and c' axis.

Meanwhile the b' axis is the most popular one, as they allow you to create big and complex application while being productive. Their runtime are not far away from the languages on the a' axis.

The c' axis is most productive and easy to pick up, with languages that feels more natural, but they dont have the performance of the a' and b' axis and also its hard to compose big applications on them unlike the a' and b' axis.

Maybe a successor of languages like Rust and Swift might be the on to do this, but i cant hardly see Rust in that position because programming in it have more or less the kind of productivity that C++ gives you.

I relax much more when i can write something in Swift instead of C++ or Rust for instance, and i would mostly choose it given the perfect match to the problem i'm solving.

I think we are going for a more polyglot world, not less, and i mostly use C++, Swift and Python when i can, where you can replace C++ for Rust, Swift for C# and Python with JavaScript according to your personal tastes.

But using something from one axis trying to reach for the goals better served in another axis is mostly a "when all you have is a hammer.." kind of paradox.

[kaba0]

Nitpick, but GC pauses are basically no longer a problem with low-latency GCs like ZGC or Shenandoah in the JVM.

[renox]

Sigh, don't take your use case of GCs and apply it as a rule to others.

I work in telecoms on the layer just above the FPGAs/DSP: even a 1ms 'pause' would be totally unacceptable here..

[kaba0]

I think you are way overthinking my comment. I just added a note that for regular, user-space applications there really is no longer a reason to use low-level languages even if latency is important.

Of course embedded will always exist, as well as specialized programs requiring utmost control over the machine.

[dexterlemmer]

I don't see any such note and it's 8 days later. May be you should check your comment again? Also, while games aren't exactly regular applications performance-wise, I think they fall more under that than embedded or utmost control and while a 1ms delay won't be the end of the world, it'll likely hurt.