15 ms·

I'm personally interested in Rust for a couple reasons. As an SRE/SysAdmin I struggle to believe that C or C++ can be written safely. It is very common that I

I'm personally interested in Rust for a couple reasons. As an SRE/SysAdmin I struggle to believe that C or C++ can be written safely. It is very common that I see software being emergency patched because of memory unsafety from very experienced engineers in ubiquitous software. Why would I need the performance/efficiency of C in the first place? Well, I regularly write software that runs on thousands to tens of thousands of machines in production. This software runs below the service. I feel a certain sense of pride in minimizing my observer effect on the system. With Rust, compared to Python, I can write software that has more functionality with a fraction of the memory and CPU utilization. Another thing that has become more appealing to me is the strong static type system. Not having a formal background in CS I fell in love with Python for how it enabled me to move quickly, and Python is still my go-to language for most things, but after years of supporting large production sites plus running my own code in production I'm a bit tired of runtime exceptions. We have great exception logging and there are entire classes of bugs we'd just never see with Rust's type system and error handling. Essentially, Rust gives me new super powers and the borrow checker is my sidekick making sure I don't shoot myself in the foot.

MichaelGG 11y ago
But this whole time, if efficiency was your aim, why not use, say OCaml? But good viewpoint: Rust is actually friendly enough that it is viable for the kind of things you mention.
- gmjosack 11y ago
  Another thing is the lack of runtime is really compelling. I can continue to write Python and can drop into Rust for hot code. Right now this is through C which does get me a bit of unsafety but it's much smaller scope. As Rust becomes more mature I'm looking forward to the ABI stabilizing so other languages can build ffi interfaces against it directly. I'll admit that OCaml is something that I've looked at before but it didn't have the staying power for me. It's likely just because it was too different at the time compared to what I was used to.
something123 11y ago
We should be seeing completely safe C++ code soon. Take a look at Herb Sutter's CppCon talk this year: https://www.youtube.com/watch?v=hEx5DNLWGgA https://www.youtube.com/watch?v=hEx5DNLWGgA Reinventing the wheel isn't entirely necessary. Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;)
- gmjosack 11y ago
  I'd already looked through the slides for that talk but I'll check out the video. Thanks! I think C++ has a lot of awesome stuff coming out but I find Rust more pleasant to code in. Also having package/dependency management has been great compared to using the old versions of libraries that come with distros or tracking down all the transitive dependencies of software. Rust is just a more delightful experience out of the box. > Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;) I definitely understand this but I don't think it's true and will be less and less true over time. It is becoming very common in the SRE/SysAdmin industry that strong coding skills is a requirement. When I started 10 years ago that was very different but it's becoming harder and harder to find jobs as a Linux grunt. The SREs I work with care about software engineering best practices, code review, testing, continuous integration, etc. Also, even if that were true, I'd much rather have people with a weaker understanding contribute to Rust where the compiler has your back. If you haven't used Rust you might be surprised how good the error messages are. Once you spend a bit of time understanding the basics the compiler is super helpful.
- MichaelGG 11y ago
  Once C++ allows people to flip a switch to produce guaranteed memory safe code, then it can start really comparing itself on that metric. (This would be fantastic. Think of the resources that'd be spent on such research! It'd be world-changing.) But even then, the inherent differences in a statement oriented vs expression oriented is likely to keep C++ being needlessly verbose. And I object to using Rust (or other production-level but "edge" languages) as being "job security". If the underlying software matters enough that using Rust has significant benefits, then it matters enough that employees spend a few days learning a bit of Rust. This fear of languages as if learning a language was this huge mountain to scale in hiring is just silly. The actual code and environment probably outweighs the language used significantly. The real exception to this is if you're running a codebase that has essentially non-programmers adding bits here and there. Somewhere where you know that the individual contributors will find learning a language to be a higher barrier than contributing new pieces of code. (So either a rather trivial system, or contributors that have an unusually low capacity.)
