10 ms·

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. "Th

As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. "This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!" Let's quote the article: > I’d say as it currently stands Rust has poor developer ergonomics but produces memory safe software, whereas Zig has good developer ergonomics and allows me to produce memory safe software with a bit of discipline. The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. It's true when you ride a skateboard with a helmet on, it's true when you program, it's true for sex. Instead you see a lot of arguments with anecdotal or indeterminate language. "Most people [that I talk to] don't seem to have much trouble unless they're less experienced." It's an amazing piece of rhetoric. In one sentence the ergonomic argument has been dismissed by denying subjectivity exists or matters and then implying that those who disagree are stupid.

jasonpeacock 1y ago
> produce memory safe software with a bit of discipline "a bit of discipline" is doing a lot of work here. "Just don't write (memory) bugs!" hasn't produced (memory) safe C, and they've been trying for 50yrs. The best practices have been to bolt on analyzers and strict "best practice" standards to enforce what should be part of the language. You're either writing in Rust, or you're writing in something else + using extra tools to try and achieve the same result as Rust.
- tptacek 1y ago
  I actively dislike Zig's memory safety story, but this isn't a real argument until you can start showing real vulnerabilities --- not models --- that exploit the gap in rigor between the two languages. Both Zig and Rust are a step function in safety past C; it is not a given that Rust is that from Zig, or that that next step matters in practice the way the one from C does.
  - dadrian 1y ago
    I like Zig, although the Bun Github tracker is full of segfaults in Zig that are presumably quite exploitable. Unclear what to draw from this, though. [1]: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
    - vanderZwan 1y ago
      Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team"? Because if so then I'm not surprised and also don't think Zig is really to blame for that.
      - dadrian 1y ago
        Not clear to me there's a correlation between hours worked and number of memory safety vulnerabilities
        blacksmith_tb 1y ago
        I think the implication is something like "overwork / fraying morale from long hours means shipping more bugs".
        tptacek 1y ago
        The point of memory-safe languages is to foreclose on a set of particularly nasty bugs, regardless of how frayed engineer morale is.
        vanderZwan 1y ago
        I'm pretty sure that in an overworked environment the engineers would reach for Rust's unsafe mode pretty quickly because they're too tired to make sense of the borrow checker.
