3 ms·
> A big parallel rewrite is not the only possible approach to writing Rust. A rewrite is the only way to convert the codebase to Rust or any other memory safe
by timschmidt 2y ago
> A big parallel rewrite is not the only possible approach to writing Rust.
A rewrite is the only way to convert the codebase to Rust or any other memory safe language. Whether that happens in parallel, piecemeal, or both at the same time is down to how well you use a version control system and structure your code. As has already been shown by sharing Servo code with Firefox.
A full rewrite is particularly useful with Rust, as the language wants you to structure your code differently than most C/C++ is structured. Doesn't make sense not to have one going if that's the plan. If you're going to rewrite the whole thing anyway, might as well do it in an idiomatic way.
- bogeholm 2y ago> A full rewrite Things You Should Never Do, Part I [0] [0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- timschmidt 2y agoThings Mozilla have done a few times.[0] All with valid reason. 30 years without a rewrite is pretty rare for any piece of software. 0: https://en.wikipedia.org/wiki/Netscape_Navigator https://en.wikipedia.org/wiki/Netscape_Navigator
- steveklabnik 2y agoGoogle has demonstrated that writing new code in a memory safe language still significantly improves the safety story of a codebase, even while keeping around the old code. Full scale rewrites are not the only option.
- timschmidt 2y agoYes, every line of C/C++ you can replace with a memory safe language in a critical codebase like a browser improves it's safety story. Which is exactly the reason replacing all of it is so attractive. But just to offer another point, I also still run into memory leaks and other performance issues in long-lived Firefox processes which, based on my experience with Rust, would be unlikely to be a problem in a functional Servo. It'd be nice to have a browser I don't have to occasionally kill and restart just to keep Youtube working.
- cozzyd 2y agoYou're seeing memory fragmentation which I would expect not to improve
- timschmidt 2y agoThat's an interesting take about a language that puts variables on the stack by default. The less you put in the heap, the less fragmented it gets. Heap fragmentation also does not account for the ever growing memory footprint of a running instance.
- cozzyd 2y agoYou're aware that C++ and C are also stack allocating by default? Unless you mean something different than what I understand.
- timschmidt 2y agoC requires malloc (and the heap) for anything that lives beyond the scope of the function lifetime. C++ adds smart pointers and copy/move semantics, but default behavior is still like C, and defaults matter.
- cozzyd 2y agoDoes rust really allow stack allocated objects to escape function lifetime? That seems antithetical to how a stack works.
- whytevuhuni 2y agoIt's the other way around; Rust is really good at tracking the lifetime of objects, and so Rust code is a lot more reckless with passing around pointers to stack-allocated objects through very long chains of functions, iterators, closures, etc, because it becomes obvious when a mistake was made (it becomes a compile error). This makes it so that things that appear dangerous in C++ are safe in Rust, so for example instead of defensively allocating std::string to store strings (because who knows what might happen with the original string), Rust can just keep using the equivalent of std::string_view until it becomes obvious that it's no longer possible.