> I tend to think Rust isn't suitable to rewrite JavaScript tooling

If only you could have warned all the people that the work they did was untenable before they went and did it.

I cannot think of any mainstream language that is AOT-compiled and create standalone executable for the three major platforms other than Rust and Go* (Zig is not stable yet), which are precisely the two languages that are used for most newer JS toolings. For Python you only have Rust, as you need C FFI. Maybe one day we will see more software in Nim, Crystal, and Janet, but they are far, far from mainstream.

What specific languages do you have in mind?

*and C and C++ but writing tools in them is like self-lobotomy.

C# is getting there.

EDIT: And Dart (which is not that mainstream).

>"...and C and C++ but writing tools in them is like self-lobotomy."

C is a lower level language than Rust so sure it is harder to write complex tools. Modern C++ - writing tools is at worst as easy than Rust and way better in practice because of a huge amount of libraries to suit every taste and C++ being more expressive / supporting more programming paradigms.

Statement like yours are not doing any service to Rust. Rust advocacy can do very much without such "help". Hopefully it does not represent culture of Rust community in general.

I am not advocating for Rust and don't care at all if these tools are written in Assembly or C++; as long as they exist and work well, I am happy.

When I wrote that statement, I didn't really mean C++ the language, but C++ the developer experience. I have tried to write a few command-line utilities in C++, and while the language proper is quite capable, dealing with CMake, package management, header files, and testing is just more headache-inducing than in Rust for me. Most of it probably stems from my lack of experience with C++, but it doesn't change the fact that despite C++ being 20 years older than Rust and having an order of magnitude more users, most of new JS toolings are not written in it.

Feel free to prove me wrong by pointing me to good tooling projects in C++. I actually want to learn more C++ best practices for working with another language.

I mainly use CLion by JetBrains for development. It does use CMake.

I can't point you for particular tooling C++ project. The only 3rd party source code I use are some C++ libraries. All it takes in my particular case is adding couple of lines in CMakeLists.txt file and I am very far from being CMake expert.

CMake is actually a perfect demonstration of how annoying C++ development tooling can be.

The documentation is massively verbose but doesn’t really say anything helpful. There’s basically no “Modern CMake” examples that anyone can agree upon. (I do see that there’s some GitHub repos these days that maybe do show some of it). There’s very little information on “The CMake way of doing things”. You really need to learn by examination, and your assumptions in the end will very likely be wrong.

Even just adding a package fetch in CMake is infuriating. What is the currently accepted way to do this? (I admit that I haven’t used CMake in a while, but as of a year ago, the internet and CMake docs did not agree on the correct way, even internally)

The Professional Cmake book is an indispensable, fantastic resource I've used on a couple of work projects, I highly recommend it to anyone working with Cmake.

That being said, Cmake is a far cry from the ease of use of cargo (albeit with potentially much more flexibility).

https://crascit.com/professional-cmake/

We must be living in a different world. It literally takes me seconds to create new executable project.

>"Even just adding a package fetch in CMake is infuriating."

I am not sure how to do it because I do not let build process / environment fetch things from the Internet. I always download / deploy / update manually upon real need. I would agree that having IDE do it for you is convenient but since I only use very few libs there is no need for me to do it at all.

If I need to create new project I just copy a template, fire up CLion IDE and it all takes few seconds from the - I am going to do it, to start actual coding.

Using external libraries is important because it lets you focus on what's important for your project. C++'s lack of a proper package manager means we're all reinventing the wheel because adding dependencies is non-trivial.

Cargo/Rust and Go show how compiled languages can have drastically superior development experiences. CMake is primitive in comparison. Its only upside is its flexibility, which I reckon isn't worth it for most cases.

A while back I needed to write a small library in C++.

It took me about the same amount of time to write few dozen lines of CMake (to get build working with all the external libraries), as it took me to write few thousands lines of C++.

I wasted way too much time dealing with CMake.

>"few dozen lines of CMake (to get build working with all the external libraries), as it took me to write few thousands lines of C++."

I claim BS unless those "thousands lines" were cut'n paste.

No, but it was a rewrite of C# code. Using MSVC compiler, targeting Windows and Linux. C++20 with modules. External libraries: libsodium, lmdb, roaring & rocksdb. First time using CMake.

>"Using external libraries is important because it lets you focus on what's important for your project"

