This post is more of a question than a comment, but I think Medium is a reasonable place for that kind of thing: what does the Rust community think of Scala?

I have a reason to ask the question, but first, I’ll give my opinion so there can be no question as to my bias. I love both. I love them for largely the same reason: they have a simple and elegant way of solving problems in their respective targeted domains, belying a rich and complex set of language constructs that make sophisticated ideas more expressible and more easily manipulable.

The problem is, in a modern stack, where we’re trying to make the best possible choice of language, it would seem they each suit a purpose — but in different parts of the code.

The purpose of Scala

If you’re looking for an easy way to build a massively parallel system across a compute cluster, including things like auto-scaling, but with enough “expert mode” stuff that you can still work at the protocol level if you like, then Akka and Scala are for you.

Indeed, I can think of no easier way to scale out a large computation, build the backend of a large system, develop self-healing software for high availability, or any of the many solutions that are built through scale.

And all the while giving you an elegant way to think about concurrency, thread safety, abstraction and even networking.

The purpose of Rust

So with our massively parallel, compute load-sharing, distributed, clustered, Gossip protocol-using, super fancy system built, we have some kind of work to do with it — right? In my case, that work is often heavily compute-bound, creates lots of temporary memory, and generally thrashes the JVM to pieces.

This is where Scala kind of breaks down. My JVMs have my cores pegged, hopelessly trying to catch up in a race they can’t win. And as much as I may see the problem — and even understand it — there is no direct route around it; the problem becomes one of engineering around the JVM.

And now Rust becomes the obvious choice. With the same expressivity I had before — although maybe a little bit more complexity involved, and certainly harder for new devs to pick up — I can drop as low-level as I need. I can write lightning-fast code (C-speed, I’d say) that is memory-efficient without managing memory or sacrificing modern conveniences like closures. I get zero-cost abstractions all over the place. I can rock CUDA without feeling like I’m fitting a square peg in a round hole — times thousands of cores.

Caveats

This isn’t to say that the clustering, distributed computing and so on couldn’t be done with Rust — there are many excellent Rust tools for that kind of thing. But at this point in the evolution of Rust’s ecosystem, I don’t think there’s anything nearly as modern, elegant, powerful and simultaneously suited for production deployments as the Akka and Scala stack.

And it’s not to say you can’t get great speed out of Scala. But when you’re looking to write some kind of highly-optimized code, low-level code, or whatever, Scala begins to feel a bit like its own round peg in a square hole, as it were.

And both have their place in a large variety of modern applications — to include almost any that rely on complex machine learning algorithms or large-scale optimization heuristics.

Where does this leave us?

I don’t know. I ask you. If you feel the same — if you really love both Scala and Rust, each for their own purpose — how do you reconcile this disparity?

A few years ago, when Scala came of age, there was a trend towards building new and better languages for the JVM, and a whole lot of great things came of it — Clojure, Groovy, and yes, the whole Scala ecosystem (Akka, Spark, Play, Lift, and a bunch of other critical infrastructure widely used in industry).

There now seems to be a trend back towards our roots, writing compiled, native code — getting closer to the metal again, and realizing that a great deal of performance can be garnered from optimizing the code running on a single node.

So my question to you is, given these two great tools: how do we reconcile where to use them? Is there a natural way to combine them in some kind of polyglot bliss, via message queues, REST APIs, or even native interop? Or is each project required to make a firm choice whether to live in the land of the JVM or the native?