8 ms·

> If we accept that Rust is indeed more difficult to learn than comparable systems programming languages I do accept this, and I try to be honest about it when

> If we accept that Rust is indeed more difficult to learn than comparable systems programming languages I do accept this, and I try to be honest about it when I'm shilling Rust :) But at the same time, I think it's worth pointing out that what we mean by "learn" can really depend on context. The subjective experience of learning a language looks something like "getting my homework done and turned in for a grade". And in that sense, for sure, learning Rust is harder than learning C. (I won't make a claim about C++.) But what percentage of people who have "learned" C can actually write UB-free C with any reliability? For the folks who really can write UB-free C, how many years did it take you to get to that point?

IshKebab 4y ago
Yes, I would say even compared to something like Python it can be easier to "learn" depending on what exactly you count as "learnt" (e.g. the ability to write bug free code). That said I think it's fair to assume your "getting my homework done" definition, in which case it is definitely harder. So I would describe it as "harder to learn but faster to finish projects".
thayne 4y ago
And even if you compare to languages that use garbage collection to prevent a lot of memory safety errors, rust's type system protects you from problems that occur there, like forgetting to close a file, or using a file after you close it, and many (but not all) race conditions with multiple threads.
- oconnor663 4y ago
  Also lots of "spooky mutation at a distance" bugs. Anywhere you see languages like Java or Python using immutable data structures, that's a place where I think Rust's shared/mut distinction solves the same problem more cleanly. And to be fair to C and C++, they also do this pretty well, if you go through the trouble of making your code const-correct.
unrealhoang 4y ago
Yes, to learn enough system programming to be able to contribute in large scale production project, Rust is massively easier than other options. An intermediate programmer coming from other high level language can confidently contribute to a big project after ~2-3 months of learning Rust, that number is almost unimaginable for C/C++.
- echelon 4y ago
  You can learn to use Rust in Go-like settings in under a week. You can have your first Actix[1]/Sqlx website up in a day, and you can have it doing some non-trivial work -- including sharing state between threads -- by Friday if you start today. Rust's type system alone is a compelling enough reason to try this. Cargo a close second. I'm willing to bet a lot of people start using Rust for backend web development. It's quite pleasant. [1] Or Axum
  - zozbot234 4y ago
    > I'm willing to bet a lot of people start using Rust for backend web development. It will happen, but it's not something you should do today. The async ecosystem in Rust is not yet ready for prime time, there are key language and stdlib features that are just missing. And this in turn holds the web ecosystem back. If you write a web backend in Rust today, you might just do a lot of pointless work that you'll have to rewrite in the future anyway as more advanced frameworks come along and the earlier ones are practically abandoned.
    - jackosdev 4y ago
      My company runs everything on AWS lambda, I’ve worked on Lambda with Go, Python and Typescript before this, Rust is by far the best experience I’ve had. Async works great, it’s definitely a lot harder to figure out the ecosystem than something like Go, but there’s nothing missing that I know of?
      - Thaxll 4y ago
        async does not work great, maybe for simple poc but once you start diging it's not well done. The debugging part is even worse.
cornholio 4y ago
> But what percentage of people who have "learned" C can actually write UB-free C with any reliability? If your alternative is C and you really need the power of C and a guarantee of no UB, then by all means, (struggle to) learn Rust. But I would argue that limits Rust to very few niches of system/expert programming. The number of people who write these is very, very limited, hence the use of the language, tooling, libraries, etc. The promise Rust makes nowadays is of an all around safe and productive language that can reward any effort spent fighting the type system and compiler with an error free execution. For most programming tasks people use languages in the real world, I would say Rust fails to deliver on this, in the sense that the effort spent to master it and use it day to day only affords limited benefits. If you need to move fast and don't absolutely need the strongest reliability guarantees, then Rust is a tar-pit.
- pyrale 4y ago
  > If you need to move fast and don't absolutely need the strongest reliability guarantees, then Rust is a tar-pit. That's true, but other type systems will likely fit your needs. For instance, if you're doing web, Elm's type system is head and shoulders above the more traditional options.
- andrewflnr 4y ago
  "Tar-pit" is overstating it significantly. It takes a paradigm shift, sure, but there are lots of options who feel Rust makes them more productive than other mainstream languages. A good type system can speed you up in some ways, too.
noduerme 4y ago
I've never tested my hand with Rust, but I've come to appreciate reading its ecosystem of champions who seem to be, like this is hard. that's a good thing.
- eximius 4y ago
  'hard' is not the goal, so much as "don't skip inherent complexity". It turns out things were already hard, Rust just has the tools to make it tractable to deal with all of it instead of ignoring it.
  - humanrebar 4y ago
    > "don't skip inherent complexity" ...except when it comes to build and packaging problems. The thing missing from this conversation is that we're talking about Rust the language, C the language, and C++ the language. In practical terms, the ways you go from "this is source code" to a running program matters a lot for end users. Point being, so far the Rust community mostly camps out in cargo land and ignores the hard problems of how to get systems code into the various ecosystems that benefit from close-to-the-metal programming. Maybe some day it will be figured out, but it's essential complexity to the broad problem space.
    - TazeTSchnitzel 4y ago
      Can't you integrate rustc into any C or C++ build system?
      - humanrebar 4y ago
        In theory. In practice, there are a lot of complications to sort out, especially if you want to have Rust call C that calls Rust that calls C that calls C++. Build requirements of transitive dependencies need to be communicated and propagated, keeping in mind that C and C++ rarely uses cargo and at least public Rust crates rarely use anything else.
    - eximius 4y ago
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
staunton 4y ago
Not that many developers even try writing UB-free C (or C++), or want to. Almost always the UB works (might not be portable, might break with a future compiler...) but im those cases they just debug the issues (or blame the compiler or don't update after all). I guess for moat projects that approach is actually economical.
- adgjlsfhk1 4y ago
  That's fine as long as you don't need to use the project for anything important.
tialaramex 4y ago
> If we accept that Rust is indeed more difficult to learn than comparable systems programming languages My problem is with "comparable systems programming languages". To me the only thing that fits there today is C++ and while a great many programming languages would be easier to learn than Rust, C++ is not one of them by a long shot. I think the C++ Quiz https://cppquiz.org/ https://cppquiz.org/ and the Rust Quiz https://dtolnay.github.io/rust-quiz/ https://dtolnay.github.io/rust-quiz/ illustrate handily. Neither of these languages is a walk in the park, but, notice they both have "Undefined behaviour" as a possible answer? Safe Rust doesn't actually have undefined behaviour, so you get to rule out one of the possibilities any time you don't see the "unsafe" keyword, which is in fact every time on the Rust Quiz. In C++ some of the quiz questions invoke UB, but good luck correctly guessing which ones.
- actionfromafar 4y ago
  In the future as C++ evolves (it had a hiatus of a decade or more where not much happened) it will be interesting to see how it will compare to Rust. C++ is performance first at any price. Hence UB. Rust is also after performance, but will specify implementation details where C++ will defer to compiler writers.
  - gmadsen 4y ago
    I don't think thats correct.. C++ has UB because of backwards compatibility, which has origins to design choices of C in the 70s. Its not like it is optimized for performance above all else, it had immediate needs to be close to metal, and that is the best they could do back then, there was not some "strongly typed" versus "performance" debate happening at the time. The creator of C++ would love for there to be safer abstractions, but has the baggage of the past to carry.
    - pornel 4y ago
      Modern C++ is still a safety-third design. std::optional is relatively new, and supports dereferencing, which when it’s empty is UB instead of an abort. There are no plans to add checks to any existing APIs, because “it didn’t have a branch before” is also considered a compatibility issue.
MichaelMoser123 4y ago
> For the folks who really can write UB-free C, how many years did it take you to get to that point? There is an easier path: you can test your C or C++ stuff with valgrind and get reasonable certainty that it work. However nowadays we are putting our trust in the borrow checker, and quietly ignore the fact that half of the rust stuff needs to use the 'unsafe' keyword.
- flohofwoe 4y ago
  For 'actual undefined behaviour' Clang's UBSAN is the better choice though (and for completeness: -Wall, -Wextra, --analyze or better clang-tidy and finally ASAN and TSAN).
- thesuperbigfrog 4y ago
  >> half of the rust stuff needs to use the 'unsafe' keyword. If this is true for the Rust code you are writing, either you are doing it wrong or perhaps you are writing lots of low-level embedded / drivers code? Having written C and C++ for years and now learning Rust, I much prefer the safety and nice features of Rust. Coding in C and C++ now feels like driving in a car without a seatbelt: you can do it if you don't have other options, but if you do have the choice, why wouldn't you?
  - steveklabnik 4y ago
    Even for low/level embedded drivers code, you don't use 50% unsafe.
    - thesuperbigfrog 4y ago
      In that case, it is being done wrong. I haven't had to use unsafe Rust yet, but have had to do some squirrely C tricks in the past for really low-level stuff.
- oconnor663 4y ago
  Both Rust and C/C++ have some important limitations when it comes to being categorically UB-free. Rust's limitations first: - If there's `unsafe` code in your dependencies, that's potentially just as bad as `unsafe` code in your own project. So you do have to be careful with what you pull in. - There are known "soundness holes" in the compiler, i.e. compiler bugs that let you corrupt memory without writing `unsafe`. However, the ones that remain are pretty obscure and very hard to hit accidentally. Now C and C++'s limitations: - Valgrind and all the sanitizers depend on test coverage. So 100% line coverage is table stakes for getting certainty out of these. And you probably also need to think about coverage of your dependencies. - None of these tools catch the UB that results from violating the "strict aliasing" rules. I believe there's something called "TypeSan" that promises to improve this situation, but it's experimental?
WastingMyTime89 4y ago
Can someone explain to me why this comment thread is so obsessed with UB? There is plenty of way to shoot yourself in the foot with well defined code in C and some undefined behaviours can be perfectly safe provided you know what the compiler you are targeting is doing. Is it a new fad in the Rust crowd to confound UB with memory unsafe? Some of the use here seems completely random to me.

IshKebab 4y ago

Yes, I would say even compared to something like Python it can be easier to "learn" depending on what exactly you count as "learnt" (e.g. the ability to write bug free code). That said I think it's fair to assume your "getting my homework done" definition, in which case it is definitely harder. So I would describe it as "harder to learn but faster to finish projects".

thayne 4y ago

And even if you compare to languages that use garbage collection to prevent a lot of memory safety errors, rust's type system protects you from problems that occur there, like forgetting to close a file, or using a file after you close it, and many (but not all) race conditions with multiple threads.

oconnor663 4y ago
Also lots of "spooky mutation at a distance" bugs. Anywhere you see languages like Java or Python using immutable data structures, that's a place where I think Rust's shared/mut distinction solves the same problem more cleanly. And to be fair to C and C++, they also do this pretty well, if you go through the trouble of making your code const-correct.

unrealhoang 4y ago

Yes, to learn enough system programming to be able to contribute in large scale production project, Rust is massively easier than other options. An intermediate programmer coming from other high level language can confidently contribute to a big project after ~2-3 months of learning Rust, that number is almost unimaginable for C/C++.

echelon 4y ago
You can learn to use Rust in Go-like settings in under a week. You can have your first Actix[1]/Sqlx website up in a day, and you can have it doing some non-trivial work -- including sharing state between threads -- by Friday if you start today. Rust's type system alone is a compelling enough reason to try this. Cargo a close second. I'm willing to bet a lot of people start using Rust for backend web development. It's quite pleasant. [1] Or Axum
- zozbot234 4y ago
  > I'm willing to bet a lot of people start using Rust for backend web development. It will happen, but it's not something you should do today. The async ecosystem in Rust is not yet ready for prime time, there are key language and stdlib features that are just missing. And this in turn holds the web ecosystem back. If you write a web backend in Rust today, you might just do a lot of pointless work that you'll have to rewrite in the future anyway as more advanced frameworks come along and the earlier ones are practically abandoned.
  - jackosdev 4y ago
    My company runs everything on AWS lambda, I’ve worked on Lambda with Go, Python and Typescript before this, Rust is by far the best experience I’ve had. Async works great, it’s definitely a lot harder to figure out the ecosystem than something like Go, but there’s nothing missing that I know of?
    - Thaxll 4y ago
      async does not work great, maybe for simple poc but once you start diging it's not well done. The debugging part is even worse.

cornholio 4y ago

> But what percentage of people who have "learned" C can actually write UB-free C with any reliability? If your alternative is C and you really need the power of C and a guarantee of no UB, then by all means, (struggle to) learn Rust. But I would argue that limits Rust to very few niches of system/expert programming. The number of people who write these is very, very limited, hence the use of the language, tooling, libraries, etc. The promise Rust makes nowadays is of an all around safe and productive language that can reward any effort spent fighting the type system and compiler with an error free execution. For most programming tasks people use languages in the real world, I would say Rust fails to deliver on this, in the sense that the effort spent to master it and use it day to day only affords limited benefits. If you need to move fast and don't absolutely need the strongest reliability guarantees, then Rust is a tar-pit.

pyrale 4y ago
> If you need to move fast and don't absolutely need the strongest reliability guarantees, then Rust is a tar-pit. That's true, but other type systems will likely fit your needs. For instance, if you're doing web, Elm's type system is head and shoulders above the more traditional options.
andrewflnr 4y ago
"Tar-pit" is overstating it significantly. It takes a paradigm shift, sure, but there are lots of options who feel Rust makes them more productive than other mainstream languages. A good type system can speed you up in some ways, too.

noduerme 4y ago

I've never tested my hand with Rust, but I've come to appreciate reading its ecosystem of champions who seem to be, like this is hard. that's a good thing.

eximius 4y ago
'hard' is not the goal, so much as "don't skip inherent complexity". It turns out things were already hard, Rust just has the tools to make it tractable to deal with all of it instead of ignoring it.
- humanrebar 4y ago
  > "don't skip inherent complexity" ...except when it comes to build and packaging problems. The thing missing from this conversation is that we're talking about Rust the language, C the language, and C++ the language. In practical terms, the ways you go from "this is source code" to a running program matters a lot for end users. Point being, so far the Rust community mostly camps out in cargo land and ignores the hard problems of how to get systems code into the various ecosystems that benefit from close-to-the-metal programming. Maybe some day it will be figured out, but it's essential complexity to the broad problem space.
  - TazeTSchnitzel 4y ago
    Can't you integrate rustc into any C or C++ build system?
    - humanrebar 4y ago
      In theory. In practice, there are a lot of complications to sort out, especially if you want to have Rust call C that calls Rust that calls C that calls C++. Build requirements of transitive dependencies need to be communicated and propagated, keeping in mind that C and C++ rarely uses cargo and at least public Rust crates rarely use anything else.
  - eximius 4y ago

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

staunton 4y ago

Not that many developers even try writing UB-free C (or C++), or want to. Almost always the UB works (might not be portable, might break with a future compiler...) but im those cases they just debug the issues (or blame the compiler or don't update after all). I guess for moat projects that approach is actually economical.

adgjlsfhk1 4y ago
That's fine as long as you don't need to use the project for anything important.

tialaramex 4y ago

> If we accept that Rust is indeed more difficult to learn than comparable systems programming languages My problem is with "comparable systems programming languages". To me the only thing that fits there today is C++ and while a great many programming languages would be easier to learn than Rust, C++ is not one of them by a long shot. I think the C++ Quiz https://cppquiz.org/ https://cppquiz.org/ and the Rust Quiz https://dtolnay.github.io/rust-quiz/ https://dtolnay.github.io/rust-quiz/ illustrate handily. Neither of these languages is a walk in the park, but, notice they both have "Undefined behaviour" as a possible answer? Safe Rust doesn't actually have undefined behaviour, so you get to rule out one of the possibilities any time you don't see the "unsafe" keyword, which is in fact every time on the Rust Quiz. In C++ some of the quiz questions invoke UB, but good luck correctly guessing which ones.

actionfromafar 4y ago
In the future as C++ evolves (it had a hiatus of a decade or more where not much happened) it will be interesting to see how it will compare to Rust. C++ is performance first at any price. Hence UB. Rust is also after performance, but will specify implementation details where C++ will defer to compiler writers.
- gmadsen 4y ago
  I don't think thats correct.. C++ has UB because of backwards compatibility, which has origins to design choices of C in the 70s. Its not like it is optimized for performance above all else, it had immediate needs to be close to metal, and that is the best they could do back then, there was not some "strongly typed" versus "performance" debate happening at the time. The creator of C++ would love for there to be safer abstractions, but has the baggage of the past to carry.
  - pornel 4y ago
    Modern C++ is still a safety-third design. std::optional is relatively new, and supports dereferencing, which when it’s empty is UB instead of an abort. There are no plans to add checks to any existing APIs, because “it didn’t have a branch before” is also considered a compatibility issue.

MichaelMoser123 4y ago

> For the folks who really can write UB-free C, how many years did it take you to get to that point? There is an easier path: you can test your C or C++ stuff with valgrind and get reasonable certainty that it work. However nowadays we are putting our trust in the borrow checker, and quietly ignore the fact that half of the rust stuff needs to use the 'unsafe' keyword.

flohofwoe 4y ago
For 'actual undefined behaviour' Clang's UBSAN is the better choice though (and for completeness: -Wall, -Wextra, --analyze or better clang-tidy and finally ASAN and TSAN).
thesuperbigfrog 4y ago
>> half of the rust stuff needs to use the 'unsafe' keyword. If this is true for the Rust code you are writing, either you are doing it wrong or perhaps you are writing lots of low-level embedded / drivers code? Having written C and C++ for years and now learning Rust, I much prefer the safety and nice features of Rust. Coding in C and C++ now feels like driving in a car without a seatbelt: you can do it if you don't have other options, but if you do have the choice, why wouldn't you?
- steveklabnik 4y ago
  Even for low/level embedded drivers code, you don't use 50% unsafe.
  - thesuperbigfrog 4y ago
    In that case, it is being done wrong. I haven't had to use unsafe Rust yet, but have had to do some squirrely C tricks in the past for really low-level stuff.
oconnor663 4y ago
Both Rust and C/C++ have some important limitations when it comes to being categorically UB-free. Rust's limitations first: - If there's `unsafe` code in your dependencies, that's potentially just as bad as `unsafe` code in your own project. So you do have to be careful with what you pull in. - There are known "soundness holes" in the compiler, i.e. compiler bugs that let you corrupt memory without writing `unsafe`. However, the ones that remain are pretty obscure and very hard to hit accidentally. Now C and C++'s limitations: - Valgrind and all the sanitizers depend on test coverage. So 100% line coverage is table stakes for getting certainty out of these. And you probably also need to think about coverage of your dependencies. - None of these tools catch the UB that results from violating the "strict aliasing" rules. I believe there's something called "TypeSan" that promises to improve this situation, but it's experimental?

WastingMyTime89 4y ago

Can someone explain to me why this comment thread is so obsessed with UB? There is plenty of way to shoot yourself in the foot with well defined code in C and some undefined behaviours can be perfectly safe provided you know what the compiler you are targeting is doing. Is it a new fad in the Rust crowd to confound UB with memory unsafe? Some of the use here seems completely random to me.