Well thank you. I just trying to guess where did you get the idea that I am not using 3rd party libs.

>"C++'s lack of a proper package manager means we're all reinventing the wheel because adding dependencies is non-trivial."

I think it is trivial. Here is particular example for cpp-http library that I use in some of my projects:

  a) download from github
  b) add add_subdirectory("./3rd-party/cpp-httplib") into CMakeLists.txt file

That is it. Ready for use.

That’s fine, but most modern tooling “automates” this for you and gives you easy tooling to manage versions as well.

Additionally, you get a nice list in a simple spot of exactly what you need that isn’t just documentation. Anyone can easily pull your project and contribute.

Being able to easily manage deps has issues (such as a tendency to trend toward left-pad), but there’s also significant benefits as well that become readily apparent when you compare cargo with CMake (I understand they’re not completely comparable)

> Statement like yours are not doing any service to Rust. Rust advocacy can do very much without such "help". Hopefully it does not represent culture of Rust community in general.

Ugh. You’re disagreeing about which languages are best for some task. Are either one of you being-an-advocate? That’s up to interpretation.

It’s not fair to say that someone who vouches for Rust is being-an-advocate while someone who vouches for C++ is just arguing normally. What basis is there for that?

I could say that you are not doing any service to Rust-naysayers. That I hope that the culture of Rust-naysayers are not represented by people like you. Would that be fair?

The Rust ecosystem is much more coherent than the C++ ecosystem, broadly speaking. Starting from cargo, which isn't perfect but is a fantastic tool.

As the main author of cargo-nextest, I'd challenge you to write a tool with a similar complexity and quality level in C++. I got so much leverage from being able to use the Rust ecosystem, including being able to port to new platforms with literally zero code changes. (Be sure to get the signal handling exactly right.)

Go is in no way comparable to the other two. It may seem deceptively simple but it lacks crucial low level primitives and features C# has.

> apparently dealing with borrow checker ... is appealing.

Yes it is. I love the borrow checker.

My experience is that the borrow checker is not that hard to deal with. There are two ways:

- you are a c/c++/low level guy who knows how allocation works very well and figure it out

- you are a java/c#/python guy who wants to get going and use clone() a lot

Either way, the performance that you get is worth the troubles.

Better create an editor macro to paste those ".clone()" all over the place.

You can get similar performance with any AOT compiled language, even managed ones.

FWIW Rust has the Copy trait which lets you more or less do exactly what you’re asking with no pasting required.

Copy and Clone traits have different semantics. Copy is only for bitwise (and cheap) copies. Clone is for explicit, potentially expensive copies. Also what entails cloning differs from type to type. String, for example, needs to duplicate the pointed to string buffer in the heap, while Arc only increments a reference count.

Yes, I know. But in the context of what’s being described here someone getting started with Rust and wanting to avoid issues with lifetimes could very easily be using copy in the way the OP described clone.

I think these days we generally just use Copilot/an LLM.

> apparently dealing with borrow checker for userspace software that doesn't require 1us performance within 512 KB is appealing.

Having worked on large web-apps, I'll take all the speedups I can get, thanks.

There are more languages out there beyond nodejs and rustc.

Yes, on that we can agree.

You specifically seemed to be saying "Why use rust when you don't want top tier performance", to which my response was "I do want top tier performance."

That aside, with regards other languages I'd consider candidates for high performance tooling, I'm either not proficient with them, or I don't enjoy working with them.

Andrew Kelley talks about this and the effects he’s trying to achieve with Zig tooling.

Undoubtedly, language tooling being fast improves your ability to iterate. 1 second vs 60 seconds doesn’t “seem” like much, but when you have that speed, it becomes very difficult to give it up, and when you know it can be faster, it is incredibly frustrating when it’s slow.

Iteration speed is crucial for shipping code fast. It can mean the difference between spending a day understanding and fixing a bug to spending 15 minutes doing the same thing.

Although I suspect that as your domain knowledge of the software improves, the effect flattens out.

> I tend to think Rust isn't suitable to rewrite JavaScript tooling

> any compiled language would do

So why not Rust?

Because as mentioned, it isn't a game engine fighting for fitting everything into 16ms into a games console.

Similar performance levels can be attained with any AOT compiled managed language, with much better developer productivity.

