4 ms·

It’s not as simple as “just” using a memory safe language. The languages that are memory safe either impose too much of a straightjacket to be productive (Rust

It’s not as simple as “just” using a memory safe language. The languages that are memory safe either impose too much of a straightjacket to be productive (Rust), don’t give you a GC or a memory safe way of writing one (Swift, Rust), or give you a GC with the wrong semantics (Java, Go, etc). Yes, the browser needs to have a GC. No, there’s no way around that. I’m not saying it can’t be done - but there are good reasons to stick with C++ to get this job done. Not an ideal situation but it’s where the world is at.

fabrice_d 2y ago
Both Firefox and Chromium are moving to Rust, incrementally. There are good reasons for that, like the fact that even their very good C++ developers are on board.
ethanol 2y ago
GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.
- pizlonator 2y ago
  It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
  - Dylan16807 2y ago
    A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
    - pizlonator 2y ago
      That's not what happens in the browser at all. The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references). The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics. So, maybe there is code out there where the GC can be an island. The browser is not that.
      - Dylan16807 2y ago
        Tight coupling is not a problem. Ignore the word "island" if that's your issue. Pretend it talked about sealing each unsafe system behind a safe API. And yes, you can make that happen. Marking references for a GC is in the same ballpark as a custom allocator. It doesn't have to fill the code using it with unsafe.
        pizlonator 2y ago
        There’s no way to seal the GC’s unsafety behind a safe API unless the safe code pins every GC object it touches. That’s not what happens in a browser engine - the GC has to ask the rest of the engine where its pointers are, and if any part of the browser fails to account for a pointer correctly, then you get use after free as soon as the GC runs. It’s a harder problem than you make it seem.
        Dylan16807 2y ago
        Doesn't Rc already demonstrate that kind of accounting? You're going to have to add GC awareness to objects so it can trace through them, but the code that makes and manipulates those objects can have all the necessary rules enforced by types.

fabrice_d 2y ago

Both Firefox and Chromium are moving to Rust, incrementally. There are good reasons for that, like the fact that even their very good C++ developers are on board.

ethanol 2y ago

GC is but one component of the massive operating system that is current web browsers. This is classic anti-Rust "argument" which states that code with tiny islands of well tested and thoroughly reviewed unsafe functions is somehow equal to 100% unsafe C++.

pizlonator 2y ago
It’s not an island. The whole rest of the browser has to interact with the GC the right way (barriers, pointer tracking) or else you escape memory safety
- Dylan16807 2y ago
  A ton of things using the GC code fits fine with what they meant by "island". You shouldn't need unsafe code all over, just normal ownership tracking that calls into the GC. And while I wouldn't normally call a GC "tiny", browsers are pretty enormous.
  - pizlonator 2y ago
    That's not what happens in the browser at all. The JS engine - about 1/3 of the browser engine, ish - is tightly coupled to the GC through-and-through. Let's even assume you have a JS engine that doesn't JIT. (If it did JIT then rewriting it in a memory safe language isn't going to do much for you at all.) The interpreter, the runtime, and the libraries are going to have to be making decisions on behalf of the GC (for stuff like weak maps, at least) and is going to have to play along with the GC's tracing (every class in the JS engine participates in the JS GC and so must tell the GC how to mark - or worse, move - outgoing references). The rest of the browser has to play along as well, just not as much. The DOM is basically JS's "standard library" within the browser and it also needs to have its objects play along with the GC's semantics. So, maybe there is code out there where the GC can be an island. The browser is not that.
    - Dylan16807 2y ago
      Tight coupling is not a problem. Ignore the word "island" if that's your issue. Pretend it talked about sealing each unsafe system behind a safe API. And yes, you can make that happen. Marking references for a GC is in the same ballpark as a custom allocator. It doesn't have to fill the code using it with unsafe.
      - pizlonator 2y ago
        There’s no way to seal the GC’s unsafety behind a safe API unless the safe code pins every GC object it touches. That’s not what happens in a browser engine - the GC has to ask the rest of the engine where its pointers are, and if any part of the browser fails to account for a pointer correctly, then you get use after free as soon as the GC runs. It’s a harder problem than you make it seem.
        Dylan16807 2y ago
        Doesn't Rc already demonstrate that kind of accounting? You're going to have to add GC awareness to objects so it can trace through them, but the code that makes and manipulates those objects can have all the necessary rules enforced by types.