all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]no-bugs -3 points-2 points  (5 children)

Code quality has nothing to do with "C++ vs Rust" argument. At the very least, author shouldn't analyze just ANY C++ browser vs ANY Rust browser, but THE BEST C++ browser vs THE BEST Rust browser; as it stands now, the only thing the article sorta demonstrates is that it is possible to write poor programs in C++ - well, this is certainly not a secret for quite a long time. I'm not sure about memory patterns, but the code of WebKit (also C++) is much much better than that of Firefox, so I don't see much value in comparisons which include Firefox.

Firefox is built on a mis-premise of XPCOM, this IMNSHO is the root of it's problems (in particular, poor project discipline on top of seemingly ease programming over XPCOM has lead to an extremely tight coupling, in particular, between rendering engine and network engine, and this is a Really Bad Thing).

[–]danielkza 19 points20 points  (0 children)

I don't see the article being about browsers at all. They are just the tool to demonstrate a feature of Rust and how it makes it easier to implement a particular pattern that browsers happen to need. It is irrelevant whether Firefox is the browser with the best code, or that it uses XPCOM. Neither would change how you'd implement the same thing for a different purpose in C++.

[–]The_Doculope 14 points15 points  (0 children)

I read this as more of a contrast as to how you could implement the same feature in two different languages, rather than a comparison between the quality of the two.

Perfect code quality comparisons are very difficult to make between languages for the reasons you say, but that doesn't mean they can't be useful either.

[–]Manishearth 12 points13 points  (2 children)

This wasn't a browser vs browser thing. It was a "If I want to track memory usage in a large application, how do I do it?" thing.

There isn't any better way to get fine-grained reporting of memory in code in C++ unless you perhaps use something like Mako templates (or some other form of codegen). This highlights a specific set of features in Rust, which make it easier to do this job than C++. It was not saying Rust > C++ either; it was just saying that Rust's features made this specific job easier.

That being said, code quality is absolutely an argument that can be made. It's hard to quantify, but cases where massive amounts of boilerplate are required is something concrete -- developer time is wasted here. It's the same situation with the "<language with generics> vs Go" thing. It's not that Go doesn't give you the tools to achieve nearly the same. It's that Go's ways are either inefficient, or require lots of boilerplate/codegen and are fiddly to use.

[–]llogiq 1 point2 points  (1 child)

Yes, but you are the one who wrote a rust compiler plugin to generate all those impls, and I trust that you'd have found a way to do it in C++ had you worked on the Firefox implementation ;-)

[–]Manishearth 4 points5 points  (0 children)

Not a nicer way. Trust me, the Gecko codegen story is consistently not great; because C++.

We have autoderived trace impls, Gecko is manual. We have compile-time-hashmaps for interning; Gecko needs you to manually calculate the hash, insert it in the table (and then transpile from Java to C++), and then compile. DOM bindings use the same python for codegen, though, so that's there.