emn13 11y ago
C++11 aims to make those problems much less severe - but most software with such emergy patches probably started out long before then. As to how much the newer features help, time will tell...
technion 11y ago
> I struggle to believe that C or C++ can be written safely There's plenty of evidence it can, for certain values of "program". redis comes to mind as a product with a specific goal and implementation, and well managed design process that makes that happen. The problem is when projects grow to have dozens of developers, of varying skill, pumping in features in a continual battle to stay up to date with standards - like a web browser. Then, I think the possibility of secure C is shown to approach 0.
lmm 11y ago
This is exactly the scenario I found so confusing, and why I wrote this. I can understand not wanting to use F# or Scala for sysadmin work, but OCaml or Haskell would give you the safely and 95% of the performance (i.e. much better than Python) without the need for manual memory management. Did you consider either of those? Were your reasons for preferring Rust similar to what I put in the article?
- gmjosack 11y ago
  I answered a similar question to a sibling comment but I think it boils down to, I didn't come to Rust for functional features but I definitely enjoy them. The languages you mention in the post have a much higher learning curve coming out of Python. I spent a few tries "learning" Haskell and I really didn't enjoy it. In general when I've looked at Scala/Haskell/F# they use so many multi-char operators that it starts to look like line noise. OCaml always felt a bit too niche for me too I think, though that may be bias of the industry I'm in.
  - MichaelGG 11y ago
    It's important to note that F# doesn't really have many operators at all. The one most people see, |> which "pipes" an argument, is defined in an F# library, not in the compiler or part of the core language. You can define it yourself to be anything you like, or not use it at all. The language is unaware of it and treats it like anything else. The definition is just: let (|>) x f = f x That's literally function application, in reverse. That's all. It comes in handy for type inference and to make things look nice, but isn't special in any way. I mention this as one comment as to why Rust doesn't have such an operator was that "Rust uses channels for data flow" which is a non-sequiter. Rust just doesn't value conciseness as much, and I'm guessing the safety/perf restrictions might complicate matters. In fact, even the + and - operators are implemented in F# and shouldn't count as part of the language (just very commonly used bits of the stdlib). I fear that perhaps not enough intros to F# focus on the relatively simple underlying language, and that everything else on top is just an application of said language. With the type system, it's actually easy to figure out the operators, based on the type alone. Looking at |> for instance, we see a type of: 'a -> ('a -> 'b) -> 'b This makes it entirely obvious. There's only one implementation for such a type definition. This holds true for so much of the stdlib that the "noise" quickly fades away. This is relevant as magic cannot hide, and misuse will quickly be identified by the compiler. But it's a valuable comment as it illustrates that the simplicity is not being marketed correctly and turning away potential users.
kybernetyk 11y ago
> I struggle to believe that C or C++ can be written safely It can. You just need to avoid those performance optimizations that were en vogue in the 90s/early00s. Luckily modern computers (and the more modern C++ standards) can handle value semantics just fine and you don't need to put pointers into vectors anymore because directly putting the data there would be too costly, etc. If you only use the new (C++11 up) smart pointers (avoiding new/delete) you've essentially achieved 80% of Rust's safety model. Add rigorous application of const correctness and you're good to go. Rust still adds a few important things but until its eco system is matured (and there is real tooling) modern C++ is a pretty good alternative.
- seanwilson 11y ago
  As an analogy, you can write safe code in assembler as well if you and your team are incredibly disciplined and only interact with libraries written with a similar amount of discipline. The appeal of alternatives is you can write safe code with a fraction of the discipline and mental effort required.
  - claudius 11y ago
    There is no extra “discipline“ or “mental effort” required to write safe C++. Don’t use new/delete/free/malloc and don’t use operator&. Of course, you can say that we might as well remove them from the language entirely, but I really don’t think it takes extra effort not to use them.
    - keyneus 11y ago
      C++14: auto p = std::make_unique<int>(5); auto q = std::move(p); std::cout << *p << std::endl; Segfault using the “safe” C++ features. I'm a fan of modern C++, but it's not safe (in a Rust sense) even if you stick to C++11/C++14 features.
      - steveklabnik 11y ago
        For comparison, the same thing in Rust: fn main() { let p = Box::new(5); let q = p; println!("{}", p); } gives, upon compiling: error: use of moved value: `p` [E0382] println!("{}", p); ^ note: in this expansion of format_args! note: in this expansion of print! (defined in <std macros>) note: in this expansion of println! (defined in <std macros>) help: run `rustc --explain E0382` to see a detailed explanation note: `p` moved here because it has type `Box<i32>`, which is moved by default let q = p; ^ help: if you would like to borrow the value instead, use a `ref` binding as shown: let ref q = p; error: aborting due to previous error Running `rustc --explain E0382` or going to https://doc.rust-lang.org/nightly/error-index.html#E0382 https://doc.rust-lang.org/nightly/error-index.html#E0382 gives you an extended error message as well.