- fpoling 1y ago
  As Rust Zig has type-safe enums/sum types. That alone eliminates a lot of problems with C. Plus sane error handling with good defaults that are better than Rust also contributes to code with less bugs. Surely there is no borrow checker, but a lot of memory-safety issues with C and C++ comes from lack of good containers with sane interfaces (std::* in C++ is just bad from memory safety point of view). If C++ gained the proper sum types, error handling and templates in Zig style 15 years ago and not the insanity that is in modern C++ Rust may not exist or be much more niche at this point.
  - TuxSH 1y ago
    > If C++ gained the proper sum types AFAIK "P2688 R5 Pattern Matching: match Expression" exists and is due C++29 (what actually matters is when it's accepted and implemented by compilers anyway) Also, cheap bound checks (in Rust) are contingent to Rust's aliasing model.
  - whatevaa 1y ago
    Buffer overruns are most common memory related RCE's. So bounds checking arrays/strings BY DEFAULT is needed.
- rixed 1y ago
  > "Just don't write (memory) bugs!" hasn't produced (memory) safe C Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Sure, it's easier to write a robust program in almost every other language. But to state that nobody ever produced a memory safe C program is just wrong. Maybe it was just rethoric for you, but I'm afraid some may read that and think it's a well established fact.
  - zanellato19 1y ago
    >Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Can you provide examples for it? Because it honestly doesn't seem like it has ever been done.
    - dayvster 1y ago
      [flagged]
      - hannofcart 1y ago
        Haven't written C in a while but I think this program has an integer overflow error when you input 2 really large integers such that the sum is more than a 32 bit signed integer. Also I believe in entering null values will lead to undefined behaviour.
        dayvster 1y ago
        har har... have my upvote!
        Karrot_Kream 1y ago
        Memory safe doesn't mean protection from integer overflow unless you use that integer to index into some array. I'm not sure how you'd enter NULL given scanf.
anon-3988 1y ago
I would argue that good C or C++ code is actually just Rust code with extra steps. So in this sense, Rust gets you to the "desired result" much easier compared to using C or C++ because no one is there to enforce anything and make you do it. You can argue that using C or C++ can get you to 80% of the way but most people don't actively think "okay, how do I REALLY mess up this program?" and fix all the various invariant that they forgot to handle. Even worse, this issue is endemic in higher level dynamic languages like Python too. Most people most of the time only think about the happy path.
- vanderZwan 1y ago
  What does that have to do with Zig though?
- wolvesechoes 1y ago
  There are valid and safe programs rejected by Rust compiler if you don't go through rituals required to please it (slaping Rc, Refcells etc). No amount of "oh your Rust code is actually something you would ended up with if you would choose C" will change that.
  - simonask 1y ago
    You know, the `unsafe` keyword exists. You’re allowed to use it. If your algorithm is truly safe, and as you say, there are many safe things the borrow checker cannot verify, that’s exactly what `unsafe` is for. Ideally you can also design a safe API around it using the appropriate language primitives to model the abstraction, but there’s no requirement.
  - crote 1y ago
    Of course. After all, it is mathematically impossible to prove the correctness of all valid and safe programs - the halting problem clearly shows that. The real question should not be "Are there valid and safe programs Rust will reject?" but "How common is it that your well-written valid and safe program will be rejected by the Rust compiler?". In practice the vast majority will be accepted, and what remains is stuff the Rust compiler cannot prove to be correct. If Rust doesn't like your code, there are two solutions. The first is to go through the rituals to rewrite it as provably-safe code - which can indeed feel a bit tedious if your code was designed using principles which don't map well to Rust. The second is to use `unsafe` blocks - but that means proving its safety is up to the programmer. But as we've historically seen with C and unsafe-heavy Rust code bases, programmers are horrible at proving safety, so your mileage may vary. I don't want to be the "you're holding it wrong" person, but "Rust rejected my valid and safe program" more often than not means "there's a subtle bug in my program I am not aware of yet". The Rust borrow checker has matured a lot since its initial release, and it doesn't have any trouble handling the low-hanging fruit anymore. What's left is mainly complex and hard-to-reason-about stuff, and that's exactly the kind of code humans struggle with as well.
weinzierl 1y ago
"It's true when you ride a skateboard with a helmet on." Rust is not the helmet. It is not a safety net that only gives you a benefit in rare catastrophic events. Rust is your lane assist. It relieves you from the burden of constant vigilance. A C or C++ programmer that doesn't feel relief when writing Rust has never acquired the mindset that is required to produce safe, secure and reliable code.
- nsagent 1y ago
  I don't think this is any better of an argument. Maybe yours is a more apt analogy, but as a very competent driver I can't tell you how often lane assist has driven me crazy. If I could simply rely on it in all situations, then it would be fine. It's the death of a thousand cuts each and every time it behaves less than ideally that gets to me and I've had to turn it off in every single car a I've driven that has it.
- omnicognate 1y ago
  Public Safety Announcement: Lane assist does not relieve you from the burden of constant vigilance.
- travisgriggs 1y ago
  > Rust is your lane assist. It relieves you from the burden of constant vigilance. Interesting analogy. I love lane assist. When I love it. And hate it when it gets in the way. It can actively jerk the car in weird and surprising ways when presented with things it doesn’t cope well with. So I manage when it’s active very proactively. Rust of course has unsafe… but… to keep the analogy, that would be like driving in a peer group where everyone was always asking me if I had my lane assist on, where when I arrived at a destination, I was badgered with “did you do the whole drive with lane assist?” And if I didn’t, I’d have explained to me the routes and techniques I could have used to arrive at my destination using used lane assist the whole way. Disclaimer, I have only dabbled a little with rust. It is the religion behind and around it that I struggle with, not the borrow checker.
  - danudey 1y ago
SoraNoTenshi 1y ago
It also drives me insane when i dump the problems i have with Rust about this exact issue, that i usually have to restructure my code to satisfy the compilers needs, and they come at me with the "Skill Issue" club... I honestly don't even know what to respond to that, but it's kind of weird to me to honestly think that you'd need essentially a "PhD" in order to use a tool...
- mattwilsonn888 1y ago
  It's an amazing piece of marketing to corner anyone who dislikes a certain hassle as being mentally deficient - that's what "skill issue" means in this context.
  - shakow 1y ago
    > that's what "skill issue" means in this context. “Skill issue” definitely does not means “mentally deficient”. It comes from the videogames world, where it is used to disparage the lack of training/natural ability of other players; frequently accompanied by “get good”, i.e. continue training & grinding to up your skill.
    - mattwilsonn888 1y ago
      Do I have to put the pieces together for you? What is the relevant skill in programming? Problem solving. It's not aim or timing or hand-eye coordination lmao.
      - vrmiguel 1y ago
        Not sure I get your point. One can definitely "get good" at problem solving. Isn't that the whole purpose of Leetcode and whatnot? I struggled with Rust at first but now it feels quite natural, and is the language I use at work and for my open-source work. I was not "mentally deficient" when I struggled with Rust (at least that I know of :v), while you could say I had a skill issue with the language
- 1y ago
pjmlp 1y ago
As I mention elsewhere, C crowd didn't call languages like Pascal and Modula-2 programming with straightjacket for no reason. Turns out not wearing that helmet, and continously falling down for 40 years at the skate park has its price.
aw1621107 1y ago
> it's a universal tradeoff, that is: Safety is less ergonomic. I'm not sure that that tradeoff is quite so universal. GC'd languages (or even GC'd implementations like Fil-C) are equally or even more memory-safe than Rust but aren't necessarily any less ergonomic. If anything, it's not an uncommon position that GC'd languages are more ergonomic since they don't forbid some useful patterns that are difficult or impossible to express in safe Rust.
- SkiFire13 1y ago
  The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.
  - quotemstr 1y ago
    > The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one. That's a myth that just won't die. How is it that people simultaneously believe 1) GC makes a language slow, and 2) Go is fast? Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only with manual memory management.
    - rixed 1y ago
      > How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast? Easy one: either not the same people, or people holding self contradicting thoughts. GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower. Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace of mind.
      - quotemstr 1y ago
        > also because of the boxing Not every GC boxes primitives. Most don't.
