11 ms·

I am very nervous about Rust. My team recently started on a Rust project because we had a need to build something that would compile to WebAssembly. Without ge

by skwirl 5y ago

I am very nervous about Rust. My team recently started on a Rust project because we had a need to build something that would compile to WebAssembly. Without getting into too much detail, the WebAssembly runtimes for memory managed languages wouldn't work for what we're doing. We are not a company that does a lot with C/C++ and those of us who have used C/C++ do not particularly enjoy it, so we decided to go with Rust. I do like Rust and it has worked well for this particular project. The problem, though, is that now there's a Rust mania that has set in and a desire to write/rewrite lots of stuff with Rust. Based on what I've seen out there on the web, this seems like a common thing. While Rust offered a clear benefit to us for the WebAssembly work, for every other case the benefits of Rust are mostly absent or minimal but the drawbacks around losing a garbage collector, losing a large healthy package ecosystem, losing use of our existing internal libraries and tooling, etc. loom large. So I am in an unhappy position where I keep telling enthusiastic Rust advocates no. Another interesting thing is that people tell their friends that we are using Rust and now they want to apply to work for us. We have a hard time recruiting and there's part of me that wonders if we'd just be flooded with applicants if we started advertising Rust jobs. This is somewhat tempting - we might be able to easily hire teams of enthusiasts to churn out Rust but for how long? How long will it have this magic aura and following? I certainly don't want to be left with tons of crappy Rust code in a few years that nobody wants to maintain. I feel like HN has mostly been very enthusiastic about Rust. A thread critical of Rust is rare and I feel like it is refreshing.

pingsl 5y ago
I have the same opinion. The best thing about rust is that rust attracts more people to learn systems programming languages. And thus, there will be more system programmers. Nowadays, young people favor application programming far more than system programming. But the problem is there are not that many system programming opportunities. Then they decided to rewrite the existing systems with rust. We can find a lot of these examples on GitHub. Who knows if it is just a moment of enthusiasm, and how long will it last?
- jmatthews 5y ago
  As someone who mostly enjoys cpp, for me the math just didn't seem worth it to really get fluent in rust. I agree there are less system jobs than app jobs kind of prima facie, but there's not exactly a lack of systems jobs for cpp programmers at the moment.
  - kinjba11 5y ago
    C and C++ are effectively immortal at this point. This is due to the fact that they've been king of the hill in systems for decades. Effectively the only choice for that domain. If you enjoy C++ more power to you. But there are those like myself who have experienced writing code in e.g. Python and Haskell and with those backgrounds find C and C++ especially unpalatable. This is part of why there's so much excitement for Rust - it has many of the features application programmers are used to (such as package management via Cargo) and is also proven capable of competing with C and C++. That's never happened before.
    - pjmlp 5y ago
      There is also another reason, domains where they are the only game in town, e.g. HPC, and any newcomer needs decades to get into the club. As for not happening before, Delphi and Turbo/Object Pascal on the PC and Mac worlds beg to differ, unfortunately C++ adoption from the OS owners pushed them away.
- nyanpasu64 5y ago
  My hopes is that Rust will result in more user-facing applications being written with the light weight, responsiveness, and performance of low-level-optimized code (no GC pauses, less allocation churn, easy safe parallelization, no segfaults unlike C++). Applications used to be written in C (and even RollerCoaster Tycoon in assembly), and GC'd languages are easier to develop in but slower to run on the user's computer. I'm not sure how successful Rust will be, since it discourages using multiple ownership or refcounting, and doesn't supply garbage collection, in situations where it is the easiest way to reason about code. IMO this raises the bar and discourages even working in these domains. (In my experience gtk-rs is more frustrating and confusing to use than unsafe Qt in C++.) And given Rust's tendency for dependency bloat, the applications don't come out as small on-disk as possible.
hojjat12000 5y ago
Wait, you're complaining that the people who used Rust to write a production software enjoyed it so much that they want that experience for all other softwares too? They enjoyed it so much that they told others? and others who also enjoy writing code in this language want to work for you? Are you saying you're afraid that "too much of a good thing" could cause issues for you?
- skwirl 5y ago
  I feel like I already articulated why I think Rust is not the best choice for most of what we do and you ignored it in order to write a snide response. Can we please keep HN from devolving into Twitter?
  - zozbot234 5y ago
    You didn't clarify what your existing stack/tooling is (other than it being based around a GC language), so it's kinda hard to give more detailed feedback. (In general, though, Rust tries its best to make GC-less development as productive as programming in ordinary GC languages, by generalizing the C++ 'RAII' pattern. Wrt. ecosystem concerns, Rust can interoperate with many existing languages though of course some will be harder than others, and interop with GC languages is quite challenging in general.)
    - trevyn 5y ago
      I’ve found Rust interaction with Go via `cgo` to be quite straightforward, fwiw. RPC approaches are also a popular option.
    - kaba0 5y ago
      > Rust tries its best to make GC-less development as productive as programming in ordinary GC languages I think it is generally impossible. While first draft version of the program may have similar velocity, later maintaining will necessarily hit those leaked lower level detail which is simply not a problem with managed languages. But I don’t think that this is a problem in any way or shape.