claudius 11y ago
> As an SRE/SysAdmin I struggle to believe that C or C++ can be written safely. It doesn’t make sense to talk about C and C++ together like that and the idea that it would possibly maybe make sense to talk about two fairly different languages the same way is very much the root cause why some people consider it impossible to write “safe” C++. C and C++ probably have as much in common as C and Rust (both of these have pointers, so they must be the same) or as Haskell and Java (both of these have types/classes, so they must be the same).
- gmjosack 11y ago
  I knew I was going to get this comment when I wrote this... I only mention those two together as the previous options for low level, no runtime languages. Outside of Rust both C and C++ were independent options I've considered investing more deeply in.
- topspin 11y ago
  It does make sense to talk about C and C++ together like this. The fact is that writing high performance systems software means using systems interfaces, and until there is a portable interface that doesn't imply the use of malloc, pointers, etc., you can't escape the C legacy of C++ and the inherently unsafe product of it. Wherever you look in the C/C++ world you find this legacy (POSIX, OpenGL, OpenMAX, OpenMP, OpenCL, on and on) so no matter how determined you are to try to match Rust with `safe' C++ you get dragged back into C. The term "C/C++" is used and understood because it is 100% appropriate, and it will continue to be appropriate as long as unsafe C/C++ interfaces proliferate. Obviously Rust can't completely solve this problem either, but Rust at least provides a mechanism to isolate the C legacy parts behind tested and supposedly `safe' API interfaces, leaving the developer exclusively within his type+memory+data race safe environment. That is a superior model.

MichaelGG 11y ago

But this whole time, if efficiency was your aim, why not use, say OCaml? But good viewpoint: Rust is actually friendly enough that it is viable for the kind of things you mention.

gmjosack 11y ago
Another thing is the lack of runtime is really compelling. I can continue to write Python and can drop into Rust for hot code. Right now this is through C which does get me a bit of unsafety but it's much smaller scope. As Rust becomes more mature I'm looking forward to the ABI stabilizing so other languages can build ffi interfaces against it directly. I'll admit that OCaml is something that I've looked at before but it didn't have the staying power for me. It's likely just because it was too different at the time compared to what I was used to.

something123 11y ago

We should be seeing completely safe C++ code soon. Take a look at Herb Sutter's CppCon talk this year: https://www.youtube.com/watch?v=hEx5DNLWGgA https://www.youtube.com/watch?v=hEx5DNLWGgA Reinventing the wheel isn't entirely necessary. Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;)