freeopinion 1y ago
Arguing that one language is more ergonomic but can produce the same safety if you use it unergonomically is... not very useful in a context where safety is highly valued.
thinkharderdev 1y ago
> As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. I interpreted the parent to be saying that ergonomics IS (at least partly) subjective. The subjective aspect is "what you are used to". And once you get used to Rust its ergonomics are fine, something I agree with having used Rust for a few years now. > The Rust community should be upfront about this tradeoff I think they are. But more to the point, I think that safety is not really something you can reasonably "trade-off", at least not for non-toy software. And I think that because I don't really see C/C++/Zig people saying "we're trading off safety for developer productivity/performance/etc". I see them saying "we can write safe code in an unsafe language by being really careful and having a good process". Maybe they're right, but I'm skeptical based on the never-ending proliferation of memory safety issues in C/C++ code.
- mattwilsonn888 1y ago
  I think you are clearly good-faith. The issue is the underlying and unfair assumption that is so common in these debates: that the memory-unsafe language we're comparing against Rust is always C/C++, rather than a modern approach like Zig or Odin (which will share many arguments against C/C++). You can prove to yourself this happens by looking around this thread! The topic is Zig vs. Rust and just look at how many pro-Rust arguments mention C (including yours). It's a strong argument if we pose C as the opponent, because C can be so un-ergonomic that even Rust with its added constraints competes on that aspect. But compare it to something like Zig or Odin (which has ergonomic and safety features like passing allocators to any and all functions, bounds checking by default, sane slice semantics which preclude the need for pointer arithmetic) and the ergonomics/safety argument isn't so simple.
  - ksec 1y ago
    Thank You that makes a lot of sense. I guess we will have to wait for Zig to become 1.0 first and then do a proper comparison.
  - simonask 1y ago
    Zig is an immense improvement, but it’s not a production language at the time of writing. Not a lot of people feel qualified to actually compare the two. At the same time, I will argue that Zig’s improvements over C are much less substantial compared to something like Rust. It’s great, but not a paradigm shift.
