TBH this sounds like a great candidate for rewrite - likely millions of hours of runtime/hour. Prettier is written on a platform with a history of such rewrites getting 10x perf increases. The only alternative that comes to mind is Go but I'm not that offended by Rust choice - has pros and cons.
It's not just speed, but also correctness. A quick search in the Prettier repo shows plenty of issues for "undefined is not a function", "cannot read property X of undefined/null", and other such errors that are avoidable in a language with a good type system.
Right which is part of why dictating the implementation language up front as part of the bounty is a mistake. They should have put the bounty on the speedup factor they're looking for and let it sort itself out.
My not-completely-naive guess is an expert optimizer can get the improvement they're looking for with only small parts or maybe even none of it rewritten in another language.
familiarity. and rust seems to be winning the war for web development tooling, at the moment. zig (by way of bun) may make a good stand if bun were to produce such tools too, as standalone. it’s a high barrier if bun has to be adopted wholesale in order to have a pretty printer.
As a (nominally) front-end developer the RIIR movement's energy is similar to how the front-end community approaches things.
Overall Rust and its community have many traits that make them very approachable to people not expected to know anything about systems programming, namely:
-Package manager with a familiar philosophy behind it (and not the sort of hell you have to deal with setting up a C++ development environment).
-Outputs WASM without much bureaucracy and advertises it.
-Friendly compiler messages. I don't recall seeing "perhaps" in a compiler error message before.
The people designing Rust put much effort into making the language as approachable as possible and that's the net effect.
That is not to say this is going to be necessarily successful, but so far the enthusiasm is there.
Some dev workflow tools really benefit from being very fast. And parsing and ast building and the like are actually things that rust is quite good for.
That doesn’t mean it couldn’t be done in other languages, but it’s a weighing of trade-offs. And of course, groups of people, such as developers on socials, are quite sensitive to popularity.
> And parsing and ast building and the like are actually things that rust is quite good for.
Having built a compiler and typechecker in Rust, I don't know if I'd say that it was "quite good" for it. Going back, I'd still do it again, but it wasn't exactly a cakewalk. Rust's lifetime rules and visceral hatred of referential structs did not make my life easy at all. I definitely took the easy way out with a lot of string copies too.
Why on earth would you need object lifecycle mem management for these things? These are points where Go excels as well. Rust is meant as a systems language, I'd love to have it as a general purpose lang as well, but it's not imho.
So you think Rust is a bad choice because... the programmers will need to deal with the borrow checker? I think it's been demonstrated that programmers are fine with that.
It is a sad moment for me, because I have more difficulties understanding Rust than Haskell, and believe me, Haskell is very difficult already. I know C, Lua, OCaml, Go, and the like, but Rust? Not really. What I hate the most is reference implementations being in Rust instead of C. C is almost like a pseudo-code.
