Practical uses of Rust

[Ollie-w]

I am a front-end web developer with no experience of low level languages like C++ or Rust. Web Assembly has made me interested in Rust yet I have not encountered any real use case for it in my own day to day work.
I'd love to hear some examples of the kind of tasks that Web Assembly could be useful for, before I take the plunge and start learning Rust.

The live example on the Web Assembly website is a video game. http://webassembly.org/demo/
I'm sure there are plenty of other applications for this technology?

I realise this is more of a Web Assembly rather than a specifically Rust question, but I though people here might have some insight.

[NoraCodes]

I have not encountered any real use case for it in my own day to day work

There honestly probably isn't one, even once good wasm support gets going. Rust is a systems language, designed for writing systems software; it happens to be pretty good for backend software too.

I personally would love to use Rust for frontend dev, but that's because I already know and love Rust, not because it has any great advantage on the front end. The only really good thing it offers there is a very expressive type system, which I believe can be found in other languages.

On the other hand, the lifetime system is likely to lead to some advanced optimizations that aren't possible with any other language, so that's probably a reason to go with it.

[vitalyd]

I agree with @NoraCodes. I don't know much about webassembly so can't comment on that. Rust as a whole though perhaps does itself a slight disservice by kind of hammering on the "systems language" part. It's definitely that, but it's a whole lot more and perhaps some folks skip over it cause they don't "need" a systems language. But I think some of those people would enjoy the type system that can prevent entire classes of bugs, concurrency safeguards, functional elements, rich pattern matching, and so on. And you get speed/efficiency, even if that's not purely warranted (but let's be honest - nobody minds faster software). It's definitely not an easy language, has quirks, and so on. But I don't know any easy languages that also offer up what Rust does in return.

[kornel]

It's useful for the kinds of applications that so far have been written as native apps, because JS for them was too slow or had too much memory overhead.

For example, you can write a game engine in Rust. Or an image/video/audio editing application or codec. You can create complex data files (e.g. compressed ZIP or tarball) purely client-side in an off-line webapp.

In general, it's best for problems where there is complex data and a lot of computation needed.

As a language, Rust is very serious about correctness. It has powerful type system and makes it hard to ignore errors, so you're unlikely to be surprised by "undefined is not a function". To get a taste of it in JS land, you could try TypeScript.

[U007D]

Let me try to address your question by framing the situation. Of course this is all pure speculation, so take it for what it's worth.

I believe WebAssembly, if successful, will be the future of the web front-end. That is to say, WebAssembly will rule where Javascript does today--in the browser. Why? Features. Something similar happened when the whole world took on a lot more complexity with Web 2.0 moving us away from simple, static, HTML pages.

Delivering binary directly to the browser allows new e-commerce solutions (browser-based Steam, anyone?), that simply don't exist today. I can think of several compelling 'killer applications' for WebAssembly, once it is sufficiently mature.

What makes WA really interesting is that it is designed to be the target of other languages. So that means you'll be able to develop in WA from "your favorite language". I think a mature Rust language figures prominently in that future with so many front-end developers embracing (or being forced to embrace) compiled languages for the first time. Safer code, fewer run-time bugs, better scalability AND better perf? I don't even care what the language is called--I believe the right answer to that offering is "shut up and take my money!"

So, like others here have said, I think Rust is much more than "merely" a systems language. At this point any investment in Rust as a front-end language would be pure speculation (and a bit of a maschocistic exercise, since both Rust, WA and, presumably their debugging tools are all so young), but not a bad investment in your skillset. You'd be learning modern paradigms which would only help you if you went to Swift, Scala or even modern C++. Of course, a similar case can be made going the other way, coming to Rust.

So if you're interested in learning new stuff, then by all means, pick an intriguing language, jump in, and don't worry too much at this point about the "practical uses". Pretty much regardless of what you choose, you'll have a head start if/when WebAssembly takes off, almost no matter what language you end up developing for it in.

Personally, my bet is on Rust enjoying a material competitive advantage, but like I've mentioned, picking something you find interesting is more important than picking Rust, per se.

[jimb]

There are lots of good, pragmatic answers here, but let me offer a different take:

The questions I think people should ask are:

• Am I constrained by speed or memory consumption?
• Am I constrained by the complexity of the code I need to write?

For many, many important problems, I think the answer is "no" to both. For those, you should use Python or JavaScript or some other language that is happy to burn resources to make the programmer's life easier. Machines are cheaper than programmers. But for everything else, Rust is a great solution.

Rust is a language for performance-constrained problems. If the key challenge in solving your problem is getting it to fit in memory, or getting it to run fast, Rust is the language for you. There's no such thing as a "fast language"; you can write slow programs in any language. What a language can do is give you the control necessary to get the performance you need. Rust doesn't force you to use a GC. It doesn't force you to use a fancy object representation with hidden classes. It doesn't force you to use a JIT. All those things trade away control for programmer convenience, which is often the right trade - it's just not always the right trade. But if the machine is capable of doing it, you can almost certainly do it in Rust; the language doesn't put complex, unpredictable systems in your way.

(I think this is actually the best definition of "systems programming". It's not really about native apps versus web pages, or what layer of the system the code lives in. Rather, it's about whether performance is a core problem you're solving.)

But Rust goes a lot further than that. Rust's types are not just, or even primarily, about safety and speed. You don't really need generics or traits for safety and speed. Rust's types are also about correctness and expressiveness. Look over the issues filed against any (non-Flow, non-TypeScript) JavaScript library, and see how many would have been caught at compile time if the code had been written in Rust. JavaScript isn't my home territory, but I do follow the source maps library, and when I see an issue titled "Error: No element indexed by null", my bet is it's something that wouldn't have happened in Rust. I love types. Finding out about typos in member names only through unit tests is... just not how I want to spend my time.

[asevans48]

If you are interested. Try executing a rust application from electron. It is possible and adds speed to your desktop software. I am building version control for users files in Rust. The hope is to be foolproof (completely avoid branch issues that come from misuse of git). File differences, updates, uploads, merges, deletion, and pull are basically rust scripts.

[anzhuo]

From my perspective, I'd say I agree that there aren't many immediate practical reasons to use Rust /WASM for frontend stuff for the vast majority of use cases.

However, I WOULD argue that WASM is the future, or at least the beginnings of the future. I love and hate JavaScript. The only thing I like more about JS than Rust is the terseness (e.g. arrow functions). I'd replace all that with Rust in a heartbeat, and WASM lets you do that.

Is it ready for primetime? Not at all. But I think and hope that time is coming. In the meantime, I'm working on getting as good with Rust as I can. If that dream falls through, I've still learned a ton of important programming concepts and can use Rust for many non-frontend programming tasks.

[_Tom]

I disagree violently with most that has been said. In fact, I am learning Rust specifically because JS is a complete mess and doesn't do what I need.

Two weeks into Rust, I've refactored a complex simulation into Rust, reached better performance than the old code, and was able to port a stripped-down version (preview only, no saving of results into the SQL database, obviously) to wasm. It executes in the browser now, is blazing fast and if someone had tasked me with writing that same code in Javascript, I'd have rather hanged myself.

Fullstack frameworks have been every web developers dream for years, and node.js is a pathetic answer to that, with its fragmented and awful ecosystem. Rust has the potential to get client and server parts compiled from the same code base without sacrifices to sanity, dark gods or performance.

So despite being very new to Rust, I already have a working, practical use-case. I'm confident that I will have more in the near future.