nicoburns 1y ago
> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. I'd agree with that if the comparison is JavaScript or Python. If the comparison is Zig (or C or C++) then I don't agree that it's universal. I personally find Rust more ergonomic than those languages (in addition to be being safer).
timeon 1y ago
How are chairs related to programming languages? Analogies are just made-up arguments.
- mattwilsonn888 1y ago
  Because a primary function of the chair is the same to programming languages: ergonomics. That is obviously true, otherwise we'd code in assembly and type in UTF-8 byte codes.
dayvster 1y ago
> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. It's true when you ride a skateboard with a helmet on, it's true when you program, it's true for sex. Well put! And this should not be contentious issue, it simply is annoying to deal with Rust's very strict compiler. It's not a matter of opinion it simply is more annoying than if you were to use any other language that does not put that much burden on you the developer. Not all memory safety bugs are critical issues either. We like to pretend like they are but specifically in `coreutils` there were 2 memory safety bugs found recently. However is it really a big concern? if someone has gotten access to your system where they can run `coreutil` commands you probably have bigger problems than them running a couple of commands that leak.
- aw1621107 1y ago
  > if someone has gotten access to your system where they can run `coreutil` commands you probably have bigger problems than them running a couple of commands that leak. Speaking more abstractly since I haven't looked at the CVEs in question, but an attacker directly accessing coreutils on your system isn't the only possible attack vector. Another potentially interesting one would be them expecting you to run coreutils on something under they control. For example, a hypothetical exploit in grep might be exploitable by getting you to grep through a repo with a malicious file. A more concrete example would be some of the various zero-click iMessage exploits, where the vulnerable software isn't exploited via the attackers directly accessing the victim's device but is exploited by sending a malicious file.
charcircuit 1y ago
>Safety is less ergonomic. It's not safety that makes it less ergonomic, it's correctness.
- mattwilsonn888 1y ago
  Implying that correctness necessitates a lack of ergonomics is deeply flawed. The distinction between correctness and safety is that safety is willing to suffer false positives, in pursuit of correctness. Correctness is just correctness.
  - charcircuit 1y ago
    It's not flawed. Ergonomics are correlated with complexity. If you can remove edge cases by giving up on correctness you can remove complexity.
rstuart4133 1y ago
> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. That can be true for small programs. Not always, because Rust's type system makes for programs that can be every bit as compact as Python if the algorithm doesn't interact badly with the borrow checker. Or even if it does. For example this tutorial converts a fairly nary C program to Rust: https://cliffle.com/p/dangerust/ https://cliffle.com/p/dangerust/ The C was 234 lines, the finished memory safe Rust 198 lines. But when it comes to large programs, the ergonomics strangely tips into reverse. By "strangely tips into reverse", I mean yes it takes more tokens and thinking to produce a working Rust program, but overall it saves time. Here a "large program" means a programmer can't fit it all in his head at one time. I think Andrew Huang summed the effect up best, when he said if you start pulling on a thread in a Rust program, you always get to the end. In other languages, you often just make the knot tighter.
bionhoward 1y ago
Rust feels easy for me, could it be we’re just used to what we use more? Anyway, it’s all pretty easy, what’s the use arguing which of multiple easy things is easiest?
junon 1y ago
Writing rust fulltime for my personal projects, I have to disagree that Rust isn't ergonomic. In fact, I find it more ergonomic than any other language I ever work with. I'm consistently more productive with it than even scripting languages. Getting tired of this quip being asserted as fact. Ergonomics are subjective; memory safety is not.
- player1234 1y ago
  [dead]
  - junon 1y ago
    How did you measure the assertion that Rust is not ergonomic? Please share your results and methodology.
spoiler 1y ago
I find Rust more ergonomic than something like C or C++, or even Go. I feel unburdened while using Rust, which is not something I can say about a lot of other dev environments. As for Zig... I tried to get into it, and I can't remember the specifics, but they felt like "poor" taste in language design (I have a similar opinion of Go). I say taste because I think some thighs weren't necessarily bad, but I just couldn't convince myself to like them. I realise this is a very minority opinion, and I know great engineers who love Zig. Zig's just not my thing I guess. Same way Rust isn't someone else's thing.

