4 ms·

> What?! You really think memory safety is binary? Not sure why you'd assume that. The languages you offered are only as memory safe as their runtimes, which

> What?! You really think memory safety is binary? Not sure why you'd assume that. The languages you offered are only as memory safe as their runtimes, which are usually implemented in something C flavored, and the compiler for same. Rust identifies memory unsafe areas instead with the unsafe tag. Functionally equivalent but I know which I like more. > It does though. It's more ergonomic and does adds safety over manual memory management. This is the misunderstanding. Rust manages to be wonderfully ergonomic without GC. The type system is really the only thing that makes it wordier than C++. And I've written large Rust applications with no manual memory management whatsoever. Occasionally I'll have to wrap something in an Arc Mutex because something needs to run in another thread. One or two variables in a whole application. Your complaints apply to other languages.

surgical_fire 2y ago
Thanks for proving my original point. I rest my case.
- timschmidt 2y ago
  OK, dude. If you never correct your misconception, you can be annoyed when people attempt to educate you forever X) No amount of complaining about Rust evangelists will change how they use the language, but you could learn to understand why they're using it the way they are.
hu3 2y ago
> This is the misunderstanding. Rust manages to be wonderfully ergonomic without GC. The type system is really the only thing that makes it wordier than C++ Thanks for the laugh. Maybe lifetimes/borrow checking syntax got invisible after a while to you. The only explanation. I'll stop here. Don't have the time nor desire to argue against what seems like passionate opinions.
- timschmidt 2y ago
  > Maybe lifetimes/borrow checking syntax got invisible after a while to you. I just did a quick scan, in a couple thousand lines of Rust I see two, maybe three lifetime annotations. Nah, not a huge contributor to language verbosity. Most Rust folk seem to work with the compiler's notion of what lifetimes should be, and everything's implicit.
- vlovich123 2y ago
  Lifetime syntax is only more visible if you try to write high performance code. If you wrap everything in Rc<RefCell> or Arc<Mutex> or Box you’ll not see it show up anywhere but you’ll probably still get a performance profile better than tracing GC because time and time again it’s been shown that reliable tail latencies and peak throughputs are generally harder to achieve with a tracing GC. Where lifetimes start to pop up more is in more complicated situations where you are trying to avoid memory allocations and have even higher performing code. And op is correct. In terms of memory safety, Java and C# aren’t as safe as you might hope because significant chunks of the runtime are still in C/C++ (not true for Go) and because of JIT miscompilation bugs (also not relevant for go). Of course JIT miscompilation in theory should be the same as a compiler miscompilation, but in practice it turns out to be worse because you have to maintain consistency between the interpreted and all the tiers of JIT at runtime and in practice humans have a hard time doing that which is why V8 constantly has security vulnerabilities in this area. That’s why GraalVM is interesting because it proposes a JIT design where you only have the compiler implemented once.
  - neonsunset 2y ago
    Go is not magically exempt from constraints other languages are subject to, no matter how much blind faith is put into this mantra. Java has different compiler implementations not all of which necessarily go through interpreter stage. .NET CoreCLR does not have one in the first place (there is technically interpreter code in the codebase but it has bitrotted and is unused). JIT or not does not make it inherently more prone to miscompilation bugs. One thing that Go has going for its compiler is it is a massively simpler design. The downside of that, of course, is much worse compiler output that cannot cope with complex code and is inadequate at high-performance scenarios, where the users of Go either have to try to work around this with goasm or might not even have a solution at all, short of rewriting the component in a different language and praying that the FFI call overhead is low enough for the workload in question. In addition to that, runtime implemented in C/C++ vs Java/C# or other language does not make it inherently safer. It is always a lower-level flavour of the language, where it cannot depend on itself, and with likely numerous relaxations in assurances to stay performant that the authors uphold manually. Even when C or C++ are used - it's usually a limited, focused subset of the language. And it is a bold claim that these runtimes are not extensively tested, fuzzed and otherwise verified against defects before going to production. If you look at bug and CVE history of .NET - pretty much all issues happen in complex "non-core" APIs, often at the unmanaged side provided by operating system rather than .NET itself (the cryptography bits). I can't recall any that are directly or indirectly related to a compiler bugs. I feel like this reply ignores the wider context, which is plain old web dev, where the use of Rust and the decision fatigue that it carries is likely to be misplaced. Just pick C# or Kotlin.
pjmlp 2y ago
Rust runtime is partially implemented in a C++ toolchain, should we use the same arguement then?
- timschmidt 2y ago
  Yes, Rust does depend on Clang for the lowest level of compilation at the moment. MIR (where the borrow checker lives and most of memory safety is implemented) and HLR are both implemented in Rust. What argument? Seems more like a misunderstanding to me.
  - pjmlp 2y ago
    Using your argument, Rust can't be fully trusted as long as its compilation model and runtime depends on having C++ somewhere. In fact, that has broken Rust compilation semantics quite a few times already.
    - timschmidt 2y ago
      I don't think I've made any contradictory argument. Perhaps someone else did? Or maybe you assumed a binary where I see gradients. I'm quite sure I didn't claim anywhere that any language was perfectly memory safe. With Rust and Cheri we are getting closer, but there is still progress to be made. I can say that Rust is well architected such that the borrow checker and most of memory safety is implemented in the midlevel intermediate representation, which is implemented using Rust, and the bits of Clang upon which MIR and HLR are built are both well tested by virtue of being used by multiple language frontends, and limited in scope and modularity. It'd be great to see an all-rust replacement though, as bugs in Clang have been found. I believe there are several projects in the works and existing pure-Rust bootstrap compilers sufficient to get the toolchain working.
