Is Rust the best choice for JS tooling?

01 Jan 2022

image of ruler with the word rustless on it, (c) Maksim Lin 2021

Introduction

While Rust is a great language, it, like all languages is well suited for some uses and not so well for others.

Focused on being a systems programming language and a safer one than C/C++, means that Rust makes trade offs that make it a great choice for systems programming tasks. But recently I've noticed that there seems to be a push by some to make it the tool of choice for writing JS tooling, versus using JS itself (via NodeJS). But is Rust really the best choice when you are in the position to create a new piece of tooling for the JS ecosystem? And is it the only viable choice apart from Node? In this article I want to present an alternative and make the argument for considering it over both using JS and Rust.

The big reveal

So what is my proposed alternative? Well it's probably not a big surprise to find out that it's Dart.

But why do I think Dart makes for a good alternative for writing JS tooling over JS and more importantly Rust?

Well let's examine some of the reasons people are using or proposing to use Rust instead of JS...

Rust for JS tooling

Here are some of the arguments I've seen written about why Rust is a good choice for JS tooling:

But if we examine these more closely, some of the above come with troubling caveats. For productivity, advocates argue that it's not that difficult for JS developers to get up to speed with Rust, but I have to seriously question that. Personally I have found my journey so far in learning Rust hardly easy and I already have a background not only in JS, but also in several GC'd, statically typed languages (Java, Kotlin, Dart) as well as (much less recently) background using C and doing some systems level programming. Rust is just too big, complex and plain different a language, both syntactically and more importantly semantically for JS developers to learn easily.

While one of the articles points to Rusts better than usual integration with NodeJS and another about the trade-offs that Rust crates make, it's really not clear what benefits the Rust package ecosystem brings to this usecase. In the meantime, the benefits of Rusts use of its unique "ownership" memory management system versus GC are really very questionable considering we are discussing tooling which for the most part are run as one-off processes rather than long-lived ones and is hardly timing & latency sensitive unlike usecases for things like audio DSP tools or games.

The above use of "single shot" vs long lived processes does though highlight the big benefit that Rust does bring in terms of AOT compiling to native executables and thus a significant improvement in cold-start times, along with execution speeds, where the JIT based NodeJS would struggle, not having sufficient runtime for the JIT to optimise the running tool before it finishes. And of course Rust's ability to compile to small, stand-alone executables for all major platforms shines here, though to be honest, given how widely and easily NodeJS is installed, it's not clear just how big of an advantage this is for JS tooling versus other areas.

Finally there is significant and fast growing adoption of Rust, which definitely does now establish it as a mainstream language in the industry and it can be relied upon to be around for the indefinite future.

Dart for JS tooling

So what can Dart offer here in comparison to Rust and JS?

Well first off: productivity. While definitely different from JS, Dart was designed (and is still maintained) with a strong focus on making the language easy to learn for developers coming from other C like languages, especially JS, given it's original goal of being an in-browser replacement for JS. I would be very confident in saying that Dart is a much easier language to learn for a JS developer than Rust. Flutter documentation even has a specific section for just this topic!

Likewise because of it's initial (now abandoned goal) of replacing JS in browsers, Dart also has both an excellent inter-op with JS as well as having not one but 2 Dart to JS cross compilers. Given that, Dart also has a significant history, community and ecosystem of use in browsers.

Looking at the previous point I covered of JS tooling needing to optimise for short runs and fast startup and execution times, Dart with its ability (just like Rust) to be AOT compiled to "smallish" statically-linked standalone native executables for all major platforms, for both x64 and Arm architectures, pretty much matches Rust, though I must admit I've not really seen any comparative benchmarks for execution throughput for the type of compiling/processing tasks that JS tooling needs to do.

In regards to adoption, while use of Dart for cli tooling is not significant, there is the very prominent existing use of Dart by the SASS compiler project that points to Dart's production readiness in regards to web development related tooling. And with Dart being the foundation of both that tool and the enormously successful Flutter, Darts long term future seems very positive.

Conclusions

While Rust does hold some advantages over using JS for JS tooling, I'm still sceptical of just how much advantages it brings to this very specific use case versus the trade-offs.

In that light I believe Dart brings many of the same benefits and perhaps not quite as many trade offs to the table and should definitely be worth consideration for use for any JS tooling that is either written from scratch or that decides to move off JS to another language.

Of course the above should in no way be seen as down playing the importance, high quality and usefulness of Rust in a multitude of other uses and domains. I'm definitely still investing time in learning it and putting it to use in many upcoming projects, including Flutter apps, embedded and microcontroller projects.

Finally I would also recommend reading Dr. Axel Rauschmayer thoughts on the pros and cons of this emerging trend to write JS tooling in non-JS languages

I hope this has been of help to you and if it has or you have any other handy tips to share, please let me know in the comments below or via Twitter.