jasonpeacock 1y ago

> produce memory safe software with a bit of discipline "a bit of discipline" is doing a lot of work here. "Just don't write (memory) bugs!" hasn't produced (memory) safe C, and they've been trying for 50yrs. The best practices have been to bolt on analyzers and strict "best practice" standards to enforce what should be part of the language. You're either writing in Rust, or you're writing in something else + using extra tools to try and achieve the same result as Rust.

tptacek 1y ago
I actively dislike Zig's memory safety story, but this isn't a real argument until you can start showing real vulnerabilities --- not models --- that exploit the gap in rigor between the two languages. Both Zig and Rust are a step function in safety past C; it is not a given that Rust is that from Zig, or that that next step matters in practice the way the one from C does.
- dadrian 1y ago
  I like Zig, although the Bun Github tracker is full of segfaults in Zig that are presumably quite exploitable. Unclear what to draw from this, though. [1]: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
  - vanderZwan 1y ago
    Wasn't Bun the project where the creator once tweeted something along the lines of "if you're not willing to work 50+ hours a week don't bother applying to my team"? Because if so then I'm not surprised and also don't think Zig is really to blame for that.
    - dadrian 1y ago
      Not clear to me there's a correlation between hours worked and number of memory safety vulnerabilities
      - blacksmith_tb 1y ago
        I think the implication is something like "overwork / fraying morale from long hours means shipping more bugs".
        tptacek 1y ago
        The point of memory-safe languages is to foreclose on a set of particularly nasty bugs, regardless of how frayed engineer morale is.
        vanderZwan 1y ago
        I'm pretty sure that in an overworked environment the engineers would reach for Rust's unsafe mode pretty quickly because they're too tired to make sense of the borrow checker.
