How (and why) we rewrote our production C++ frontend infrastructure in Rust

24 points by abareplace 12 hours ago on lobsters | 2 comments

david_chisnall | 9 hours ago

But, come on, it’s 2026, and “lowercase a string” is still too much to ask from the language’s standard library?

The advantage, in theory, of the C++ approach is that it's agnostic to the string representation. That is a big deal: optimising the string representation in different ways is something I've seen give a 2x or more end-to-end performance improvement, in codebases that wanted completely different string representations.

The problem is: the C++ approach is staggeringly bad for this. Unless you do a lot of inlining in exactly the right order, the result may not be vectorisable. And the tolower function almost certainly isn't anyway (and is probably using the libc one, not the ICU one, so may or may not actually do the right thing for the correct locale. Oh, you did remember that this is a domain name, right? So you probably don't want the default locale behaviour (you did remember that in the Rust version too, I hope?).

Making strings both efficient across different use cases and ergonomic is really hard. C++ fails on both counts.

fazalmajid | 3 hours ago

Indeed, Unicode is loaded with footguns. It's not as if Rust strings don't have their own issues, like the fact String::truncate() can panic...