gmjosack 11y ago
I'd already looked through the slides for that talk but I'll check out the video. Thanks! I think C++ has a lot of awesome stuff coming out but I find Rust more pleasant to code in. Also having package/dependency management has been great compared to using the old versions of libraries that come with distros or tracking down all the transitive dependencies of software. Rust is just a more delightful experience out of the box. > Though if you're a SysAdmin and you write your codebase in Rust.. that's some nice job security. ;) I definitely understand this but I don't think it's true and will be less and less true over time. It is becoming very common in the SRE/SysAdmin industry that strong coding skills is a requirement. When I started 10 years ago that was very different but it's becoming harder and harder to find jobs as a Linux grunt. The SREs I work with care about software engineering best practices, code review, testing, continuous integration, etc. Also, even if that were true, I'd much rather have people with a weaker understanding contribute to Rust where the compiler has your back. If you haven't used Rust you might be surprised how good the error messages are. Once you spend a bit of time understanding the basics the compiler is super helpful.
MichaelGG 11y ago
Once C++ allows people to flip a switch to produce guaranteed memory safe code, then it can start really comparing itself on that metric. (This would be fantastic. Think of the resources that'd be spent on such research! It'd be world-changing.) But even then, the inherent differences in a statement oriented vs expression oriented is likely to keep C++ being needlessly verbose. And I object to using Rust (or other production-level but "edge" languages) as being "job security". If the underlying software matters enough that using Rust has significant benefits, then it matters enough that employees spend a few days learning a bit of Rust. This fear of languages as if learning a language was this huge mountain to scale in hiring is just silly. The actual code and environment probably outweighs the language used significantly. The real exception to this is if you're running a codebase that has essentially non-programmers adding bits here and there. Somewhere where you know that the individual contributors will find learning a language to be a higher barrier than contributing new pieces of code. (So either a rather trivial system, or contributors that have an unusually low capacity.)

emn13 11y ago

C++11 aims to make those problems much less severe - but most software with such emergy patches probably started out long before then. As to how much the newer features help, time will tell...

technion 11y ago

> I struggle to believe that C or C++ can be written safely There's plenty of evidence it can, for certain values of "program". redis comes to mind as a product with a specific goal and implementation, and well managed design process that makes that happen. The problem is when projects grow to have dozens of developers, of varying skill, pumping in features in a continual battle to stay up to date with standards - like a web browser. Then, I think the possibility of secure C is shown to approach 0.

lmm 11y ago

This is exactly the scenario I found so confusing, and why I wrote this. I can understand not wanting to use F# or Scala for sysadmin work, but OCaml or Haskell would give you the safely and 95% of the performance (i.e. much better than Python) without the need for manual memory management. Did you consider either of those? Were your reasons for preferring Rust similar to what I put in the article?

gmjosack 11y ago
I answered a similar question to a sibling comment but I think it boils down to, I didn't come to Rust for functional features but I definitely enjoy them. The languages you mention in the post have a much higher learning curve coming out of Python. I spent a few tries "learning" Haskell and I really didn't enjoy it. In general when I've looked at Scala/Haskell/F# they use so many multi-char operators that it starts to look like line noise. OCaml always felt a bit too niche for me too I think, though that may be bias of the industry I'm in.
- MichaelGG 11y ago
  It's important to note that F# doesn't really have many operators at all. The one most people see, |> which "pipes" an argument, is defined in an F# library, not in the compiler or part of the core language. You can define it yourself to be anything you like, or not use it at all. The language is unaware of it and treats it like anything else. The definition is just: let (|>) x f = f x That's literally function application, in reverse. That's all. It comes in handy for type inference and to make things look nice, but isn't special in any way. I mention this as one comment as to why Rust doesn't have such an operator was that "Rust uses channels for data flow" which is a non-sequiter. Rust just doesn't value conciseness as much, and I'm guessing the safety/perf restrictions might complicate matters. In fact, even the + and - operators are implemented in F# and shouldn't count as part of the language (just very commonly used bits of the stdlib). I fear that perhaps not enough intros to F# focus on the relatively simple underlying language, and that everything else on top is just an application of said language. With the type system, it's actually easy to figure out the operators, based on the type alone. Looking at |> for instance, we see a type of: 'a -> ('a -> 'b) -> 'b This makes it entirely obvious. There's only one implementation for such a type definition. This holds true for so much of the stdlib that the "noise" quickly fades away. This is relevant as magic cannot hide, and misuse will quickly be identified by the compiler. But it's a valuable comment as it illustrates that the simplicity is not being marketed correctly and turning away potential users.