fpoling 1y ago
As Rust Zig has type-safe enums/sum types. That alone eliminates a lot of problems with C. Plus sane error handling with good defaults that are better than Rust also contributes to code with less bugs. Surely there is no borrow checker, but a lot of memory-safety issues with C and C++ comes from lack of good containers with sane interfaces (std::* in C++ is just bad from memory safety point of view). If C++ gained the proper sum types, error handling and templates in Zig style 15 years ago and not the insanity that is in modern C++ Rust may not exist or be much more niche at this point.
- TuxSH 1y ago
  > If C++ gained the proper sum types AFAIK "P2688 R5 Pattern Matching: match Expression" exists and is due C++29 (what actually matters is when it's accepted and implemented by compilers anyway) Also, cheap bound checks (in Rust) are contingent to Rust's aliasing model.
- whatevaa 1y ago
  Buffer overruns are most common memory related RCE's. So bounds checking arrays/strings BY DEFAULT is needed.
rixed 1y ago
> "Just don't write (memory) bugs!" hasn't produced (memory) safe C Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Sure, it's easier to write a robust program in almost every other language. But to state that nobody ever produced a memory safe C program is just wrong. Maybe it was just rethoric for you, but I'm afraid some may read that and think it's a well established fact.
- zanellato19 1y ago
  >Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Can you provide examples for it? Because it honestly doesn't seem like it has ever been done.
  - dayvster 1y ago
    [flagged]
    - hannofcart 1y ago
      Haven't written C in a while but I think this program has an integer overflow error when you input 2 really large integers such that the sum is more than a 32 bit signed integer. Also I believe in entering null values will lead to undefined behaviour.
      - dayvster 1y ago
        har har... have my upvote!
      - Karrot_Kream 1y ago
        Memory safe doesn't mean protection from integer overflow unless you use that integer to index into some array. I'm not sure how you'd enter NULL given scanf.

anon-3988 1y ago

I would argue that good C or C++ code is actually just Rust code with extra steps. So in this sense, Rust gets you to the "desired result" much easier compared to using C or C++ because no one is there to enforce anything and make you do it. You can argue that using C or C++ can get you to 80% of the way but most people don't actively think "okay, how do I REALLY mess up this program?" and fix all the various invariant that they forgot to handle. Even worse, this issue is endemic in higher level dynamic languages like Python too. Most people most of the time only think about the happy path.

vanderZwan 1y ago
What does that have to do with Zig though?
wolvesechoes 1y ago
There are valid and safe programs rejected by Rust compiler if you don't go through rituals required to please it (slaping Rc, Refcells etc). No amount of "oh your Rust code is actually something you would ended up with if you would choose C" will change that.
- simonask 1y ago
  You know, the `unsafe` keyword exists. You’re allowed to use it. If your algorithm is truly safe, and as you say, there are many safe things the borrow checker cannot verify, that’s exactly what `unsafe` is for. Ideally you can also design a safe API around it using the appropriate language primitives to model the abstraction, but there’s no requirement.
- crote 1y ago
  Of course. After all, it is mathematically impossible to prove the correctness of all valid and safe programs - the halting problem clearly shows that. The real question should not be "Are there valid and safe programs Rust will reject?" but "How common is it that your well-written valid and safe program will be rejected by the Rust compiler?". In practice the vast majority will be accepted, and what remains is stuff the Rust compiler cannot prove to be correct. If Rust doesn't like your code, there are two solutions. The first is to go through the rituals to rewrite it as provably-safe code - which can indeed feel a bit tedious if your code was designed using principles which don't map well to Rust. The second is to use `unsafe` blocks - but that means proving its safety is up to the programmer. But as we've historically seen with C and unsafe-heavy Rust code bases, programmers are horrible at proving safety, so your mileage may vary. I don't want to be the "you're holding it wrong" person, but "Rust rejected my valid and safe program" more often than not means "there's a subtle bug in my program I am not aware of yet". The Rust borrow checker has matured a lot since its initial release, and it doesn't have any trouble handling the low-hanging fruit anymore. What's left is mainly complex and hard-to-reason-about stuff, and that's exactly the kind of code humans struggle with as well.

weinzierl 1y ago

"It's true when you ride a skateboard with a helmet on." Rust is not the helmet. It is not a safety net that only gives you a benefit in rare catastrophic events. Rust is your lane assist. It relieves you from the burden of constant vigilance. A C or C++ programmer that doesn't feel relief when writing Rust has never acquired the mindset that is required to produce safe, secure and reliable code.

nsagent 1y ago
I don't think this is any better of an argument. Maybe yours is a more apt analogy, but as a very competent driver I can't tell you how often lane assist has driven me crazy. If I could simply rely on it in all situations, then it would be fine. It's the death of a thousand cuts each and every time it behaves less than ideally that gets to me and I've had to turn it off in every single car a I've driven that has it.
omnicognate 1y ago
Public Safety Announcement: Lane assist does not relieve you from the burden of constant vigilance.
travisgriggs 1y ago
> Rust is your lane assist. It relieves you from the burden of constant vigilance. Interesting analogy. I love lane assist. When I love it. And hate it when it gets in the way. It can actively jerk the car in weird and surprising ways when presented with things it doesn’t cope well with. So I manage when it’s active very proactively. Rust of course has unsafe… but… to keep the analogy, that would be like driving in a peer group where everyone was always asking me if I had my lane assist on, where when I arrived at a destination, I was badgered with “did you do the whole drive with lane assist?” And if I didn’t, I’d have explained to me the routes and techniques I could have used to arrive at my destination using used lane assist the whole way. Disclaimer, I have only dabbled a little with rust. It is the religion behind and around it that I struggle with, not the borrow checker.
- danudey 1y ago

SoraNoTenshi 1y ago

It also drives me insane when i dump the problems i have with Rust about this exact issue, that i usually have to restructure my code to satisfy the compilers needs, and they come at me with the "Skill Issue" club... I honestly don't even know what to respond to that, but it's kind of weird to me to honestly think that you'd need essentially a "PhD" in order to use a tool...

mattwilsonn888 1y ago
It's an amazing piece of marketing to corner anyone who dislikes a certain hassle as being mentally deficient - that's what "skill issue" means in this context.
- shakow 1y ago
  > that's what "skill issue" means in this context. “Skill issue” definitely does not means “mentally deficient”. It comes from the videogames world, where it is used to disparage the lack of training/natural ability of other players; frequently accompanied by “get good”, i.e. continue training & grinding to up your skill.
  - mattwilsonn888 1y ago
    Do I have to put the pieces together for you? What is the relevant skill in programming? Problem solving. It's not aim or timing or hand-eye coordination lmao.
    - vrmiguel 1y ago
      Not sure I get your point. One can definitely "get good" at problem solving. Isn't that the whole purpose of Leetcode and whatnot? I struggled with Rust at first but now it feels quite natural, and is the language I use at work and for my open-source work. I was not "mentally deficient" when I struggled with Rust (at least that I know of :v), while you could say I had a skill issue with the language
1y ago

pjmlp 1y ago

As I mention elsewhere, C crowd didn't call languages like Pascal and Modula-2 programming with straightjacket for no reason. Turns out not wearing that helmet, and continously falling down for 40 years at the skate park has its price.

aw1621107 1y ago

> it's a universal tradeoff, that is: Safety is less ergonomic. I'm not sure that that tradeoff is quite so universal. GC'd languages (or even GC'd implementations like Fil-C) are equally or even more memory-safe than Rust but aren't necessarily any less ergonomic. If anything, it's not an uncommon position that GC'd languages are more ergonomic since they don't forbid some useful patterns that are difficult or impossible to express in safe Rust.

