logoalt Hacker News

drnick1yesterday at 11:31 PM4 repliesview on HN

Not too surprising. Swift is too tied to Apple and it's not really clear what the benefit would be relative to a subset of C++ written with contemporary memory safety practices. It's a battle tested choice and pretty much every browser actually in use is written in C++.


Replies

jsheardyesterday at 11:40 PM

> It's a battle tested choice and pretty much every browser actually in use is written in C++.

Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.

IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.

show 3 replies
amlutoyesterday at 11:44 PM

> a subset of C++ written with contemporary memory safety practices

What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)

show 3 replies
abraxasyesterday at 11:49 PM

Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?

show 4 replies
ahartmetzyesterday at 11:37 PM

Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).

show 2 replies