3 ms·

> Part of the magic of learning Rust is realizing that it's a fast compiled language that one doesn't fear to apply to services connected to the open internet.

by hu3 2y ago

> Part of the magic of learning Rust is realizing that it's a fast compiled language that one doesn't fear to apply to services connected to the open internet. This is so unusual, it may be unique. Is that sarcasm? If not, thanks for proving my point. From the top of my head, Go/.NET/Java are fast and safe choices. Also safe in the sense that you won't have a hard time hiring devs that are productive from the get go.

timschmidt 2y ago
> often preach replacing GC'd languages with rust in cases where it is not the best fit (mundane web dev for example). > proving my point. Was your point misunderstanding that garbage collection != memory safety? Having garbage collection doesn't make a language any better for web dev. Being memory safe does. If you do not understand the difference and needlessly associate the two, you are validating the work put in by the evangelists.
- hu3 2y ago
  > Was your point misunderstanding that garbage collection != memory safety? What?! You really think memory safety is binary? > Having garbage collection doesn't make a language any better for web dev. It does though. It's more ergonomic than fighting rust compiler and does add safety over manual memory management from the likes of C/C++. I just want to thank you for demonstrating so clearly how rust evangelists think.
  - timschmidt 2y ago
    > 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.

by hu3 2y ago

timschmidt 2y ago

> often preach replacing GC'd languages with rust in cases where it is not the best fit (mundane web dev for example). > proving my point. Was your point misunderstanding that garbage collection != memory safety? Having garbage collection doesn't make a language any better for web dev. Being memory safe does. If you do not understand the difference and needlessly associate the two, you are validating the work put in by the evangelists.

hu3 2y ago
> Was your point misunderstanding that garbage collection != memory safety? What?! You really think memory safety is binary? > Having garbage collection doesn't make a language any better for web dev. It does though. It's more ergonomic than fighting rust compiler and does add safety over manual memory management from the likes of C/C++. I just want to thank you for demonstrating so clearly how rust evangelists think.
- timschmidt 2y ago
  > 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.