3 ms·

I would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak see

by 3a2d29 4y ago

I would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible. Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue? If you like Result<> or concurrency, use a GC language with those things. Go may not have them, but your choice isn't just Go.

mlindner 4y ago
If you're going to use Rust in web anything at all, the backend is the first place you'd think of. You can use Rust in the frontend but it's not exactly a smooth experience. Rust is a systems language.
satvikpendem 4y ago
Can doesn't mean will. I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.
- 3a2d29 4y ago
  What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue? "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust. GCs prevent memory leaks, which safe rust can do. So even if you somehow make sure no unsafe is ever used, you can still introduce a hard to debug issue just because you want to use rust.
  - satvikpendem 4y ago
    > "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention. There are no GC vs non-GC spaces. The point of Rust is to be able to have memory safety without a garbage collector, that's literally why it was made. Thus, it is expected based on that premise that we be able to use Rust wherever a GC could be used. The fact that unsafe exists does matter, as long as unsafe isn't used. I too can turn a GC language like Java into an unsafe monstrosity, by for example doing raw bytecode tinkering, does that mean that Java is now unsafe? No, unsafe is merely an escape hatch.
    - 3a2d29 4y ago
      Right but my main point is this: Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing. You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easier to hire devs (and train devs) for other GC languages cause not everyone knows or understands the borrow checker. Is there any advantage?
      - nicoburns 4y ago
        > It is easier to leak memory I'm not convinced about this at all. I've had far more issues with memory leaks in JavaScript programs than I have with Rust. The only way you're really likely to leak memory in Rust is creating cycles of Rc and Arc types. But I don't think any of my programs have even contained Rc, and only trivial usages of Arc for global resources, which I absolutely wouldn't want to point to each other. JavaScript will let you create the same problem without making it obvious with type signatures. And while you might be lucky and have the GC sort out your mess, it doesn't always manage to.
      - satvikpendem 4y ago
        I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for you, but they exist.
  - MrJohz 4y ago
    The difference is that it's fairly easy to prevent unsafe code from occurring: a "forbid(unsafe_code)" directive prevents unsafe code from even being accepted by the compiler. In C++ there is no equivalent - good linting can prevent some obvious errors, but a lot of valid code is inherently unsafe (in the Rust sense) if used incorrectly or under the wrong assumptions. It's also worth pointing out that most GC languages can have the same issues as a Rust program (if not more) just by virtue of having FFI. In Python, I can quite happily load a C extension and ignore all the rules. Whereas in Rust, if I want to use a C library, I still need to explicitly declare it as unsafe code. In practice, I tend to find that I have to think more about how I approach parallel/multi-threaded code in Rust than I do in other languages - not because it's dangerous, but because the compiler doesn't allow code that would break memory safety guarantees. In some ways, that's obviously a bad thing if I'm having to think more, but in my experience, the thoughts often lead to a better design anyway. So in the end, I'm more confident in my Rust code than I am in equivalent code in a GC language.
    - 3a2d29 4y ago
      Right but to my knowledge (and I could be wrong) that unsafe tag does to prevent it in the crates. Many memory safety violations have been discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ https://www.infoq.com/news/2021/11/rudra-rust-safety/ Maybe I wrong on that, but if it can’t guarantee crate safety, then it doesn’t really do anything.
      - MrJohz 4y ago
        That's true, but again, it's also true in most other languages that your dependencies can do anything they like, including shipping untrusted, compiled C code. The value of something like "unsafe" is not that your code is magically protected if it isn't there, but rather that it provides a warning sign as to where dangerous code might lie. So if something goes go wrong - or you're just worried something _might_ go wrong - you know roughly where to look. In the same way, if your Python code includes a C extension and you start getting weird segfaults, you can reasonably guess where to start looking. Except that, because unsafe is so well integrated in the language, you can often significantly reduce the impact of unsafe to only a few lines, and in most cases you won't need to use it at all.
- 3a2d29 4y ago
  > borrow checker ensures that I don't leak memory when not using unsafe Also to point out, you can 100% leak memory in safe rust
  - satvikpendem 4y ago
    Yes, you're right. However, it's much harder than in other languages, and the likelihood of doing so therefore is lower. I can also leak memory in GC languages too, just to note.
  - MrJohz 4y ago
    You can 100% leak memory in pretty much every language though: just use a bad caching/memoisation strategy, and you'll have memory leaks for days. Leaking memory isn't in of itself a problem, and it can be a very valid strategy for short-lived programs where you can rely on the OS to do the ultimate garbage collection run anyway. It's only a problem in the sense that uncontrolled memory acquisition will inevitably lead to the system running out of memory to acquire, but that's also true if you're accumulating memory for perfectly legitimate reasons.
UltraViolence 4y ago
The big win with Rust is that it's not only memory-safe but also thread-safe, which is hugely important in a web application. IMHO C# is also an excellent choice, but there's a lot going on behind the covers to keep it working properly in a multi-threaded web environment. This mostly doesn't concern you as a developer, until it bites you.