SkiFire13 1y ago
The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one.
- quotemstr 1y ago
  > The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one. That's a myth that just won't die. How is it that people simultaneously believe 1) GC makes a language slow, and 2) Go is fast? Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only with manual memory management.
  - rixed 1y ago
    > How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast? Easy one: either not the same people, or people holding self contradicting thoughts. GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower. Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace of mind.
    - quotemstr 1y ago
      > also because of the boxing Not every GC boxes primitives. Most don't.

freeopinion 1y ago

Arguing that one language is more ergonomic but can produce the same safety if you use it unergonomically is... not very useful in a context where safety is highly valued.

thinkharderdev 1y ago

> As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. I interpreted the parent to be saying that ergonomics IS (at least partly) subjective. The subjective aspect is "what you are used to". And once you get used to Rust its ergonomics are fine, something I agree with having used Rust for a few years now. > The Rust community should be upfront about this tradeoff I think they are. But more to the point, I think that safety is not really something you can reasonably "trade-off", at least not for non-toy software. And I think that because I don't really see C/C++/Zig people saying "we're trading off safety for developer productivity/performance/etc". I see them saying "we can write safe code in an unsafe language by being really careful and having a good process". Maybe they're right, but I'm skeptical based on the never-ending proliferation of memory safety issues in C/C++ code.

mattwilsonn888 1y ago
I think you are clearly good-faith. The issue is the underlying and unfair assumption that is so common in these debates: that the memory-unsafe language we're comparing against Rust is always C/C++, rather than a modern approach like Zig or Odin (which will share many arguments against C/C++). You can prove to yourself this happens by looking around this thread! The topic is Zig vs. Rust and just look at how many pro-Rust arguments mention C (including yours). It's a strong argument if we pose C as the opponent, because C can be so un-ergonomic that even Rust with its added constraints competes on that aspect. But compare it to something like Zig or Odin (which has ergonomic and safety features like passing allocators to any and all functions, bounds checking by default, sane slice semantics which preclude the need for pointer arithmetic) and the ergonomics/safety argument isn't so simple.
- ksec 1y ago
  Thank You that makes a lot of sense. I guess we will have to wait for Zig to become 1.0 first and then do a proper comparison.
- simonask 1y ago
  Zig is an immense improvement, but it’s not a production language at the time of writing. Not a lot of people feel qualified to actually compare the two. At the same time, I will argue that Zig’s improvements over C are much less substantial compared to something like Rust. It’s great, but not a paradigm shift.

nicoburns 1y ago

> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. I'd agree with that if the comparison is JavaScript or Python. If the comparison is Zig (or C or C++) then I don't agree that it's universal. I personally find Rust more ergonomic than those languages (in addition to be being safer).