kybernetyk 11y ago

> I struggle to believe that C or C++ can be written safely It can. You just need to avoid those performance optimizations that were en vogue in the 90s/early00s. Luckily modern computers (and the more modern C++ standards) can handle value semantics just fine and you don't need to put pointers into vectors anymore because directly putting the data there would be too costly, etc. If you only use the new (C++11 up) smart pointers (avoiding new/delete) you've essentially achieved 80% of Rust's safety model. Add rigorous application of const correctness and you're good to go. Rust still adds a few important things but until its eco system is matured (and there is real tooling) modern C++ is a pretty good alternative.

seanwilson 11y ago
As an analogy, you can write safe code in assembler as well if you and your team are incredibly disciplined and only interact with libraries written with a similar amount of discipline. The appeal of alternatives is you can write safe code with a fraction of the discipline and mental effort required.
- claudius 11y ago
  There is no extra “discipline“ or “mental effort” required to write safe C++. Don’t use new/delete/free/malloc and don’t use operator&. Of course, you can say that we might as well remove them from the language entirely, but I really don’t think it takes extra effort not to use them.
  - keyneus 11y ago
    C++14: auto p = std::make_unique<int>(5); auto q = std::move(p); std::cout << *p << std::endl; Segfault using the “safe” C++ features. I'm a fan of modern C++, but it's not safe (in a Rust sense) even if you stick to C++11/C++14 features.
    - steveklabnik 11y ago
      For comparison, the same thing in Rust: fn main() { let p = Box::new(5); let q = p; println!("{}", p); } gives, upon compiling: error: use of moved value: `p` [E0382] println!("{}", p); ^ note: in this expansion of format_args! note: in this expansion of print! (defined in <std macros>) note: in this expansion of println! (defined in <std macros>) help: run `rustc --explain E0382` to see a detailed explanation note: `p` moved here because it has type `Box<i32>`, which is moved by default let q = p; ^ help: if you would like to borrow the value instead, use a `ref` binding as shown: let ref q = p; error: aborting due to previous error Running `rustc --explain E0382` or going to https://doc.rust-lang.org/nightly/error-index.html#E0382 https://doc.rust-lang.org/nightly/error-index.html#E0382 gives you an extended error message as well.

claudius 11y ago

> As an SRE/SysAdmin I struggle to believe that C or C++ can be written safely. It doesn’t make sense to talk about C and C++ together like that and the idea that it would possibly maybe make sense to talk about two fairly different languages the same way is very much the root cause why some people consider it impossible to write “safe” C++. C and C++ probably have as much in common as C and Rust (both of these have pointers, so they must be the same) or as Haskell and Java (both of these have types/classes, so they must be the same).

gmjosack 11y ago
I knew I was going to get this comment when I wrote this... I only mention those two together as the previous options for low level, no runtime languages. Outside of Rust both C and C++ were independent options I've considered investing more deeply in.
topspin 11y ago
It does make sense to talk about C and C++ together like this. The fact is that writing high performance systems software means using systems interfaces, and until there is a portable interface that doesn't imply the use of malloc, pointers, etc., you can't escape the C legacy of C++ and the inherently unsafe product of it. Wherever you look in the C/C++ world you find this legacy (POSIX, OpenGL, OpenMAX, OpenMP, OpenCL, on and on) so no matter how determined you are to try to match Rust with `safe' C++ you get dragged back into C. The term "C/C++" is used and understood because it is 100% appropriate, and it will continue to be appropriate as long as unsafe C/C++ interfaces proliferate. Obviously Rust can't completely solve this problem either, but Rust at least provides a mechanism to isolate the C legacy parts behind tested and supposedly `safe' API interfaces, leaving the developer exclusively within his type+memory+data race safe environment. That is a superior model.