4 ms·

Memory safety is one of Rust’s biggest selling points. It’s a bit baffling that this engine would choose to implement unsafe garbage collection.

swiftcoder 11mo ago
The whole point of unsafe is to be able to circumvent the guardrails where the developer knows something the compiler isn't (yet) smart enough to understand. It's likely that implementing a high-performance GC runs afoul of quite a few of those edge cases.
scratcheee 11mo ago
The obvious use-case for unsafe is to implement alternative memory regimes that don’t exist in rust already, so you can write safe abstractions over them. Rust doesn’t have the kind of high performance garbage collection you’d want for this, so starting with unsafe makes perfect sense to me. Hopefully they keep the unsafe layer small to minimise mistakes, but it seems reasonable to me.
- amelius 11mo ago
  I'm curious if it can be done in Rust entirely though. Maybe some assembly instructions are required e.g. for trapping or setting memory fences.
  - nicoburns 11mo ago
    If it comes to it then Rust has excellent support for inline assembly
    - amelius 11mo ago
      But how well does it play with memory fences?
      - steveklabnik 11mo ago
        You don’t even need inline assembly for those https://doc.rust-lang.org/stable/std/sync/atomic/fn.fence.html https://doc.rust-lang.org/stable/std/sync/atomic/fn.fence.ht...
nicoburns 11mo ago
Even using something as simple as Vec means using `unsafe` code (from the std library). The idea isn't to have no `unsafe` code (which is impossible). It's to limit it to small sections of your code that are much more easily verifiable. For some use cases, that means that "user code" can have no `unsafe`. But implementing a GC is very much not one of those.
jeroenhd 11mo ago
Rust also has some nice language features. Even unsafe rust doesn't have the huge "undefined behaviour" surface that languages like C++ still contain. If I were to write a toy JS runtime in Rust, I'd try to make it as safe as possible and deal with unsafe only when optimization starts to become necessary, but it's not like that's the only way to use Rust.
- LtdJorge 11mo ago
  That’s the philosophy. Use the less constrained (but still somewhat constrained and borrow checked) unsafe to wrap/build the low level stuff, and expose a safe public API. That way you limit the exposure of human errors in unsafe code to a few key parts that can be well understood and tested.
the__alchemist 11mo ago
IMO the memory safety aspect is overblown by enthusiasts and purists. Rust is an overall nice fast imperative language.
- phplovesong 11mo ago
  Rust WAS really nice before it got mangled with syntax like we never seen before. Graydon did not imagine rust as what it is today. Rust core wo. async is ok, but in practice rust projects tend to have hundreds of deps and really slow compiles. Its just like javascript with npm.
  - swiftcoder 11mo ago
    > in practice rust projects tend to have hundreds of deps That's really just any language with a built-in package manager. Go somewhat sidesteps this by making you vendor your dependencies, but very few other languages escape the ballooning dependency graph.
    - phplovesong 11mo ago
      Go has probably more packages than Rust, but i rarely see Go projects that use as many as rust. In Go the usuals are depending on the app, possibly some db drivers, a simple router and maybe some crypto related thing. Most projects do fine with just the stdlib. In rust i tend to see 100 deps, and 1000 transient deps. Compile times are not in seconds, but minutes.
      - swiftcoder 11mo ago
        You can do that just fine in Rust too, for example the Makepad[1] developers take a pretty extreme non-invented-here stance, and builds a full UI toolkit with no external dependencies (and a major focus on clean-build compile times). However, it isn't really part of the Rust OSS culture to operate like that. The culture typically values safety over compile times, and prefers to lean on a deep stable of battle-hardened abstractions. [1]: https://makepad.nl https://makepad.nl, https://github.com/makepad/makepad https://github.com/makepad/makepad

swiftcoder 11mo ago

The whole point of unsafe is to be able to circumvent the guardrails where the developer knows something the compiler isn't (yet) smart enough to understand. It's likely that implementing a high-performance GC runs afoul of quite a few of those edge cases.

scratcheee 11mo ago

The obvious use-case for unsafe is to implement alternative memory regimes that don’t exist in rust already, so you can write safe abstractions over them. Rust doesn’t have the kind of high performance garbage collection you’d want for this, so starting with unsafe makes perfect sense to me. Hopefully they keep the unsafe layer small to minimise mistakes, but it seems reasonable to me.

amelius 11mo ago
I'm curious if it can be done in Rust entirely though. Maybe some assembly instructions are required e.g. for trapping or setting memory fences.
- nicoburns 11mo ago
  If it comes to it then Rust has excellent support for inline assembly
  - amelius 11mo ago
    But how well does it play with memory fences?
    - steveklabnik 11mo ago
      You don’t even need inline assembly for those https://doc.rust-lang.org/stable/std/sync/atomic/fn.fence.html https://doc.rust-lang.org/stable/std/sync/atomic/fn.fence.ht...

nicoburns 11mo ago

Even using something as simple as Vec means using `unsafe` code (from the std library). The idea isn't to have no `unsafe` code (which is impossible). It's to limit it to small sections of your code that are much more easily verifiable. For some use cases, that means that "user code" can have no `unsafe`. But implementing a GC is very much not one of those.

jeroenhd 11mo ago

Rust also has some nice language features. Even unsafe rust doesn't have the huge "undefined behaviour" surface that languages like C++ still contain. If I were to write a toy JS runtime in Rust, I'd try to make it as safe as possible and deal with unsafe only when optimization starts to become necessary, but it's not like that's the only way to use Rust.

LtdJorge 11mo ago
That’s the philosophy. Use the less constrained (but still somewhat constrained and borrow checked) unsafe to wrap/build the low level stuff, and expose a safe public API. That way you limit the exposure of human errors in unsafe code to a few key parts that can be well understood and tested.

the__alchemist 11mo ago

IMO the memory safety aspect is overblown by enthusiasts and purists. Rust is an overall nice fast imperative language.

phplovesong 11mo ago
Rust WAS really nice before it got mangled with syntax like we never seen before. Graydon did not imagine rust as what it is today. Rust core wo. async is ok, but in practice rust projects tend to have hundreds of deps and really slow compiles. Its just like javascript with npm.
- swiftcoder 11mo ago
  > in practice rust projects tend to have hundreds of deps That's really just any language with a built-in package manager. Go somewhat sidesteps this by making you vendor your dependencies, but very few other languages escape the ballooning dependency graph.
  - phplovesong 11mo ago
    Go has probably more packages than Rust, but i rarely see Go projects that use as many as rust. In Go the usuals are depending on the app, possibly some db drivers, a simple router and maybe some crypto related thing. Most projects do fine with just the stdlib. In rust i tend to see 100 deps, and 1000 transient deps. Compile times are not in seconds, but minutes.
    - swiftcoder 11mo ago
      You can do that just fine in Rust too, for example the Makepad[1] developers take a pretty extreme non-invented-here stance, and builds a full UI toolkit with no external dependencies (and a major focus on clean-build compile times). However, it isn't really part of the Rust OSS culture to operate like that. The culture typically values safety over compile times, and prefers to lean on a deep stable of battle-hardened abstractions. [1]: https://makepad.nl https://makepad.nl, https://github.com/makepad/makepad https://github.com/makepad/makepad