timeon 1y ago

How are chairs related to programming languages? Analogies are just made-up arguments.

mattwilsonn888 1y ago
Because a primary function of the chair is the same to programming languages: ergonomics. That is obviously true, otherwise we'd code in assembly and type in UTF-8 byte codes.

dayvster 1y ago

> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. It's true when you ride a skateboard with a helmet on, it's true when you program, it's true for sex. Well put! And this should not be contentious issue, it simply is annoying to deal with Rust's very strict compiler. It's not a matter of opinion it simply is more annoying than if you were to use any other language that does not put that much burden on you the developer. Not all memory safety bugs are critical issues either. We like to pretend like they are but specifically in `coreutils` there were 2 memory safety bugs found recently. However is it really a big concern? if someone has gotten access to your system where they can run `coreutil` commands you probably have bigger problems than them running a couple of commands that leak.

aw1621107 1y ago
> if someone has gotten access to your system where they can run `coreutil` commands you probably have bigger problems than them running a couple of commands that leak. Speaking more abstractly since I haven't looked at the CVEs in question, but an attacker directly accessing coreutils on your system isn't the only possible attack vector. Another potentially interesting one would be them expecting you to run coreutils on something under they control. For example, a hypothetical exploit in grep might be exploitable by getting you to grep through a repo with a malicious file. A more concrete example would be some of the various zero-click iMessage exploits, where the vulnerable software isn't exploited via the attackers directly accessing the victim's device but is exploited by sending a malicious file.

charcircuit 1y ago

>Safety is less ergonomic. It's not safety that makes it less ergonomic, it's correctness.

mattwilsonn888 1y ago
Implying that correctness necessitates a lack of ergonomics is deeply flawed. The distinction between correctness and safety is that safety is willing to suffer false positives, in pursuit of correctness. Correctness is just correctness.
- charcircuit 1y ago
  It's not flawed. Ergonomics are correlated with complexity. If you can remove edge cases by giving up on correctness you can remove complexity.

rstuart4133 1y ago

> The Rust community should be upfront about this tradeoff - it's a universal tradeoff, that is: Safety is less ergonomic. That can be true for small programs. Not always, because Rust's type system makes for programs that can be every bit as compact as Python if the algorithm doesn't interact badly with the borrow checker. Or even if it does. For example this tutorial converts a fairly nary C program to Rust: https://cliffle.com/p/dangerust/ https://cliffle.com/p/dangerust/ The C was 234 lines, the finished memory safe Rust 198 lines. But when it comes to large programs, the ergonomics strangely tips into reverse. By "strangely tips into reverse", I mean yes it takes more tokens and thinking to produce a working Rust program, but overall it saves time. Here a "large program" means a programmer can't fit it all in his head at one time. I think Andrew Huang summed the effect up best, when he said if you start pulling on a thread in a Rust program, you always get to the end. In other languages, you often just make the knot tighter.

bionhoward 1y ago

Rust feels easy for me, could it be we’re just used to what we use more? Anyway, it’s all pretty easy, what’s the use arguing which of multiple easy things is easiest?

junon 1y ago

Writing rust fulltime for my personal projects, I have to disagree that Rust isn't ergonomic. In fact, I find it more ergonomic than any other language I ever work with. I'm consistently more productive with it than even scripting languages. Getting tired of this quip being asserted as fact. Ergonomics are subjective; memory safety is not.

player1234 1y ago
[dead]
- junon 1y ago
  How did you measure the assertion that Rust is not ergonomic? Please share your results and methodology.

spoiler 1y ago

I find Rust more ergonomic than something like C or C++, or even Go. I feel unburdened while using Rust, which is not something I can say about a lot of other dev environments. As for Zig... I tried to get into it, and I can't remember the specifics, but they felt like "poor" taste in language design (I have a similar opinion of Go). I say taste because I think some thighs weren't necessarily bad, but I just couldn't convince myself to like them. I realise this is a very minority opinion, and I know great engineers who love Zig. Zig's just not my thing I guess. Same way Rust isn't someone else's thing.