by 3a2d29 4y ago

mlindner 4y ago

If you're going to use Rust in web anything at all, the backend is the first place you'd think of. You can use Rust in the frontend but it's not exactly a smooth experience. Rust is a systems language.

satvikpendem 4y ago

Can doesn't mean will. I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

3a2d29 4y ago
What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue? "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust. GCs prevent memory leaks, which safe rust can do. So even if you somehow make sure no unsafe is ever used, you can still introduce a hard to debug issue just because you want to use rust.
- satvikpendem 4y ago
  > "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention. There are no GC vs non-GC spaces. The point of Rust is to be able to have memory safety without a garbage collector, that's literally why it was made. Thus, it is expected based on that premise that we be able to use Rust wherever a GC could be used. The fact that unsafe exists does matter, as long as unsafe isn't used. I too can turn a GC language like Java into an unsafe monstrosity, by for example doing raw bytecode tinkering, does that mean that Java is now unsafe? No, unsafe is merely an escape hatch.
  - 3a2d29 4y ago
    Right but my main point is this: Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing. You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easier to hire devs (and train devs) for other GC languages cause not everyone knows or understands the borrow checker. Is there any advantage?
    - nicoburns 4y ago
      > It is easier to leak memory I'm not convinced about this at all. I've had far more issues with memory leaks in JavaScript programs than I have with Rust. The only way you're really likely to leak memory in Rust is creating cycles of Rc and Arc types. But I don't think any of my programs have even contained Rc, and only trivial usages of Arc for global resources, which I absolutely wouldn't want to point to each other. JavaScript will let you create the same problem without making it obvious with type signatures. And while you might be lucky and have the GC sort out your mess, it doesn't always manage to.
    - satvikpendem 4y ago
      I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for you, but they exist.
- MrJohz 4y ago
  The difference is that it's fairly easy to prevent unsafe code from occurring: a "forbid(unsafe_code)" directive prevents unsafe code from even being accepted by the compiler. In C++ there is no equivalent - good linting can prevent some obvious errors, but a lot of valid code is inherently unsafe (in the Rust sense) if used incorrectly or under the wrong assumptions. It's also worth pointing out that most GC languages can have the same issues as a Rust program (if not more) just by virtue of having FFI. In Python, I can quite happily load a C extension and ignore all the rules. Whereas in Rust, if I want to use a C library, I still need to explicitly declare it as unsafe code. In practice, I tend to find that I have to think more about how I approach parallel/multi-threaded code in Rust than I do in other languages - not because it's dangerous, but because the compiler doesn't allow code that would break memory safety guarantees. In some ways, that's obviously a bad thing if I'm having to think more, but in my experience, the thoughts often lead to a better design anyway. So in the end, I'm more confident in my Rust code than I am in equivalent code in a GC language.
  - 3a2d29 4y ago
    Right but to my knowledge (and I could be wrong) that unsafe tag does to prevent it in the crates. Many memory safety violations have been discovered in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/ https://www.infoq.com/news/2021/11/rudra-rust-safety/ Maybe I wrong on that, but if it can’t guarantee crate safety, then it doesn’t really do anything.
    - MrJohz 4y ago
      That's true, but again, it's also true in most other languages that your dependencies can do anything they like, including shipping untrusted, compiled C code. The value of something like "unsafe" is not that your code is magically protected if it isn't there, but rather that it provides a warning sign as to where dangerous code might lie. So if something goes go wrong - or you're just worried something _might_ go wrong - you know roughly where to look. In the same way, if your Python code includes a C extension and you start getting weird segfaults, you can reasonably guess where to start looking. Except that, because unsafe is so well integrated in the language, you can often significantly reduce the impact of unsafe to only a few lines, and in most cases you won't need to use it at all.
3a2d29 4y ago
> borrow checker ensures that I don't leak memory when not using unsafe Also to point out, you can 100% leak memory in safe rust
- satvikpendem 4y ago
  Yes, you're right. However, it's much harder than in other languages, and the likelihood of doing so therefore is lower. I can also leak memory in GC languages too, just to note.
- MrJohz 4y ago
  You can 100% leak memory in pretty much every language though: just use a bad caching/memoisation strategy, and you'll have memory leaks for days. Leaking memory isn't in of itself a problem, and it can be a very valid strategy for short-lived programs where you can rely on the OS to do the ultimate garbage collection run anyway. It's only a problem in the sense that uncontrolled memory acquisition will inevitably lead to the system running out of memory to acquire, but that's also true if you're accumulating memory for perfectly legitimate reasons.

UltraViolence 4y ago

The big win with Rust is that it's not only memory-safe but also thread-safe, which is hugely important in a web application. IMHO C# is also an excellent choice, but there's a lot going on behind the covers to keep it working properly in a multi-threaded web environment. This mostly doesn't concern you as a developer, until it bites you.