Rome developers will not use Rome to develop Rome, and the Rome users are less likely to contribute because they are more likely web developers and not familiar with Rust.
My point is that Go seems like a reasonable choice, if you want to easily onboard developers who are familiar with JavaScript. I don't think Rust would be as accessible.
I personally learnt Rust quite quickly and easily coming from a JS background. There was some new stuff to learn, but the Book covered that well, and what I consider idiomatic JS - lot's of functional iterator chains, minimal mutation, duck typing, etc - translated into Rust pretty much 1:1. Cargo is also familiar to the JS dev, and the availability of high quality libraries means that a beginner Rust dev doesn't need to learn the most complex parts until later.
That said, Rust has come a long way in terms of ergonomics.
The most significant performance-oriented effort in this space still leveraging JS that I know of is kataw[3], and while that's quite fast compared to babel, it's still within an order of magnitude from babel. Kataw itself is a CST-based implementation that was created to outperform seafox (a AST-based parser by the same developer), which itself is an iteration over several other perf-oriented parser projects.
Babel gained popularity due to the crazy amount of churn in grammar over the past few years, but more and more I think the dust is settling, and flexibility is no longer the name of the game, making an AST-based implementation less appealing. The Rome team must be feeling the heat if the data structure design choices are being informed by performance. I highly doubt someone will be able to compete in performance using a JS implementation in today's landscape.
[0] https://github.com/swc-project/swc
[1] https://github.com/sebbekarlsson/fjb
[2] https://bun.sh/
Is there really a significant overlap between programming tooling usage, and development of the programming tools?
The case where I see most rampant abuse of this is npm/node commandline tools. Written in/for an environment because it is mostly used by people in that environment, and not because it is particularly suited for it. If it wasn't for docker, all those tools would be tied to a exceptionally messy runtime, and wasted effort. They also won't be included in any normal distribution either. It makes any tool written in node to come across as an amateurish and hacked together attempt. Regardless of how well and robust it is. I'm sure there are good reasons for it, beyond my understanding, since node is something I've always avoided due to red flags all around.
But, I digress. If the memory and runtime model isn't suited for the requirement of the tool, and language doesn't allow for a paradigm that matches well with the problem domain... You've picked the wrong language.
Using Rust promises performance and stability, key features for the thousands of engineers that will be running Rome as a critical part of their workflow. The vast majority of those developers would prefer that the tool runs faster and has fewer errors over having a lower barrier to entry for contributing.
"Contributing" may also encompass the plugin/extensibility ecosystem around the tool, and can be closely tied to the underlying implementation language. This functionality has been integral to the growth of things like Babel and Webpack, but it seems in this case Rome is trying to replace much of that very ecosystem.
I there are some toolchains that may prioritize "barrier of entry to contributions" -- new languages, or niche communities for example -- but I don't think it's an appropriate priority for a toolchain for a massively popular established programming language with $4.5 million in funding [1].
It's also tempting to think that Rust is just better than Javascript for the web too, and you can target the browser with a WASM bundle. I think that's wrong, too. The developer story in the web is weird, but it works and you give up a lot by using WASM. I also think from a societal standpoint (un-obfuscated) Javascript is the healthier choice, since it lets people learn from each other. So, basically: yes, Rome, a dev tool, will be written in Rust, and it will help people write better Javascript, and that's okay.
This is a popular sentiment which I've never understood. Should all JS tools be written in JS? What if you already have an 80% solution written in F# thanks to some other work that can be reapplied to JS, should that solution be rewritten? Should we have IDEs predominantly written in their target language?
I think this is literally the first time that I hear anybody saying that TypeScript is very fast. It's no coincidence that the top open issue in Deno's repo is literally titled "TypeScript compiler in Rust" [0]. The developer behind swc is even rewriting the whole type checker in TypeScript [1]. A lot of people, myself included, think that TS can get excruciatingly slow, in a large-enough but not really huge codebase, in a way that probably wouldn't happen if it were written in something like Rust with a big focus on performance.
If it's goals do not include a good systems interface, the same applies. And Javascript's goals don't include either.