Either one needs to deal with the borrow checker for performance that matters, or if the performance doesn't matter to put .clone() all over the place, then what is the point beyond CV building?!?

Once you know Rust, the borrow checker is not impacting your productivity.

This leaves you with a fast language, with robust and relatively easy multithreading, and a rich ecosystem of high quality libraries. I don’t know any other AOT language that can come close to such productivity. The closest may be golang, but it’s not ideal for parsing.

>"..relatively easy multithreading"

Multithreading is just as "relatively" easy in other compiled languages.

AFAIK no other language has thread safety in the type system, enforced at compile time. The next best thing is having a particular share-nothing or message-passing paradigm built into the language.

Golang for example does not enforce use of synchronization when mutating shared objects from multiple threads, even though it can lead to crashes and vulnerabilities, just like in C and C++.

It may be hard to appreciate Rust's fearless concurrency until you see for yourself how it can save you from heisenbugs. You can invoke any function, which could be even a 3d party dependency using more dependencies and touching a million lines of code, and Rust will tell you right away if any of that code has some thread-unsafe behavior (e.g. some method may have internal cache without proper locking). With the safety net of the borrow checker you can use constructs that would have been considered irresponsibly dangerous in other languages, like spawning threads referencing on-stack values of other threads.

>"It may be hard to appreciate Rust's fearless concurrency until you see for yourself how it can save you from heisenbugs."

Writing multithreaded native applications is my bread and butter. Including enterprise grade application servers with multiple clients and various IT systems accessing it. I can't recall when was the last time I had any problems caused by improperly mutating data.

Mozilla, a project full of C++ experts, tried to write a parallel CSS engine in C++ twice. They couldn't get it working either time. But their first attempt at using Rust worked out -- even though many of the devs working on it were completely new to Rust.

The quality of the tools one uses matters a lot.

https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...

>"Mozilla, a project full of C++ experts, tried to write a parallel CSS engine in C++ twice. They couldn't get it working either time."

The fact that Mozilla can not do a particular thing in particular way has zero value for others not in the same boat. I am not Mozilla. Do not know their problems and do not care. Maybe parallel CSS is too complex by nature. I can only relate to my own situation. My commercially deployed systems work and serve bazillion of clients with no problems.

What weight do you assign Mozilla's data point? It isn't rational to say zero, is it? Also consider that Chromium still doesn't have a parallel CSS engine -- my understanding is that they tried and failed as well.

I've also written systems in Rust, some embarrassingly parallel and some that are more complex than that. The embarrassingly parallel ones never took more than 10 minutes of effort to do. The more complex ones are harder but still possible.

I agree that your data point should also be assigned non-zero weight.

>"It isn't rational to say zero, is it?"

It is well above zero. But this is for very specific situation - parallel CSS.

I on the other hand had never had problem managing / mutating state in my multithreaded programs. I did have one situation with deadlock when interacting with Directshow signal processing. That was around 2002 I think. Took me one day to analyze and fix the code after the bug was reported. But Directshow is an incredibly complex piece with some weird behaviors. Other then that I do not recall any real problems. Btw that particular software was desktop application and written in Delphi, not even C++.

So yes to me the opinion of Mozilla's team is totally irrelevant. It is of course totally mutual but I suspect that my situation - C++ application servers is way more common than parallel CSS.

Your original assertion was:

> Multithreading is just as "relatively" easy in other compiled languages.

Maybe that is true for your case, but broadly speaking it isn't true.

It is much easier to write complex multithreaded code (not just data-parallel) in Rust than in any other language. And data-parallel code is also easier.

Wrong question. Why rust?

Because the people who actually want to do the work want to do it in rust.

With both Vite and TailwindCSS v4 written in Tailwind, web development is going to be faster for Astro and other frameworks.

>TailwindCSS v4 written in Tailwind

Didn't realize it was a self bootstrapping language now. Thats awesome

That's a fair answer. Although I still don't agree with rust being particularly fitting for that problem.

Because it’s the only sufficiently mainstream language in the ML family.

That's not a reason to use rust in that instance.

If you don't care about the best possible performance you can (and so most people should) just do whatever is easiest to reason about and not waste your time trying to figure out how to satisfy the borrow checker.

But also yeah, Rust is just a really nice programming language, I prefer to write Rust so obviously I'm going to write software in Rust and that's likely true for others too.