germandiago 2y ago
> Rust manages to be wonderfully ergonomic without GC Hahahahaha! That's funny.
germandiago 2y ago
Rust, like absolutely any language, needs an unsafe base on which to implement safe abstractions.

surgical_fire 2y ago

Thanks for proving my original point. I rest my case.

timschmidt 2y ago
OK, dude. If you never correct your misconception, you can be annoyed when people attempt to educate you forever X) No amount of complaining about Rust evangelists will change how they use the language, but you could learn to understand why they're using it the way they are.

hu3 2y ago

> This is the misunderstanding. Rust manages to be wonderfully ergonomic without GC. The type system is really the only thing that makes it wordier than C++ Thanks for the laugh. Maybe lifetimes/borrow checking syntax got invisible after a while to you. The only explanation. I'll stop here. Don't have the time nor desire to argue against what seems like passionate opinions.

timschmidt 2y ago
> Maybe lifetimes/borrow checking syntax got invisible after a while to you. I just did a quick scan, in a couple thousand lines of Rust I see two, maybe three lifetime annotations. Nah, not a huge contributor to language verbosity. Most Rust folk seem to work with the compiler's notion of what lifetimes should be, and everything's implicit.
vlovich123 2y ago
Lifetime syntax is only more visible if you try to write high performance code. If you wrap everything in Rc<RefCell> or Arc<Mutex> or Box you’ll not see it show up anywhere but you’ll probably still get a performance profile better than tracing GC because time and time again it’s been shown that reliable tail latencies and peak throughputs are generally harder to achieve with a tracing GC. Where lifetimes start to pop up more is in more complicated situations where you are trying to avoid memory allocations and have even higher performing code. And op is correct. In terms of memory safety, Java and C# aren’t as safe as you might hope because significant chunks of the runtime are still in C/C++ (not true for Go) and because of JIT miscompilation bugs (also not relevant for go). Of course JIT miscompilation in theory should be the same as a compiler miscompilation, but in practice it turns out to be worse because you have to maintain consistency between the interpreted and all the tiers of JIT at runtime and in practice humans have a hard time doing that which is why V8 constantly has security vulnerabilities in this area. That’s why GraalVM is interesting because it proposes a JIT design where you only have the compiler implemented once.
- neonsunset 2y ago
  Go is not magically exempt from constraints other languages are subject to, no matter how much blind faith is put into this mantra. Java has different compiler implementations not all of which necessarily go through interpreter stage. .NET CoreCLR does not have one in the first place (there is technically interpreter code in the codebase but it has bitrotted and is unused). JIT or not does not make it inherently more prone to miscompilation bugs. One thing that Go has going for its compiler is it is a massively simpler design. The downside of that, of course, is much worse compiler output that cannot cope with complex code and is inadequate at high-performance scenarios, where the users of Go either have to try to work around this with goasm or might not even have a solution at all, short of rewriting the component in a different language and praying that the FFI call overhead is low enough for the workload in question. In addition to that, runtime implemented in C/C++ vs Java/C# or other language does not make it inherently safer. It is always a lower-level flavour of the language, where it cannot depend on itself, and with likely numerous relaxations in assurances to stay performant that the authors uphold manually. Even when C or C++ are used - it's usually a limited, focused subset of the language. And it is a bold claim that these runtimes are not extensively tested, fuzzed and otherwise verified against defects before going to production. If you look at bug and CVE history of .NET - pretty much all issues happen in complex "non-core" APIs, often at the unmanaged side provided by operating system rather than .NET itself (the cryptography bits). I can't recall any that are directly or indirectly related to a compiler bugs. I feel like this reply ignores the wider context, which is plain old web dev, where the use of Rust and the decision fatigue that it carries is likely to be misplaced. Just pick C# or Kotlin.

pjmlp 2y ago

Rust runtime is partially implemented in a C++ toolchain, should we use the same arguement then?

timschmidt 2y ago
Yes, Rust does depend on Clang for the lowest level of compilation at the moment. MIR (where the borrow checker lives and most of memory safety is implemented) and HLR are both implemented in Rust. What argument? Seems more like a misunderstanding to me.
- pjmlp 2y ago
  Using your argument, Rust can't be fully trusted as long as its compilation model and runtime depends on having C++ somewhere. In fact, that has broken Rust compilation semantics quite a few times already.
  - timschmidt 2y ago
    I don't think I've made any contradictory argument. Perhaps someone else did? Or maybe you assumed a binary where I see gradients. I'm quite sure I didn't claim anywhere that any language was perfectly memory safe. With Rust and Cheri we are getting closer, but there is still progress to be made. I can say that Rust is well architected such that the borrow checker and most of memory safety is implemented in the midlevel intermediate representation, which is implemented using Rust, and the bits of Clang upon which MIR and HLR are built are both well tested by virtue of being used by multiple language frontends, and limited in scope and modularity. It'd be great to see an all-rust replacement though, as bugs in Clang have been found. I believe there are several projects in the works and existing pure-Rust bootstrap compilers sufficient to get the toolchain working.

germandiago 2y ago

> Rust manages to be wonderfully ergonomic without GC Hahahahaha! That's funny.

germandiago 2y ago

Rust, like absolutely any language, needs an unsafe base on which to implement safe abstractions.