Hacker News new | past | comments | ask | show | jobs | submit login

Yeah and Webrender, Stylo, and Servo just happen to appear out of thin air.



Webrender and Stylo were big projects, but they’re already in tree, and that means about 10% of Firefox is Rust. That’s hardly “full Rust,” and even less so “at all cost.” You would have to show intent to actually re-write all of Firefox, you’d have to somehow deal with the fact that the number of engineers writing more C++ and continuing to do so is far greater than those writing Rust... there’s a ton of evidence that “full Rust at all cost” is not intended, desired, or being worked on.

It sounds like you’re objecting to any Rust being included at all, if I’m being honest.

EDIT: Like, for example, this article is about committing engineering time to help improve their C++. If the goal was 100% Rust at all costs, that would be a waste. Even this article is an indication that this thesis is incorrect.


Firefox has something like 8 million lines of C++. Stylo replaced about 150,000 lines of that, and WebRender is more of a fast path than a true replacement of anything.

Both of those rewrites came with massive speedups due to the amount of parallelism they were able to use, which was impractical in C++. Other parts of Firefox are not as critical or parallelizable, hence why they aren't being replaced any time soon.

You seem to be quite aggressively misinformed, if you are not deliberately trolling.


> the amount of parallelism they were able to use, which was impractical in C++

You mean after not using OpenMP, basic multithreading core guidelines, and not doing the refactoring with sanity checkup in TLA+, tools that end up on the frontpage everytime people rediscover them.


Do you believe that "just applying TLA+ to the rendering code in Firefox" is a useful thing to recommend to people? TLA+ cannot scale to that size of a codebase without such dramatic simplifications that it's not going to catch any of these kinds of bugs. This is the entire reason why proving safe encapsulation of `unsafe` blocks is possible was so important, it lets you focus the proof engineering effort on a much tinier part of the program. Sure, it can't prove the kind of global invariants TLA+ aims for, but you can also actually apply it to a very large codebase like Firefox (and keep it in sync--another problem you need to deal with when using tools like TLA+).


Out of curiosity, have you used OpenMP or TLA+? I seem to remember that solve problems that are really, really different from the use cases for which Rust is designed.


Also, I'll throw out there that TLA+ is nearly as handy for Rust as it is for C++. Safe Rust will keep you from data races that break it's safety guarantees, but there's more to correct use of concurrent algorithms than that. TLA+ is a great tool for modelling those other concerns if you need to apply a little more engineering rigor to some of those problems.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: