5 ms·

Very naive question. What's the main selling point of Rust besides being stably sponsored by Mozilla?

eropple 3y ago
In short: the type system is significantly more expressive and encourages domain modeling that tends to lead to fewer errors; "if the compiler says it's OK, it'll be OK" isn't strictly true but it's often pretty close. Rust also offers stronger guarantees around memory safety than C, as well as C++ as commonly practiced. (Which is to say, you can write very memory-safe C++, but you will work at it.)
chaxor 3y ago
The build tools are incredible. That's the main reason many people love Rust. For kernel dev however, the memory safety is a big win.
paulddraper 3y ago
Statically checked memory management Advanced typing Build tools
deleted 3y ago
[deleted]
adrianN 3y ago
Rust‘s type system prevents memory safety bugs because it reasons about object lifetimes statically. At the same time rust allows you to write systems code on bare metal.
- dosshell 3y ago
  > it reasons about object lifetimes statically. How does that differ from RAII? I think i misunderstand you or lack knowledge, because this sounds exactly like RAII. I know that rust has major compile time checks, but saying that the difference is that it reason about life time as difference to c++ is misleading. I think the major point of c++ compared to c is that c++ "reason about object lifetime statically" with deconstructors and RAII. And saying that rust do this and implying c++ don't is misleading.
  - oconnor663 3y ago
    Rust and C++ work very similarly with respect to objects you own. In both languages they get cleaned up by a destructor when they go out of scope. However, Rust also has a lot of language features that deal with objects you borrow, i.e. have a pointer to. In C++ you might make a "use-after-free" mistake and hold a pointer to an object that's already been destructed, which can lead to all sorts of memory corruption. In Rust, the same mistake almost always results in a compile-time error. The part of the compiler that enforces all this is called the "borrow checker", and getting used to the borrow checker's rules is a big part of Rust's learning curve. One thing C++ programmers might be interested to learn, is that this doesn't only apply to simple variables and references; it also applies to library data structures and their methods. The Rust compiler doesn't really "know" what the .clear() method on a Vec does, but it knows enough to prevent you from calling that method while you're holding references to the Vec's elements.
    - deleted 3y ago
      [deleted]
    - baq 3y ago
      > getting used to the borrow checker's rules is a big part of Rust's learning curve. It’s also a big part of C and C++’s learning curves, it’s just that the compiler doesn’t tell you about it; you’re being taught by segfaults and silent memory corruption instead.
      - oconnor663 3y ago
        Very true. My hot take on this is, if you want to learn C or C++ "properly" (not just well enough to get your homework done, but well enough to write medium-size programs that pass ASan/UBSan/TSan), the fastest way is to learn Rust first. This is emphatically not because Rust is quick to learn, but rather because ownership and borrowing discipline takes years of mentorship to absorb in C and C++, and plenty of career programmers never really get it.
    - zozbot234 3y ago
      > Rust and C++ work very similarly with respect to objects you own. There is one major difference. In Rust you can memcpy objects you own to a different base address and they will still work, unless they're pointed at by a Pin<> type (as such, code that requires objects to stay put in memory must take a Pin<> reference. This arrangement may potentially be replaced by a special "?Move" trait in future editions of Rust). C++ pins all objects by default and allows objects to have custom "move" constructors, to sort of enable them to be moved elsewhere. In C++, objects that get "moved" must leave behind something that can be destructed cleanly; Rust has no such limitation, at least wrt. ordinary moves. Arguably the closest thing it has to a C++ move is the .take() pattern, which leaves a default-constructed object behind. But this is rarely used. The general tradeoff is that the Rust pattern memcpy's compound objects more often, but has less gratuitous use of the heap and less pointer chasing compared to idiomatic C/C++. This is a valid choice once one has the compiler support that Rust provides.
avgcorrection 3y ago
The language features.
formerly_proven 3y ago
I don’t think Mozilla has had any major sponsorship role for a few years now?
- hartator 3y ago
  > https://internals.rust-lang.org/t/mozilla-is-hiring-for-the-rust-team-2019/9949 https://internals.rust-lang.org/t/mozilla-is-hiring-for-the-... It seems that some Rust folks are still on Mozilla payroll.
  - steveklabnik 3y ago
    That post is from 2019, the layoffs of the teams were in 2020. Mozilla is still a member of the foundation, so they do support it in that sense, but they are one of many companies that do so.
oconnor663 3y ago
There are two very broad set of features: 1) Memory safety. If you live in the world of kernels and embedded code, your options are mostly C, C++, and (as of just the last few years) Rust. Of those, only Rust reliably prevents memory corruption mistakes like use-after-free. 2) Being a 21st century language. Rust has a lot of features that any new language would be expected to have these days: a unified build system, a library ecosystem that the build sytem knows about, slices over arrays and vectors, UTF-8 strings, convenient ways to de/serialize JSON, something like async/await, etc. This makes it competitive with languages like Java and Python for doing "everyday stuff", where realistically ~no one would use C. The main downside of Rust in a Java/Python sort of context is that the learning curve is a lot steeper. A couple other notes: - Some of nice 21st century features (like JSON) go away when you're writing embedded/kernel code, but others still work. Embedded ("no_std") Rust still has enums, error handling, slices, iterators, and sometimes even async/await. Those quality-of-life features are hard to replicate in C, even if you believe your code is 100% bug free :) - If you know you're going to be writing multithreaded code, Rust's thread safety features are really unmatched. A lot of the same machinery that gets used for memory safety also turns out to be useful for thread safety. Libraries like Rayon make it surprisingly convenient to write multithreaded code, while also catching a huge percentage of mistakes at compile time. (Deadlocks are still possible though.)
- hartator 3y ago
  > Memory safety Another very naive question. Are memory safety concerns from a cybersecurity standpoint or from less-dev error standpoint?
  - eloisant 3y ago
    Mostly from a less-dev error standpoint but I think you gain in cybersecurity as well, as the language won't let you write code that accesses memory in places it's not supposed to.
    - masklinn 3y ago
      It's mostly from the cybersecurity standpoint actually, at least for large projects / companies. MS, Chromium, Project Zero, Mozilla, have pretty consistently found that north of 70% of vulnerabilities were rooted in memory safety. The dev-error is broader language guarantees, which dovetail into memory safety but are useful on their own e.g. data race safety, rich type system, ...
secondcoming 3y ago
You've got to be trolling
jcranmer 3y ago
I can't give you just one selling point, because Rust has two main competitive features, and it's hard for me to say which one is enticing FreeBSD more here: 1. Rust has a more modern sense of computer primitives than C does. For example, C has the char-short-int-long-long long set of types which correspond to 8, 16, 32, and 64 bit integers in practice (and yes, 5 types for 4 sizes), whereas Rust has u8/u16/u32/u64. Rust also has a builtin slice type, which is a desperately needed notion of pointer + size of array, and C's lack of such type has proven to be the source of much malware. The standard library is also somewhat richer too, you have better support for things like threads or networking than C/C++ does. But note that Rust is still like C in that it has a very thin runtime layer, and can also go a step further and have "no" standard library at all, which is necessary in several contexts. 2. The borrow checker. Effectively, use-after-free (or any other lifetime issue) vulnerabilities become compiler errors, and even many kinds of data races are also turned into compiler errors. Also it can do things like make iterator invalidation issues a compiler error as well.
logicprog 3y ago
One of the biggest things about Rust for me is that it's essentially Prometheus, bringing the fire of modern languages and more advances PL theory to systems programming, which imo is sorely needed. We don't need a 10% better C or C++, we need a huge jump for the field. Rust I think does this. They have: 1. A type system that's deeply inspired by OCaml, a language that's designed and used by a lot of programming language research people and is widely praised (just look at how every other language — C#, Java, Kotlin — is suddenly trying to pile half baked imitations of ML features like ADTs and deep pattern matching onto their existing OOP type systems), except they've both imemented the type system correctly and fully, and also filed off all the warts and awkward features, and replaced OCaml's verbose and underpowered first class module system with Haskell style type classes 2. got amazing, highly flexible and generalized iterator and monad support (you can use iterator methods on monads), basically second only to Haskell itself, that compiles down to the equivalent of hand written assembly code loops 3. an error handling system using monads that neatly sidesteps the issues with both traditional C style error handling and exceptions that combines with point two in an exponential curve of awesomeness for error handling 4. hygienic (from Racket) and procedural (eg Common Lisp) macros 5. And finally ofc their statuc memory safety and race condition safety, which is based on linear types ala Idris. But most importantly, Rust's designers seem to IMO have carefully picked only the advanced programming language features that tend to make your code clearer as well as more correct, and help you model problems at the right level of abstraction to be intuitive, and also only features that can be implemented in a way that is as performant as the equivalent C++ code, roughly speaking at least. They also seem to have been very careful with how they integrate and implement everything in order to uphold those goals. So you get to have 90% of the power of a language like Haskell, in a language that performs like, and has the low level capabilities of, C++, with the extra benefit of — for instance — less dogmatic puritanism and more deterministic and comprehensible performance and execution properties then Haskell, and less Lovecraftian horror full of surprise gotchas than C++. It's kind of like the ultimate pragmatic language for someone like me who has gone deep into pure functional languages and other esoteric languages and wants to have as much as of that goodness as is practical.
- deleted 3y ago
  [deleted]

In short: the type system is significantly more expressive and encourages domain modeling that tends to lead to fewer errors; "if the compiler says it's OK, it'll be OK" isn't strictly true but it's often pretty close. Rust also offers stronger guarantees around memory safety than C, as well as C++ as commonly practiced. (Which is to say, you can write very memory-safe C++, but you will work at it.)

chaxor 3y ago

The build tools are incredible. That's the main reason many people love Rust. For kernel dev however, the memory safety is a big win.

paulddraper 3y ago

Statically checked memory management Advanced typing Build tools

deleted 3y ago

[deleted]

adrianN 3y ago

Rust‘s type system prevents memory safety bugs because it reasons about object lifetimes statically. At the same time rust allows you to write systems code on bare metal.

dosshell 3y ago
> it reasons about object lifetimes statically. How does that differ from RAII? I think i misunderstand you or lack knowledge, because this sounds exactly like RAII. I know that rust has major compile time checks, but saying that the difference is that it reason about life time as difference to c++ is misleading. I think the major point of c++ compared to c is that c++ "reason about object lifetime statically" with deconstructors and RAII. And saying that rust do this and implying c++ don't is misleading.
- oconnor663 3y ago
  Rust and C++ work very similarly with respect to objects you own. In both languages they get cleaned up by a destructor when they go out of scope. However, Rust also has a lot of language features that deal with objects you borrow, i.e. have a pointer to. In C++ you might make a "use-after-free" mistake and hold a pointer to an object that's already been destructed, which can lead to all sorts of memory corruption. In Rust, the same mistake almost always results in a compile-time error. The part of the compiler that enforces all this is called the "borrow checker", and getting used to the borrow checker's rules is a big part of Rust's learning curve. One thing C++ programmers might be interested to learn, is that this doesn't only apply to simple variables and references; it also applies to library data structures and their methods. The Rust compiler doesn't really "know" what the .clear() method on a Vec does, but it knows enough to prevent you from calling that method while you're holding references to the Vec's elements.
  - deleted 3y ago
    [deleted]
  - baq 3y ago
    > getting used to the borrow checker's rules is a big part of Rust's learning curve. It’s also a big part of C and C++’s learning curves, it’s just that the compiler doesn’t tell you about it; you’re being taught by segfaults and silent memory corruption instead.
    - oconnor663 3y ago
      Very true. My hot take on this is, if you want to learn C or C++ "properly" (not just well enough to get your homework done, but well enough to write medium-size programs that pass ASan/UBSan/TSan), the fastest way is to learn Rust first. This is emphatically not because Rust is quick to learn, but rather because ownership and borrowing discipline takes years of mentorship to absorb in C and C++, and plenty of career programmers never really get it.
  - zozbot234 3y ago
    > Rust and C++ work very similarly with respect to objects you own. There is one major difference. In Rust you can memcpy objects you own to a different base address and they will still work, unless they're pointed at by a Pin<> type (as such, code that requires objects to stay put in memory must take a Pin<> reference. This arrangement may potentially be replaced by a special "?Move" trait in future editions of Rust). C++ pins all objects by default and allows objects to have custom "move" constructors, to sort of enable them to be moved elsewhere. In C++, objects that get "moved" must leave behind something that can be destructed cleanly; Rust has no such limitation, at least wrt. ordinary moves. Arguably the closest thing it has to a C++ move is the .take() pattern, which leaves a default-constructed object behind. But this is rarely used. The general tradeoff is that the Rust pattern memcpy's compound objects more often, but has less gratuitous use of the heap and less pointer chasing compared to idiomatic C/C++. This is a valid choice once one has the compiler support that Rust provides.

avgcorrection 3y ago

The language features.

formerly_proven 3y ago

I don’t think Mozilla has had any major sponsorship role for a few years now?

hartator 3y ago
> https://internals.rust-lang.org/t/mozilla-is-hiring-for-the-rust-team-2019/9949 https://internals.rust-lang.org/t/mozilla-is-hiring-for-the-... It seems that some Rust folks are still on Mozilla payroll.
- steveklabnik 3y ago
  That post is from 2019, the layoffs of the teams were in 2020. Mozilla is still a member of the foundation, so they do support it in that sense, but they are one of many companies that do so.

oconnor663 3y ago

There are two very broad set of features: 1) Memory safety. If you live in the world of kernels and embedded code, your options are mostly C, C++, and (as of just the last few years) Rust. Of those, only Rust reliably prevents memory corruption mistakes like use-after-free. 2) Being a 21st century language. Rust has a lot of features that any new language would be expected to have these days: a unified build system, a library ecosystem that the build sytem knows about, slices over arrays and vectors, UTF-8 strings, convenient ways to de/serialize JSON, something like async/await, etc. This makes it competitive with languages like Java and Python for doing "everyday stuff", where realistically ~no one would use C. The main downside of Rust in a Java/Python sort of context is that the learning curve is a lot steeper. A couple other notes: - Some of nice 21st century features (like JSON) go away when you're writing embedded/kernel code, but others still work. Embedded ("no_std") Rust still has enums, error handling, slices, iterators, and sometimes even async/await. Those quality-of-life features are hard to replicate in C, even if you believe your code is 100% bug free :) - If you know you're going to be writing multithreaded code, Rust's thread safety features are really unmatched. A lot of the same machinery that gets used for memory safety also turns out to be useful for thread safety. Libraries like Rayon make it surprisingly convenient to write multithreaded code, while also catching a huge percentage of mistakes at compile time. (Deadlocks are still possible though.)

hartator 3y ago
> Memory safety Another very naive question. Are memory safety concerns from a cybersecurity standpoint or from less-dev error standpoint?
- eloisant 3y ago
  Mostly from a less-dev error standpoint but I think you gain in cybersecurity as well, as the language won't let you write code that accesses memory in places it's not supposed to.
  - masklinn 3y ago
    It's mostly from the cybersecurity standpoint actually, at least for large projects / companies. MS, Chromium, Project Zero, Mozilla, have pretty consistently found that north of 70% of vulnerabilities were rooted in memory safety. The dev-error is broader language guarantees, which dovetail into memory safety but are useful on their own e.g. data race safety, rich type system, ...

secondcoming 3y ago

You've got to be trolling

jcranmer 3y ago

I can't give you just one selling point, because Rust has two main competitive features, and it's hard for me to say which one is enticing FreeBSD more here: 1. Rust has a more modern sense of computer primitives than C does. For example, C has the char-short-int-long-long long set of types which correspond to 8, 16, 32, and 64 bit integers in practice (and yes, 5 types for 4 sizes), whereas Rust has u8/u16/u32/u64. Rust also has a builtin slice type, which is a desperately needed notion of pointer + size of array, and C's lack of such type has proven to be the source of much malware. The standard library is also somewhat richer too, you have better support for things like threads or networking than C/C++ does. But note that Rust is still like C in that it has a very thin runtime layer, and can also go a step further and have "no" standard library at all, which is necessary in several contexts. 2. The borrow checker. Effectively, use-after-free (or any other lifetime issue) vulnerabilities become compiler errors, and even many kinds of data races are also turned into compiler errors. Also it can do things like make iterator invalidation issues a compiler error as well.

logicprog 3y ago

One of the biggest things about Rust for me is that it's essentially Prometheus, bringing the fire of modern languages and more advances PL theory to systems programming, which imo is sorely needed. We don't need a 10% better C or C++, we need a huge jump for the field. Rust I think does this. They have: 1. A type system that's deeply inspired by OCaml, a language that's designed and used by a lot of programming language research people and is widely praised (just look at how every other language — C#, Java, Kotlin — is suddenly trying to pile half baked imitations of ML features like ADTs and deep pattern matching onto their existing OOP type systems), except they've both imemented the type system correctly and fully, and also filed off all the warts and awkward features, and replaced OCaml's verbose and underpowered first class module system with Haskell style type classes 2. got amazing, highly flexible and generalized iterator and monad support (you can use iterator methods on monads), basically second only to Haskell itself, that compiles down to the equivalent of hand written assembly code loops 3. an error handling system using monads that neatly sidesteps the issues with both traditional C style error handling and exceptions that combines with point two in an exponential curve of awesomeness for error handling 4. hygienic (from Racket) and procedural (eg Common Lisp) macros 5. And finally ofc their statuc memory safety and race condition safety, which is based on linear types ala Idris. But most importantly, Rust's designers seem to IMO have carefully picked only the advanced programming language features that tend to make your code clearer as well as more correct, and help you model problems at the right level of abstraction to be intuitive, and also only features that can be implemented in a way that is as performant as the equivalent C++ code, roughly speaking at least. They also seem to have been very careful with how they integrate and implement everything in order to uphold those goals. So you get to have 90% of the power of a language like Haskell, in a language that performs like, and has the low level capabilities of, C++, with the extra benefit of — for instance — less dogmatic puritanism and more deterministic and comprehensible performance and execution properties then Haskell, and less Lovecraftian horror full of surprise gotchas than C++. It's kind of like the ultimate pragmatic language for someone like me who has gone deep into pure functional languages and other esoteric languages and wants to have as much as of that goodness as is practical.

deleted 3y ago
[deleted]