- 5y ago
nicoburns 5y ago
Rewrites seem like a bad idea (unless you’re hitting performance issues), but maybe you could consider letting people start some new projects in Rust? It’s a pretty good fit for backend web dev if you do any of that.
aidenn0 5y ago
Most of the "rewrite in rust" I've seen is for software that is in C/C++ so they aren't giving up a GC. That might just be the sorts of projects I follow though.
- nine_k 5y ago
  Yes, "let's rewrite it in Rust because we're tired of fixing buffer overruns, or memory leaks, or race conditions". This is very understandable, and mostly applies to systems software, slower-moving, high-reliability things.
  - otabdeveloper4 5y ago
    The vast, vast majority of buffer overruns, memory leaks and race conditions live in Javascript code. (An interpreted, garbage-collected language.) You don't understand what the memory safety promised by Rust actually does. (No, it won't save you from buffer overruns. Only from segfaults.)
    - nine_k 5y ago
      No, you can't get an RCE with an index being out of bounds in JS. You get a safe `undefined`, and a denial of service at best. With a buffer overrun in C, you can smash the stack or other interesting structures, and put executable code of your choice in it. If you have the right kind if container breach and privilege escalation exploit lying around for the target OS, you can pwn the entire infrastructure eventually. And no, I don't think you can memcpy / strcpy data[*i++] with abandon in Rust without first marking such code unsafe. To say nothing of concurrent modification which is another popular source of index overruns, and more.
      - otabdeveloper4 5y ago
        'undefined' is never safe in Javascript. As for the rest of your comment - good job on completely missing the point. When we talk about "buffer overflows", privilige escalation exploits are the least of our problems. https://hackernoon.com/null-the-billion-dollar-mistake-8t5z32d6 https://hackernoon.com/null-the-billion-dollar-mistake-8t5z3...
varjag 5y ago
This reads like satire.
drogus 5y ago
I'm curious, what are the types of other things that you do and which people want to rewrite to Rust? In general I'm very much against any rewrites without a clear list of things that are lacking in the current implementation, details on how the rewrite would address this and what are the functional requirements for the rewrite to succeed. But regarding new projects I think that people sometimes underestimate Rust in non systems programming scenarios. Not saying that you do, but at my job there is the notion that Rust is only good for "close to the metal" performance and where usually C/C++ would have been used. I think this is a flawed view. So while I am aware Rust is not the best choice for some stuff, if I had to write a web service and/or microservice that's not rendering anything I would often choose Rust just because of all the correctness guarantees. I come from a Ruby background, but I've done a lot of other languages too and a confidence I have when writing Rust is a big factor on why I like the language so much. I'm not really sure what percentage of Rust devs work with web services, but I think in the next few years it will be a big percentage of work done in Rust.

by skwirl 5y ago

pingsl 5y ago

I have the same opinion. The best thing about rust is that rust attracts more people to learn systems programming languages. And thus, there will be more system programmers. Nowadays, young people favor application programming far more than system programming. But the problem is there are not that many system programming opportunities. Then they decided to rewrite the existing systems with rust. We can find a lot of these examples on GitHub. Who knows if it is just a moment of enthusiasm, and how long will it last?

jmatthews 5y ago
As someone who mostly enjoys cpp, for me the math just didn't seem worth it to really get fluent in rust. I agree there are less system jobs than app jobs kind of prima facie, but there's not exactly a lack of systems jobs for cpp programmers at the moment.
- kinjba11 5y ago
  C and C++ are effectively immortal at this point. This is due to the fact that they've been king of the hill in systems for decades. Effectively the only choice for that domain. If you enjoy C++ more power to you. But there are those like myself who have experienced writing code in e.g. Python and Haskell and with those backgrounds find C and C++ especially unpalatable. This is part of why there's so much excitement for Rust - it has many of the features application programmers are used to (such as package management via Cargo) and is also proven capable of competing with C and C++. That's never happened before.
  - pjmlp 5y ago
    There is also another reason, domains where they are the only game in town, e.g. HPC, and any newcomer needs decades to get into the club. As for not happening before, Delphi and Turbo/Object Pascal on the PC and Mac worlds beg to differ, unfortunately C++ adoption from the OS owners pushed them away.
