Comment by ardy42 | Hacker News Reader

Comment by ardy42 | Hacker News Reader

Parent Full thread

> C++ offers direct, low-level control over memory, and C++ can be used to implement anything which can be implemented in Rust. Maybe Rust has certain advantages which made this problem a lot easier to solve for Mozilla, and I'm certainly happy to have Rust in the language landscape, but another team with other processes may have been able to use C++ to achieve similar goals.

You could say the same thing about assembly programming or some language that uses GOTOs instead of structured control constructs ... or Brainfuck. Given infinite time and resources, you can implement anything in any language.

Claims about this or that language being unsuitable for a problem aren't really about stuff like Turing completeness, it's more about practical software engineering problems (e.g. does the language provide the right kind of support to the developers allow them to implement the required functionality in a reasonable amount of time with a reasonably small amount of bugs with the budget available).

> You could say the same thing about assembly programming or some language that uses GOTOs instead of structured control constructs ... or Brainfuck.

I think this a reduction of the argument to the point of absurdity. C++ and Rust are certainly much more similar in terms of form and capability than C++ and brainfuck.

> Claims about this or that language being unsuitable for a problem aren't really about stuff like Turing completeness, it's more about practical software engineering problems (e.g. does the language provide the right kind of support to the developers allow them to implement the required functionality in a reasonable amount of time with a reasonably small amount of bugs with the budget available).

I agree. C++ may very well have been unsuitable for Mozilla at the time they adopted Rust. What I take issue with is the general claim that C++ is not suitable for a parallel CSS engine at all. This is a very strong claim, and I do not believe one team coming to this conclusion for them is enough evidence to conclude this in general.

> C++ and Rust are certainly much more similar in terms of form and capability than C++ and brainfuck.

From the point of view of somebody creating a highly interdependent parallel system, no, it's the other way around. On the features that matter to parallel systems, C++ is much closer to brainfuck than it's to Rust.

> I agree. C++ may very well have been unsuitable for Mozilla at the time they adopted Rust. What I take issue with is the general claim that C++ is not suitable for a parallel CSS engine at all. This is a very strong claim, and I do not believe one team coming to this conclusion for them is enough evidence to conclude this in general.

I know very little about rust, so take this with a grain of salt. It's possible that writing the CSS engine in C++ would require too many custom classes, containers, and build tools outside of the STL than equivalent code in Rust. For example, fast mutexes and mutex safety are not a standard part of C++ but vital to fast parallel C++ code, and the semantics of mutexes are thus very hard to get right. Static checkers for specific mutex implementations can decrease the risk of deadlocks and races but these are additions to C++. If rust provides primitive mutexes with static checking for correctness or other language features (maybe refcell or similar) then it might be worth using rust to stay within the standard language features instead of building add-ons for C++.

Reply on news.ycombinator.com