This feels like a really good blog post to write - something I'd really want to read - but the generated AI prose distracts, and makes me lose trust and not want to read this. I'm very AI-pilled, so this is not a criticism of AI as a whole, just this piece.
Note, I am a co-maintainer of GNU coreutils. Whether that makes my opinion relevant, biased, or both, you can decide. :)
I really wished the documented their benchmarking methodology here, or at least cautioned the reader not to jump to conclusions based on the benchmarks shown.
GNU 'sort' performance can drastically be altered by the locale in use, the input, and the arguments given to the --buffer-size and --parallel options. GNU 'sort' is fairly conservative in how many threads it will use by default, and in my experience, much more so than uutils. This is because throwing more threads at 'sort' may make it faster (or may not), but also risks running out of memory. This is an issue with uutils, which is poor at deciding when to use external sorting:
$ export LC_ALL=C
$ for i in {a..z}; do yes $i | head -n $(numfmt --from=iec 512M) | tr -d '\n' >> input; done
$ time sort input > /dev/null
real 0m24.245s
user 0m0.896s
sys 0m19.161s
Here is the same command using the latest uutils commit compiled with 'make PROFILE=release':
$ time uu-sort input > /dev/null
Killed uu-sort input > /dev/null
real 2m53.560s
user 1m40.634s
sys 0m59.847s
The process gets killed by the OOM killer. This is likely because uutils 'sort' decides to use 18 threads, instead of the 1 used by GNU 'sort'. I find it a bit frustrating that benchmarks are thrown out without any methodology or citations, because they are often trusted without question. These could be benchmarks from before uutils had localization, which was the case before 2025, and treated LC_ALL=en_US.UTF-8 as LC_ALL=C. In that case, of course it would be much faster than GNU coreutils, but it also means uutils would give you the wrong results for non-ASCII characters. There is, as shown above, much more considerations beyond speed that seemingly never get the time of day next to flashy benchmarks...
There’s none of those details because it’s an AI written article. It doesn’t even talk about the stuff it says it’s going to in the very first paragraph.
Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?
As it stands I am generally averse to using GNU tools because my feeling is that they will be slow, clunky and exhibit arcane behavior in particular edge cases. ripgrep is significantly faster than GNU grep -R; fd than GNU find, etc.
For example, before LLMs were common, I once had to spend an entire day getting GNU flex and GNU bison to generate code that was: a) properly prefixed with a custom prefix, not yy_ et. al and b) did not use global variables.
I would have understood if, for backwards compatibility, this was gated behind a --sane flag or similar, but the GNU manuals were, at least at the time, under the confusing impression that what I was doing was advanced usage and used semi-fancy terms like "re-enterant" to describe what should be the normal behavior. I had to toggle several different knobs, some working for macros, others for functions, and the knobs were different for flex and bison.
POSIX locales in particular are an anti-feature, and I say this as a non-English native, so uutils adding support for them feels like bug-compatibility with GNU, not feature-compatibility.
Other issues involve the dynamic linking requirements of glibc and of the nsswitch in a world that would increasingly prefer to link things statically.
I am really saddened if the reaction is just that GNU is the old and stable is the main argument here. Because when you read many GNU documents and manpages, written years ago, you get the feeling that the original authors were looking to do things properly, make breaking changes where they were sane (hence POSIXLY_CORRECT), innovate (Emacs), and overall would not have been particularly swayed by the "old and stable" argument of traditional Unix distributions at the time.
The Rust community seems to be the one making exciting innovative stuff nowadays. uucore is more complimentary as well, ripgrep and fd are much more interesting. Sure, there may be certainly kinks, as you pointed out. But Rust programs can be debugged. Can GNU programs innovate?
Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?
Most GNU projects don't have a large overlap, if any overlap at all, between their active contributors. I suspect they behave far more independently than you expect. Also, GNU didn't invent locales, if that is what you are getting at.
As it stands I am generally averse to using GNU tools because my feeling is that they will be slow, clunky and exhibit arcane behavior in particular edge cases. ripgrep is significantly faster than GNU grep -R; fd than GNU find, etc.
Those programs have their imperfections as well. Particularly, they don't account for arbitrary limits like PATH_MAX. See 'fd' stops before visiting the deepest directory without altering it's exit code:
On the other hand GNU find can visit arbitrarily deep directories:
$ find a | wc -l
16384
ripgrep has similar issues:
$ (while cd $(yes a/ | head -n 1024 | tr -d '\n'); do :; done > /dev/null 2>&1; echo a > a)
$ rg '^a$' a
rg: a/[...]/a: File name too long (os error 36)
GNU grep handles this fine:
$ grep -r '^a$' a
a/[...]/a:a
> For example, before LLMs were common, I once had to spend an entire day getting GNU flex and GNU bison to generate code that was: a) properly prefixed with a custom prefix, not yy_ et. al and b) did not use global variables.
Flex isn't a GNU project. I don't use or contribute to Bison, but I am pretty sure that is here:
I would have understood if, for backwards compatibility, this was gated behind a --sane flag or similar, but the GNU manuals were, at least at the time, under the confusing impression that what I was doing was advanced usage and used semi-fancy terms like "re-enterant" to describe what should be the normal behavior. I had to toggle several different knobs, some working for macros, others for functions, and the knobs were different for flex and bison.
Again, I don't contribute to Flex or Bison. I also do not use them. However, I will note that understanding the programs require some complex topics, specifically formal languages and automata. I am not entirely surprised that some of the documentation can be a bit difficult to understand.
POSIX locales in particular are an anti-feature, and I say this as a non-English native, so uutils adding support for them feels like bug-compatibility with GNU, not feature-compatibility.
They are also widely supported by other implementations. It would be harmful to everyone if we were to disregard them. Also, as I mentioned previously, they were not invented by GNU.
Other issues involve the dynamic linking requirements of glibc and of the nsswitch in a world that would increasingly prefer to link things statically.
I am a committer to glibc, but this isn't really my area of focus. You are free to discuss it on libc-help@sourceware.org if you'd like.
I am really saddened if the reaction is just that GNU is the old and stable is the main argument here. Because when you read many GNU documents and manpages, written years ago, you get the feeling that the original authors were looking to do things properly, make breaking changes where they were sane (hence POSIXLY_CORRECT), innovate (Emacs), and overall would not have been particularly swayed by the "old and stable" argument of traditional Unix distributions at the time.
We make breaking changes. I recently changed 'printenv' and 'env' to safely quote their output. I will note though that although you want us to make more changes like this, others get quite angry at us when we do. Even changes that aren't breaking cause angry mailing list messages. We can't make everyone happy.
Can GNU programs innovate?
Individual GNU projects are free to innovate as much or as little as they want.
Thanks for taking the time to respond to all my points!
Unfortunately, I find this confirms all my fears.
Whether or not ripgrep, fd, sd, et al. have some bugs left in them or not, the fact remains, when they do work (which is 99%+ of the time for most users), they are significantly more pleasant to work with. More pleasant = more use = more eyes = the bugs get fixed in the long run (as GNU should know from it's history!).
I wish everyone all the best, but I really do see a lot of these tools going the way of X.org in the next 10 years. Or, more likely, the way of csh.
However, I will note that understanding the programs require some complex topics, specifically formal languages and automata. I am not entirely surprised that some of the documentation can be a bit difficult to understand.
And it has every right to be, when it is discussing these topics. But not polluting the global namespace and not using global variables is not an advanced request!
Yes, I thought that too. But no, that wouldn't be realistic. Their IDEs are massive, to rewrite them in Rust they would probably also have to rewrite half of the library code in the Java ecosystem.
This post advocates rewriting incrementally instead of all at once. Just like Joel said back in 2000, and like everyone continues to always say to this day. Yet in practice, people don't actually do this; complete rewrites in Rust remain far more common than incremental ones, particularly when rewriting from a language other than C. The high-profile exceptions, like Linux, Windows, and Firefox, are codebases so huge and ancient that they obviously cannot be rewritten from scratch. When rewriting from scratch is an option, it tends to be taken.
The reason for this is pretty straightforward: Incrementally porting a codebase from another language to Rust (especially if it's not C) is a deeply unpleasant experience, because the interop tooling isn't good enough and you spend most of your time fighting it. Consider the case of rewriting from C++; in the simplest case, you use bindgen and cbindgen, which only work with extern "C" functions in both languages. So you effectively have to rewrite each API first from idiomatic C++ to C-in-C++, then translate to C-in-Rust, then rewrite again in idiomatic Rust. And then repeat for the next API. And so on. It's not going to take long for most programmers to go "screw it, I don't care what Joel said, at least when I rewrite all my work I'll be doing it in one language where anything can call anything else". cxx and autocxx modestly improve things, but still leave you with an impoverished API vocabulary and similar problems, and you still have to do the three-step rewrite for each API, one at a time.
This is also why TypeScript, Kotlin, and Swift worked so hard to have seamless two-way interop with JavaScript, Java, and Objective-C. Without that, they couldn't have credibly promised to replace the earlier languages (because large existing codebases where a rewrite wasn't economical would still be stuck with them), and so couldn't have gotten off the ground.
Crubit is supposed to fix this for C++-to-Rust, and I'm rooting really hard for it, but it's not there yet. For most other languages, a Crubit-like thing probably isn't even possible in principle, because the differences are too great.
(I'm not talking here about the use case where you started with a garbage-collected language but have hit a performance ceiling with it, so you rewrite just the most performance-sensitive parts in Rust, while continuing to develop the rest of the codebase in the original language. This is often a great way to use Rust, but it's solving an easier problem and so poses fewer difficult tradeoffs.)
complete rewrites in Rust remain far more common than incremental ones, particularly when rewriting from a language other than C.
Well yeah, that has obvious practical reasons: unless you're using C/C++, you can't really link Rust code with your codebase (or you could theoretically do it, but in a way that would affect performance and/or complicate your architecture). So, if you're going to do it at all, a full rewrite makes more sense.
Was just testing latest gen LLM capabilities, and decided to give it goal of rewriting a small opensource project in Rust. (Should be noted: was not some tiny library, but an actually useful network service).
It completed the entire rewrite from typescript to rust in about 2 hours, ~600k tokens used. Worked perfectly on first try with no follow up changes required. Memory and CPU usage now a tiny fraction of TS version (obviously). Rust code was simple, easy to read, accurate test suite, etc.
I was pleasantly surprised.
Obviously bigger code bases with more complex business logic will likely struggle here, but there are some advantages to "RIIR" when performance matters, even security benefits aside. Rust can help squeeze more juice out of old hardware; reduced memory footprint especially helpful with current RAM prices.
For small services where operational cost matters, having LLMs "rewrite it in rust" might be worth the spend.
I’ve seen people do this and I’m always confused, do they believe they will never have to reason about the code ever again.
I suppose if it is like the Zig Rewrite where essentially all development is being done by Claude, I can imagine this making sense.
But in any other case, you had a codebase that presumably you wrote, you could reason about, you could refactor etc. and then you made it into a completely unintelligible code base, which even if written cleanly will take a long time to reason about. Typescript to Rust is not just syntax changes. It doesn’t make sense to me, unless you believe you will be completely out of the loop in managing this code in the future.
A small typescript util rewritten into rust is going to look so similar that I don't think this will be a problem. As the parent commenter said, maybe not for a larger project. But rust semantics are really close to typescript for the most part, at least the bits you'd use for a simple tool.
This wasn't a codebase I originally wrote or cared to reason about deeply. It's fairly straight-forward rust, so not hard to understand or follow. Again, this was originally just a test to see how well it would work (better than I expected).
Not something I need to maintain much going forward, so I have no reason to manage the code manually ever.
This topic has somewhat recently acquired a connotation where it yields a polarized response. People seem "tired" of the language and the episodes like Bun rewrite don't help, especially in current LLM-obsessed era.
Amidst this, just let me try to give my own experience with language while working in a field where it doesn't have much traction (scientific/numerical programming). A couple of years ago, after being tired trying to make Python faster, I was looking for a language to write simulation code in. Fortran (and C/C++) has been the go-to choice in my field for decades but I wanted to try a modern language. I tried Julia but the workflow didn't come naturally to me. Also by default, it also wasn't ahead-of-time compilable. Rust was my second choice but it's type system/design, expressiveness and tooling (rust-analyzer) won me over. I have written so much of it and I really enjoy writing it. Borrow checker isn't really an issue 99% of time when writing scientific code. And when it is (self-referential data structures), you can just use an arena (or something equivalent). The C/Fortran inter-op is great so it's still so easy for me to build my own abstractions on top for the more general stuff like solving ODEs and sparse matrices.
And of course, there is speed, memory safety and ability to parallelize things so effortlessly (rayon is magical), but I feel those were never the things that actually won me over. The language was just a joy to write.
I would love it if jetbrains were to speed up IntelliJ. I started a new job writing Java professionally last year and, up that point, I had no idea that IDE's could actually be that slow.
My company gave me a brand new, beefy Macbook pro and that thing can barely handle IntelliJ sometimes...
But what about <some obscure feature that you use once in a blue moon and could’ve been achieved using some CLI faster than you could remember an IntelliJ shortcut for it>! It’s an IDE, not an editor!
That comparison figure of LaTeX vs Typst is ridiculous, choosing math-dense example for LaTeX vs classical markdown text for Typst. Yes, Typst syntax is much simpler https://typst.app/docs/reference/math/ but one doesn't need to make unfair comparisons to make Rust look better, Rust has a lot of good things going for it anyway, for example cargo.
There have been times I needed to yell at Claude to rewrite some Python program into a faster lang because it was truly CPU-bound. I chose Rust purely cause of Cargo and the rest of the toolchain, despite being way more familiar with C++ (did use Rust but it was 9y ago). Didn't even care about the borrow-checker for that.
I think that a line-for-line rewrite in Rust like Bun did isn’t really getting all of the benefits of using Rust. A key benefit is utilizing the type system to make the borrow checker work for you by making certain checks happen at compile-time instead of runtime. Making it impossible for certain mistakes to occur is a massive benefit but you need to restructure everything to do so.
The Bun rewrite is a long-term investment; the idea is that you initially compromise on idiomatic Rust for the sake of being able to keep shipping, but then the codebase becomes more idiomatically Rust-like over time. It will probably take another year or so to determine whether this works out.
(Note also that Bun inherently needs to use a lot of unsafe because a large fraction of its internal API surface is interlinked deeply and pervasively with that of JavaScriptCore.)
To me Rust is great where you don’t have to touch unsafe part. All the hard works are done by those skillful maintainers of the language and some core libraries such as tokio. I don’t see much value in it if either I have to work on the low-level stuff quickly (like implementing linked lists myself) or a complete high-level of i/o bound work like writing web servers.
I understand that's a guest post in Jetbrains blog, and these guests could very well be real people, project maintainers, conference speakers and whatnot, but I feel they used LLM so heavily that it reads like a slop. Pease do better next time.
Yes, there are quite a few signs of LLM usage in the post, which I also found annoying. But I also had the feeling that someone really cared about the quality of the text and I found only one strange/useless sentence in the post, which today has to be taken as a win, I guess.
I had the same impression, and Occam's Razor suggests that the reason is because the author wrote it with the heavy assistance of a language model. But I do wonder if might also be a certain proportion of the tech industry that has started internalising LLM speak and uses it even in writing that is authentically their own.
I think every project should seriously ask itself if it actually needs manual memory management. My hunch is that most people who think they need it, do not. If you really truly do need it, then yes Rust is a great way to get most of the benefits of garbage collection while still having manual control over memory.
I wouldn't consider Rust a manual memory environment. There are ways to do that at edges if needed, but it is otherwise very much automatic which is kind of the whole point of its design.
I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management
I wouldn't consider Swift manually managed, but also not GC. And not being GC has some practical implications like needing to break cycles yourself, so you need to at least be aware of ownership a little. It's like a manual transmission vs automated manual vs true automatic, AMT removes most of the work but still cannot be treated like full auto.
You're referring specifically to tracing garbage collection. When a reference count reaches zero, that garbage is collected, often recursively. Among programming language designers, ARC is considered a GC strategy.
Refcounting isn't GC, but also C++ isn't a refcounted language. You could spam shared_ptr everywhere, but it's not designed for that and probably wouldn't be performant. And because of that, realistically all your libs take raw pointers, so you still have to unwrap your shared_ptrs then be back to managing ownership.
Swift has refcounting built into the language and assumed everywhere. You could always use raw refs in Swift, but that's not the norm.
... Part of this comes from auto-vectorization: the Rust compiler generates SIMD instructions automatically from a regular for loop, while most C implementations require hand-written SIMD...
I understand that their compiler in Rust is better. And any other language could compile it using the same SIMD instructions.
I appreciate rewrite isn't always the answer but it's a strange post when the authors should be giving constructive ways forward so we move to Rust and then use their 1k star Django clone they link to.
Instead anytime a question is posed it falls back to "sometimes" and little detail after that.
Citing a nine year old paper instead of something newer or doing their own benchmarking wasn't ideal either.
And then there’s the Stack Overflow Developer Survey.
Honest question, at what point is the Stack Overflow Developer Survey not representative of the average software engineer, many (most?) of who no longer use Stack Overflow?
Good question. I no longer use SO at all, it's been years now, but I still get the yearly developer survey email alert, and I still take the time to answer, I take it most people doing the survey is the same...
Typst is a good example of the readability argument:
I'm afraid the author completely missed the point here. Typst is not more readable than (La)TeX because it's written in Rust, but because its DSL was so designed. It could have been implemented in PHP that the result would be exactly the same.
Same thing with the auto-unroll/SIMD arguments. AFAIK, it's LLVM that's doing the job, there is nothing theoretically preventing a {language} compiler to obtain the same results.
Where Rust shines w.r.t. other similar languages though is that its strict memory model lets developers push further memory/concurrency optimization without sacrificing safety – which she highlights in the GNU/coreutils sort comparison.
Is this really an alternative? I would never replace battle proved TeX with consistent syntax, build for processing text, with great fonts, thousands of plugins for some Markdown mess, which is, in addition, paid.
I'd argue the syntax is much simpler, more modern, and perhaps even more consistent (the fact that in TeX you can change the meaning of the escape symbol or the comment symbol is pure insanity IMHO). It can use any font, and the feature you know from LaTeX, a compiler, is free. Only the web application has some premium features. It's more like Overleaf. It's also several orders of magnitudes faster and has actually helpful error messages.
The fact that it was written in Rust is less than secondary.
I don't think the main scientific journals accept it, so for that it is not a replacement. However, I would say that for most usages it's a good alternative even if it doesn't have all the ecosystem of 50 years of tex/latex
Comments
This feels like a really good blog post to write - something I'd really want to read - but the generated AI prose distracts, and makes me lose trust and not want to read this. I'm very AI-pilled, so this is not a criticism of AI as a whole, just this piece.
Note, I am a co-maintainer of GNU coreutils. Whether that makes my opinion relevant, biased, or both, you can decide. :)
I really wished the documented their benchmarking methodology here, or at least cautioned the reader not to jump to conclusions based on the benchmarks shown.
GNU 'sort' performance can drastically be altered by the locale in use, the input, and the arguments given to the --buffer-size and --parallel options. GNU 'sort' is fairly conservative in how many threads it will use by default, and in my experience, much more so than uutils. This is because throwing more threads at 'sort' may make it faster (or may not), but also risks running out of memory. This is an issue with uutils, which is poor at deciding when to use external sorting:
Here is the same command using the latest uutils commit compiled with 'make PROFILE=release': The process gets killed by the OOM killer. This is likely because uutils 'sort' decides to use 18 threads, instead of the 1 used by GNU 'sort'. I find it a bit frustrating that benchmarks are thrown out without any methodology or citations, because they are often trusted without question. These could be benchmarks from before uutils had localization, which was the case before 2025, and treated LC_ALL=en_US.UTF-8 as LC_ALL=C. In that case, of course it would be much faster than GNU coreutils, but it also means uutils would give you the wrong results for non-ASCII characters. There is, as shown above, much more considerations beyond speed that seemingly never get the time of day next to flashy benchmarks...There’s none of those details because it’s an AI written article. It doesn’t even talk about the stuff it says it’s going to in the very first paragraph.
That's a really great point, and demonstrates a deep understanding of how AI is changing the landscape of writing online!
Did I just read an HN comment written by an AI? Looks sycophantic enough
I believe that is "The Joke"
You are absolutely right! It's not just that you spotted it, it's how you pointed it out that make your comment upvote worthy
changing the landscape of writi' you mean fucking shit up to the point of no return?
Hi, co-maintainer of GNU coreutils!
Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?
As it stands I am generally averse to using GNU tools because my feeling is that they will be slow, clunky and exhibit arcane behavior in particular edge cases. ripgrep is significantly faster than GNU grep -R; fd than GNU find, etc.
For example, before LLMs were common, I once had to spend an entire day getting GNU flex and GNU bison to generate code that was: a) properly prefixed with a custom prefix, not yy_ et. al and b) did not use global variables.
I would have understood if, for backwards compatibility, this was gated behind a --sane flag or similar, but the GNU manuals were, at least at the time, under the confusing impression that what I was doing was advanced usage and used semi-fancy terms like "re-enterant" to describe what should be the normal behavior. I had to toggle several different knobs, some working for macros, others for functions, and the knobs were different for flex and bison.
POSIX locales in particular are an anti-feature, and I say this as a non-English native, so uutils adding support for them feels like bug-compatibility with GNU, not feature-compatibility.
Other issues involve the dynamic linking requirements of glibc and of the nsswitch in a world that would increasingly prefer to link things statically.
I am really saddened if the reaction is just that GNU is the old and stable is the main argument here. Because when you read many GNU documents and manpages, written years ago, you get the feeling that the original authors were looking to do things properly, make breaking changes where they were sane (hence POSIXLY_CORRECT), innovate (Emacs), and overall would not have been particularly swayed by the "old and stable" argument of traditional Unix distributions at the time.
The Rust community seems to be the one making exciting innovative stuff nowadays. uucore is more complimentary as well, ripgrep and fd are much more interesting. Sure, there may be certainly kinks, as you pointed out. But Rust programs can be debugged. Can GNU programs innovate?
Most GNU projects don't have a large overlap, if any overlap at all, between their active contributors. I suspect they behave far more independently than you expect. Also, GNU didn't invent locales, if that is what you are getting at.
Those programs have their imperfections as well. Particularly, they don't account for arbitrary limits like PATH_MAX. See 'fd' stops before visiting the deepest directory without altering it's exit code:
On the other hand GNU find can visit arbitrarily deep directories: ripgrep has similar issues: GNU grep handles this fine: > For example, before LLMs were common, I once had to spend an entire day getting GNU flex and GNU bison to generate code that was: a) properly prefixed with a custom prefix, not yy_ et. al and b) did not use global variables.Flex isn't a GNU project. I don't use or contribute to Bison, but I am pretty sure that is here:
https://www.gnu.org/software/bison/manual/bison.html#Multipl...
Again, I don't contribute to Flex or Bison. I also do not use them. However, I will note that understanding the programs require some complex topics, specifically formal languages and automata. I am not entirely surprised that some of the documentation can be a bit difficult to understand.
They are also widely supported by other implementations. It would be harmful to everyone if we were to disregard them. Also, as I mentioned previously, they were not invented by GNU.
I am a committer to glibc, but this isn't really my area of focus. You are free to discuss it on libc-help@sourceware.org if you'd like.
We make breaking changes. I recently changed 'printenv' and 'env' to safely quote their output. I will note though that although you want us to make more changes like this, others get quite angry at us when we do. Even changes that aren't breaking cause angry mailing list messages. We can't make everyone happy.
Individual GNU projects are free to innovate as much or as little as they want.
Thanks for taking the time to respond to all my points!
Unfortunately, I find this confirms all my fears.
Whether or not ripgrep, fd, sd, et al. have some bugs left in them or not, the fact remains, when they do work (which is 99%+ of the time for most users), they are significantly more pleasant to work with. More pleasant = more use = more eyes = the bugs get fixed in the long run (as GNU should know from it's history!).
I wish everyone all the best, but I really do see a lot of these tools going the way of X.org in the next 10 years. Or, more likely, the way of csh.
And it has every right to be, when it is discussing these topics. But not polluting the global namespace and not using global variables is not an advanced request!
For a brief second I thought JetBrains were rewriting their tools in Rust and we were going to get some performance improvements.
Yes, I thought that too. But no, that wouldn't be realistic. Their IDEs are massive, to rewrite them in Rust they would probably also have to rewrite half of the library code in the Java ecosystem.
Wasn’t their newer text editor/IDE written in Rust? I forgot how it was called and also didn’t followed up with their development.
It was called Fleet (I almost forgot about it too) and has since been retired: https://blog.jetbrains.com/fleet/2025/12/the-future-of-fleet...
(if you wanted to be snarky, you could say that Fleet dissolved into thin Air)
No, Fleet was written in Kotlin running on the JVM. I seem to remember it used Skia for the UI.
This post advocates rewriting incrementally instead of all at once. Just like Joel said back in 2000, and like everyone continues to always say to this day. Yet in practice, people don't actually do this; complete rewrites in Rust remain far more common than incremental ones, particularly when rewriting from a language other than C. The high-profile exceptions, like Linux, Windows, and Firefox, are codebases so huge and ancient that they obviously cannot be rewritten from scratch. When rewriting from scratch is an option, it tends to be taken.
The reason for this is pretty straightforward: Incrementally porting a codebase from another language to Rust (especially if it's not C) is a deeply unpleasant experience, because the interop tooling isn't good enough and you spend most of your time fighting it. Consider the case of rewriting from C++; in the simplest case, you use bindgen and cbindgen, which only work with extern "C" functions in both languages. So you effectively have to rewrite each API first from idiomatic C++ to C-in-C++, then translate to C-in-Rust, then rewrite again in idiomatic Rust. And then repeat for the next API. And so on. It's not going to take long for most programmers to go "screw it, I don't care what Joel said, at least when I rewrite all my work I'll be doing it in one language where anything can call anything else". cxx and autocxx modestly improve things, but still leave you with an impoverished API vocabulary and similar problems, and you still have to do the three-step rewrite for each API, one at a time.
This is also why TypeScript, Kotlin, and Swift worked so hard to have seamless two-way interop with JavaScript, Java, and Objective-C. Without that, they couldn't have credibly promised to replace the earlier languages (because large existing codebases where a rewrite wasn't economical would still be stuck with them), and so couldn't have gotten off the ground.
Crubit is supposed to fix this for C++-to-Rust, and I'm rooting really hard for it, but it's not there yet. For most other languages, a Crubit-like thing probably isn't even possible in principle, because the differences are too great.
(I'm not talking here about the use case where you started with a garbage-collected language but have hit a performance ceiling with it, so you rewrite just the most performance-sensitive parts in Rust, while continuing to develop the rest of the codebase in the original language. This is often a great way to use Rust, but it's solving an easier problem and so poses fewer difficult tradeoffs.)
Well yeah, that has obvious practical reasons: unless you're using C/C++, you can't really link Rust code with your codebase (or you could theoretically do it, but in a way that would affect performance and/or complicate your architecture). So, if you're going to do it at all, a full rewrite makes more sense.
Small related anecdote:
Was just testing latest gen LLM capabilities, and decided to give it goal of rewriting a small opensource project in Rust. (Should be noted: was not some tiny library, but an actually useful network service).
It completed the entire rewrite from typescript to rust in about 2 hours, ~600k tokens used. Worked perfectly on first try with no follow up changes required. Memory and CPU usage now a tiny fraction of TS version (obviously). Rust code was simple, easy to read, accurate test suite, etc.
I was pleasantly surprised.
Obviously bigger code bases with more complex business logic will likely struggle here, but there are some advantages to "RIIR" when performance matters, even security benefits aside. Rust can help squeeze more juice out of old hardware; reduced memory footprint especially helpful with current RAM prices.
For small services where operational cost matters, having LLMs "rewrite it in rust" might be worth the spend.
I’ve seen people do this and I’m always confused, do they believe they will never have to reason about the code ever again.
I suppose if it is like the Zig Rewrite where essentially all development is being done by Claude, I can imagine this making sense.
But in any other case, you had a codebase that presumably you wrote, you could reason about, you could refactor etc. and then you made it into a completely unintelligible code base, which even if written cleanly will take a long time to reason about. Typescript to Rust is not just syntax changes. It doesn’t make sense to me, unless you believe you will be completely out of the loop in managing this code in the future.
A small typescript util rewritten into rust is going to look so similar that I don't think this will be a problem. As the parent commenter said, maybe not for a larger project. But rust semantics are really close to typescript for the most part, at least the bits you'd use for a simple tool.
This wasn't a codebase I originally wrote or cared to reason about deeply. It's fairly straight-forward rust, so not hard to understand or follow. Again, this was originally just a test to see how well it would work (better than I expected).
Not something I need to maintain much going forward, so I have no reason to manage the code manually ever.
This topic has somewhat recently acquired a connotation where it yields a polarized response. People seem "tired" of the language and the episodes like Bun rewrite don't help, especially in current LLM-obsessed era.
Amidst this, just let me try to give my own experience with language while working in a field where it doesn't have much traction (scientific/numerical programming). A couple of years ago, after being tired trying to make Python faster, I was looking for a language to write simulation code in. Fortran (and C/C++) has been the go-to choice in my field for decades but I wanted to try a modern language. I tried Julia but the workflow didn't come naturally to me. Also by default, it also wasn't ahead-of-time compilable. Rust was my second choice but it's type system/design, expressiveness and tooling (rust-analyzer) won me over. I have written so much of it and I really enjoy writing it. Borrow checker isn't really an issue 99% of time when writing scientific code. And when it is (self-referential data structures), you can just use an arena (or something equivalent). The C/Fortran inter-op is great so it's still so easy for me to build my own abstractions on top for the more general stuff like solving ODEs and sparse matrices.
And of course, there is speed, memory safety and ability to parallelize things so effortlessly (rayon is magical), but I feel those were never the things that actually won me over. The language was just a joy to write.
I would love it if jetbrains were to speed up IntelliJ. I started a new job writing Java professionally last year and, up that point, I had no idea that IDE's could actually be that slow.
My company gave me a brand new, beefy Macbook pro and that thing can barely handle IntelliJ sometimes...
Just use VS Code. Its Java support isn’t the best, but it’s good enough and the rest of the IDE makes up for it.
I feel like a lot of the love for IntelliJ is a sort of Stockholm Syndrome combined with relief at not using Eclipse.
But what about <some obscure feature that you use once in a blue moon and could’ve been achieved using some CLI faster than you could remember an IntelliJ shortcut for it>! It’s an IDE, not an editor!
What CLI can I use to extract an interface from a class?
open-code run "extract interface x from class y"
I’ve been using cursor mainly (so sorta vscode in a way). I just use IntelliJ for unit tests and the debugger mainly.
That comparison figure of LaTeX vs Typst is ridiculous, choosing math-dense example for LaTeX vs classical markdown text for Typst. Yes, Typst syntax is much simpler https://typst.app/docs/reference/math/ but one doesn't need to make unfair comparisons to make Rust look better, Rust has a lot of good things going for it anyway, for example cargo.
I think he forgot to praise cargo.
(Imho, having cargo available is often already worth a RIIR.)
There have been times I needed to yell at Claude to rewrite some Python program into a faster lang because it was truly CPU-bound. I chose Rust purely cause of Cargo and the rest of the toolchain, despite being way more familiar with C++ (did use Rust but it was 9y ago). Didn't even care about the borrow-checker for that.
I think that a line-for-line rewrite in Rust like Bun did isn’t really getting all of the benefits of using Rust. A key benefit is utilizing the type system to make the borrow checker work for you by making certain checks happen at compile-time instead of runtime. Making it impossible for certain mistakes to occur is a massive benefit but you need to restructure everything to do so.
The Bun rewrite is a long-term investment; the idea is that you initially compromise on idiomatic Rust for the sake of being able to keep shipping, but then the codebase becomes more idiomatically Rust-like over time. It will probably take another year or so to determine whether this works out.
(Note also that Bun inherently needs to use a lot of unsafe because a large fraction of its internal API surface is interlinked deeply and pervasively with that of JavaScriptCore.)
To me Rust is great where you don’t have to touch unsafe part. All the hard works are done by those skillful maintainers of the language and some core libraries such as tokio. I don’t see much value in it if either I have to work on the low-level stuff quickly (like implementing linked lists myself) or a complete high-level of i/o bound work like writing web servers.
I understand that's a guest post in Jetbrains blog, and these guests could very well be real people, project maintainers, conference speakers and whatnot, but I feel they used LLM so heavily that it reads like a slop. Pease do better next time.
Yes, there are quite a few signs of LLM usage in the post, which I also found annoying. But I also had the feeling that someone really cared about the quality of the text and I found only one strange/useless sentence in the post, which today has to be taken as a win, I guess.
I had the same impression, and Occam's Razor suggests that the reason is because the author wrote it with the heavy assistance of a language model. But I do wonder if might also be a certain proportion of the tech industry that has started internalising LLM speak and uses it even in writing that is authentically their own.
There are a lot of Claudisms[1] in there for sure.
1:https://claudisms.ai
I think every project should seriously ask itself if it actually needs manual memory management. My hunch is that most people who think they need it, do not. If you really truly do need it, then yes Rust is a great way to get most of the benefits of garbage collection while still having manual control over memory.
I wouldn't consider Rust a manual memory environment. There are ways to do that at edges if needed, but it is otherwise very much automatic which is kind of the whole point of its design.
What most people mean when they say this is GC vs no GC. Rust is the latter. You have to care about ownership unless you're wrapping in Rc/Arc.
I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management
I wouldn't consider Swift manually managed, but also not GC. And not being GC has some practical implications like needing to break cycles yourself, so you need to at least be aware of ownership a little. It's like a manual transmission vs automated manual vs true automatic, AMT removes most of the work but still cannot be treated like full auto.
Good point, I like your formulation
Refcounting is indeed a form of GC (and the languages that want to handle cycles then need an extra form of GC on top of it).
GC specifically means you leave unreferenced mem on the heap until it gets collected in one big sweep later.
You're referring specifically to tracing garbage collection. When a reference count reaches zero, that garbage is collected, often recursively. Among programming language designers, ARC is considered a GC strategy.
https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...
https://users.rust-lang.org/t/reference-counting-garbage-col...
No, I would consider refcounting as variants of GC.
if refcounting is gc, then c++ is a garbage collected language. It has std::shared_ptr
Refcounting isn't GC, but also C++ isn't a refcounted language. You could spam shared_ptr everywhere, but it's not designed for that and probably wouldn't be performant. And because of that, realistically all your libs take raw pointers, so you still have to unwrap your shared_ptrs then be back to managing ownership.
Swift has refcounting built into the language and assumed everywhere. You could always use raw refs in Swift, but that's not the norm.
No
E.g. in Swift the reference counting is automatic a d implicit
In C++ it is manual and explicit
I understand that their compiler in Rust is better. And any other language could compile it using the same SIMD instructions.
Well they should rewrite their shitty sluggish new JS UI in Rust then.
Oh no, what are we hiding?
Isn't this why every bug fix gets a unit test?
I appreciate rewrite isn't always the answer but it's a strange post when the authors should be giving constructive ways forward so we move to Rust and then use their 1k star Django clone they link to.
Instead anytime a question is posed it falls back to "sometimes" and little detail after that.
Citing a nine year old paper instead of something newer or doing their own benchmarking wasn't ideal either.
Honest question, at what point is the Stack Overflow Developer Survey not representative of the average software engineer, many (most?) of who no longer use Stack Overflow?
Good question. I no longer use SO at all, it's been years now, but I still get the yearly developer survey email alert, and I still take the time to answer, I take it most people doing the survey is the same...
I'm afraid the author completely missed the point here. Typst is not more readable than (La)TeX because it's written in Rust, but because its DSL was so designed. It could have been implemented in PHP that the result would be exactly the same.
Same thing with the auto-unroll/SIMD arguments. AFAIK, it's LLVM that's doing the job, there is nothing theoretically preventing a {language} compiler to obtain the same results.
Where Rust shines w.r.t. other similar languages though is that its strict memory model lets developers push further memory/concurrency optimization without sacrificing safety – which she highlights in the GNU/coreutils sort comparison.
And here I thought they’re finally rewriting their slow, bloated IDEs. Shame.
"Typst instead of LaTeX"
Is this really an alternative? I would never replace battle proved TeX with consistent syntax, build for processing text, with great fonts, thousands of plugins for some Markdown mess, which is, in addition, paid.
Only because it is written in Rust, not in C.
Yes it is, for many use cases.
I'd argue the syntax is much simpler, more modern, and perhaps even more consistent (the fact that in TeX you can change the meaning of the escape symbol or the comment symbol is pure insanity IMHO). It can use any font, and the feature you know from LaTeX, a compiler, is free. Only the web application has some premium features. It's more like Overleaf. It's also several orders of magnitudes faster and has actually helpful error messages.
The fact that it was written in Rust is less than secondary.
Also, TeX was written in WEB, not C.
Typst is neither markdown nor proprietary, and can use any font you have installed.
https://github.com/typst/typst/blob/main/LICENSE
I don't think the main scientific journals accept it, so for that it is not a replacement. However, I would say that for most usages it's a good alternative even if it doesn't have all the ecosystem of 50 years of tex/latex