nyanpasu64 5y ago
My hopes is that Rust will result in more user-facing applications being written with the light weight, responsiveness, and performance of low-level-optimized code (no GC pauses, less allocation churn, easy safe parallelization, no segfaults unlike C++). Applications used to be written in C (and even RollerCoaster Tycoon in assembly), and GC'd languages are easier to develop in but slower to run on the user's computer. I'm not sure how successful Rust will be, since it discourages using multiple ownership or refcounting, and doesn't supply garbage collection, in situations where it is the easiest way to reason about code. IMO this raises the bar and discourages even working in these domains. (In my experience gtk-rs is more frustrating and confusing to use than unsafe Qt in C++.) And given Rust's tendency for dependency bloat, the applications don't come out as small on-disk as possible.

hojjat12000 5y ago

Wait, you're complaining that the people who used Rust to write a production software enjoyed it so much that they want that experience for all other softwares too? They enjoyed it so much that they told others? and others who also enjoy writing code in this language want to work for you? Are you saying you're afraid that "too much of a good thing" could cause issues for you?

skwirl 5y ago
I feel like I already articulated why I think Rust is not the best choice for most of what we do and you ignored it in order to write a snide response. Can we please keep HN from devolving into Twitter?
- zozbot234 5y ago
  You didn't clarify what your existing stack/tooling is (other than it being based around a GC language), so it's kinda hard to give more detailed feedback. (In general, though, Rust tries its best to make GC-less development as productive as programming in ordinary GC languages, by generalizing the C++ 'RAII' pattern. Wrt. ecosystem concerns, Rust can interoperate with many existing languages though of course some will be harder than others, and interop with GC languages is quite challenging in general.)
  - trevyn 5y ago
    I’ve found Rust interaction with Go via `cgo` to be quite straightforward, fwiw. RPC approaches are also a popular option.
  - kaba0 5y ago
    > Rust tries its best to make GC-less development as productive as programming in ordinary GC languages I think it is generally impossible. While first draft version of the program may have similar velocity, later maintaining will necessarily hit those leaked lower level detail which is simply not a problem with managed languages. But I don’t think that this is a problem in any way or shape.
5y ago

nicoburns 5y ago

Rewrites seem like a bad idea (unless you’re hitting performance issues), but maybe you could consider letting people start some new projects in Rust? It’s a pretty good fit for backend web dev if you do any of that.

aidenn0 5y ago

Most of the "rewrite in rust" I've seen is for software that is in C/C++ so they aren't giving up a GC. That might just be the sorts of projects I follow though.

nine_k 5y ago
Yes, "let's rewrite it in Rust because we're tired of fixing buffer overruns, or memory leaks, or race conditions". This is very understandable, and mostly applies to systems software, slower-moving, high-reliability things.
- otabdeveloper4 5y ago
  The vast, vast majority of buffer overruns, memory leaks and race conditions live in Javascript code. (An interpreted, garbage-collected language.) You don't understand what the memory safety promised by Rust actually does. (No, it won't save you from buffer overruns. Only from segfaults.)
  - nine_k 5y ago
    No, you can't get an RCE with an index being out of bounds in JS. You get a safe `undefined`, and a denial of service at best. With a buffer overrun in C, you can smash the stack or other interesting structures, and put executable code of your choice in it. If you have the right kind if container breach and privilege escalation exploit lying around for the target OS, you can pwn the entire infrastructure eventually. And no, I don't think you can memcpy / strcpy data[*i++] with abandon in Rust without first marking such code unsafe. To say nothing of concurrent modification which is another popular source of index overruns, and more.
    - otabdeveloper4 5y ago
      'undefined' is never safe in Javascript. As for the rest of your comment - good job on completely missing the point. When we talk about "buffer overflows", privilige escalation exploits are the least of our problems. https://hackernoon.com/null-the-billion-dollar-mistake-8t5z32d6 https://hackernoon.com/null-the-billion-dollar-mistake-8t5z3...

varjag 5y ago

This reads like satire.

drogus 5y ago

I'm curious, what are the types of other things that you do and which people want to rewrite to Rust? In general I'm very much against any rewrites without a clear list of things that are lacking in the current implementation, details on how the rewrite would address this and what are the functional requirements for the rewrite to succeed. But regarding new projects I think that people sometimes underestimate Rust in non systems programming scenarios. Not saying that you do, but at my job there is the notion that Rust is only good for "close to the metal" performance and where usually C/C++ would have been used. I think this is a flawed view. So while I am aware Rust is not the best choice for some stuff, if I had to write a web service and/or microservice that's not rendering anything I would often choose Rust just because of all the correctness guarantees. I come from a Ruby background, but I've done a lot of other languages too and a confidence I have when writing Rust is a big factor on why I like the language so much. I'm not really sure what percentage of Rust devs work with web services, but I think in the next few years it will be a big percentage of work done in Rust.