That’s misinformation. There’s no overestimation. The problem is so bad that even the US government advocates the use of memory safe languages (including GC languages).
I have used C and C++. You need laser sharp focus to avoid memory safety errors even after you learn what causes them and how to avoid them. It’s significantly easier to write programs in Rust because any lapse in care to avoid memory safety bugs are caught by the compiler.
What I mean is that even if you use GC languages like Java or Go you will still encounter annoying bugs. I’m not saying that memory safety isn’t important.
You said bugs caused by ‘memory problems’. And that Rust programmers vastly overestimate them. Those aren’t generic logical bugs that you get in Go or Java. And Rust never claimed to solve logical bugs.
Yeah. The verdict is still out on whether having a deeply surly compiler will help me focus on iterating and understanding the client’s needs.
I run Python CICD controls on main with at least the same level of prissiness (as Rust comes with), but at least Python knows how to shut up and let me prototype.
I’m currently not convinced that Rust’s opinionated design hits a useable long term sweet spot.
But I think if Rust adds a debug flag --fuck-off-i-need-to-try-something, it could genuinely become the next Python, and the world would be better for it.
Edit: And if I just missed the --fuck-off-i-need-to-try-something Rust flag, someone point me at it, and I’ll gladly give Rust another run.
That flag exists, it’s called unsafe for if you need to tell the borrow checker to trust you or unwrap if you don’t want to deal with handling errors on most ADTs.
You can always cast anything to an unmanaged pointer type and use it in unsafe code.
Yeah. Which is how I roll with Python now, as a Python Zen master. But Python was a little charmer when I was learning it to replace my Perl scripts.
In contrast, Rust would not shut up the last time I was trying to do an unsafe local bubble sort, just to get to know it. What I got to know was that I was working with a language that was going to go out of it’s way to get in my, each time way I wanted to do something it didn’t like.
Rust was easily the worst first date with a programming language I have had in a long time, and I can code in both varieties of ‘Pikachu’.
Again, it’s just my first impression, not the last word on the language. But I have enough tools in my belt that I didn’t need to add Rust.
I’ll try that ‘unsafe’ flag next time, and we will see if it can sort my local music files by artist name without having a security fit.
Thanks. I found and tried that, but what I really needed was a useful compiler error, which Rust did not provide.
Rust desperately needed a usability makeover, last time I tried it.
It amuses me that my fellow security gurus push Rust hard, because we sit in the same policy-pushers conferences as the usability specialists, but we don’t always learn enough from them.
You’re missing the point. Tools are different. Trying to learn and use rust by writing unsafe bubble sort is pointless. Use it to actually accomplish something and you’ll find out just how amazing it is.
Using the ecosystem that exists to be productive and not have to think at all about whether what you’re doing is correct is the point. It catches the subtle errors for you and lets you use the powerful libraries like clap for command line parsing, tokio, etc.
I wasn’t being that picky, and I was using the ecosystem. Rust just has lousy compiler warnings.
I know dozens of languages, so I don’t mind risking looking dumb when I say “this tool isn’t very good yet”.
Rust’s compiler, considering what it asks for, isn’t good enough at guiding the developer toward those asks. It actively wastes the one crucial low-supply computing resource: developer time.
I could have figured it out, if I had to. But I didn’t have to. I moved on to the next interesting language to try out. It was goLang, and it had isn’t own bullshit, but it wasn’t as bad as Rust.
I’ve written in Haskell and Brainfuck. I don’t mind esoteric languages.
But Rust presents itself as a solid general purpose pragmatic development tool, which is great to strive for, but it wasn’t there yet, last time I gave it a chance.
I want Rust to succeed in replacing Python, because the world would be better off with better security defaults. But Rust had not, last I checked, attracted the necessary usability specialist contributors, to have any chance at that goal.
I’m sorry to hear that. I think at one point in my past, about half my job was tracking down nil dereference errors in Ruby. And probably a quarter was writing tests for things a good type system would catch at compile time.
I don’t know if you’re talking about panics and abort or about crashes caused by memory safety errors. The latter class is very unlikely in safe rust, other than as rare compiler bugs. Panics and aborts are your call. You can easily write code that doesn’t panic or abort.
As a user. I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in. I almost never seesegfaults; I can’t say I’ve ever seen one in a Go program, and I use a bunch on those.
If we’re only talking about segfaults, the only language I can remember seeing doing that has been C, or C++. If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust. If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.
This is definitely into the territory of misinformation.
I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in
I already addressed this before. Regular crashes are almost always (I can’t remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs’ stability to ‘any other compiled language tools I use are written in’ is very disingenuous - because it’s just as easy to handle those errors and prevent a crash at all.
If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust
You are unnecessarily conflating issues here. ‘Most modern languages’ are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their ‘systems programming language’ tag, for example. If a GC language meets your requirements - then by all means, use it. But it’s not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It’s not something to dismiss as trivial.
And while at it, you neglecting what segfaults represent. It’s just a benign example of memory safety bug. It’s benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.
If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.
I really don’t want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as ‘any other prolang’ is to neglect idiomatic Rust. That isn’t surprising because crashing anything is possible if that’s your intention.
I think you’re missing the point where I said I don’t write Rust. I’m merely making an observation - as a user who’s more than usual, probably, aware of which language any given tool is written in, of what I observe.
I know I’ve seen a Rust program segfault, and I’m certain that I saw this only once. I’m equally confident that almost every other segfault has been from C/C++ code, but not other languages.
What I’m hearing you say is that crashes aren’t a risk, per se, as long as they aren’t memory related and so the crashes I see from Rust programs don’t count because they aren’t segmentation faults. Did I read that right? And I also hear you claiming that, e.g., NPEs are security issues, even if the runtime catches them and safely exits the program in a controlled manner (“crashing out” safely) - is that right?
Sure. I haven’t seen a proper segfault from any modern, post-C/C++ language in ages. I’ve never seen a Go program segfault, or a Nim one (although, there are comparatively few of those as a sample size).
So, it seems to me that - purely from the perspective of a user of programs - Rust still seems about as safe as any other modern language - since I’ve seen no other modern (say, created in the past decade) compiled language segfault. Even the C segfaults seem to be largely becoming rare occurrences, which I have to chalk up to better tooling, because I highly doubt that there’s been some magical increase in general C programmer quality in the intervening years.
IME Rust programs crash at about the same rate as other languages. “Rewrite everything in Rust” hasn’t made much of a difference for me, so far.
Rust programmers vastly overestimate how many bugs are caused by memory problems
Amen. But they have to, because that’s where they spend most of their cognitive focus, and it’s Rust’s “killer feature.”
I don’t know, I’ve caused a whole lot in C/C++. I haven’t actually written anything in Rust either, so I’m somewhat unbiased.
That’s misinformation. There’s no overestimation. The problem is so bad that even the US government advocates the use of memory safe languages (including GC languages).
I have used C and C++. You need laser sharp focus to avoid memory safety errors even after you learn what causes them and how to avoid them. It’s significantly easier to write programs in Rust because any lapse in care to avoid memory safety bugs are caught by the compiler.
What I mean is that even if you use GC languages like Java or Go you will still encounter annoying bugs. I’m not saying that memory safety isn’t important.
You said bugs caused by ‘memory problems’. And that Rust programmers vastly overestimate them. Those aren’t generic logical bugs that you get in Go or Java. And Rust never claimed to solve logical bugs.
Yeah. The verdict is still out on whether having a deeply surly compiler will help me focus on iterating and understanding the client’s needs.
I run Python CICD controls on main with at least the same level of prissiness (as Rust comes with), but at least Python knows how to shut up and let me prototype.
I’m currently not convinced that Rust’s opinionated design hits a useable long term sweet spot.
But I think if Rust adds a debug flag
--fuck-off-i-need-to-try-something, it could genuinely become the next Python, and the world would be better for it.Edit: And if I just missed the
--fuck-off-i-need-to-try-somethingRust flag, someone point me at it, and I’ll gladly give Rust another run.That flag exists, it’s called
unsafefor if you need to tell the borrow checker to trust you orunwrapif you don’t want to deal with handling errors on most ADTs.You can always cast anything to an unmanaged pointer type and use it in unsafe code.
Thank you. I’ll check it out next time.
Once you get the hang of rust you don’t ever need to ask it to do unsafe things. It’s not really any faster to do things unsafe
Yeah. Which is how I roll with Python now, as a Python Zen master. But Python was a little charmer when I was learning it to replace my Perl scripts.
In contrast, Rust would not shut up the last time I was trying to do an unsafe local bubble sort, just to get to know it. What I got to know was that I was working with a language that was going to go out of it’s way to get in my, each time way I wanted to do something it didn’t like.
Rust was easily the worst first date with a programming language I have had in a long time, and I can code in both varieties of ‘Pikachu’.
Again, it’s just my first impression, not the last word on the language. But I have enough tools in my belt that I didn’t need to add Rust.
I’ll try that ‘unsafe’ flag next time, and we will see if it can sort my local music files by artist name without having a security fit.
https://doc.rust-lang.org/std/primitive.slice.html#method.sort_unstable
Thanks. I found and tried that, but what I really needed was a useful compiler error, which Rust did not provide.
Rust desperately needed a usability makeover, last time I tried it.
It amuses me that my fellow security gurus push Rust hard, because we sit in the same policy-pushers conferences as the usability specialists, but we don’t always learn enough from them.
You’re missing the point. Tools are different. Trying to learn and use rust by writing unsafe bubble sort is pointless. Use it to actually accomplish something and you’ll find out just how amazing it is.
Using the ecosystem that exists to be productive and not have to think at all about whether what you’re doing is correct is the point. It catches the subtle errors for you and lets you use the powerful libraries like clap for command line parsing, tokio, etc.
I wasn’t being that picky, and I was using the ecosystem. Rust just has lousy compiler warnings.
I know dozens of languages, so I don’t mind risking looking dumb when I say “this tool isn’t very good yet”.
Rust’s compiler, considering what it asks for, isn’t good enough at guiding the developer toward those asks. It actively wastes the one crucial low-supply computing resource: developer time.
I could have figured it out, if I had to. But I didn’t have to. I moved on to the next interesting language to try out. It was goLang, and it had isn’t own bullshit, but it wasn’t as bad as Rust.
I’ve written in Haskell and Brainfuck. I don’t mind esoteric languages.
But Rust presents itself as a solid general purpose pragmatic development tool, which is great to strive for, but it wasn’t there yet, last time I gave it a chance.
I want Rust to succeed in replacing Python, because the world would be better off with better security defaults. But Rust had not, last I checked, attracted the necessary usability specialist contributors, to have any chance at that goal.
You’re the only person I’ve ever heard this from. Rust’s compiler warnings are amazing. Like 2nd to none
It’s very possible it’s improved since I tried it last. I’ll put it back on my list to give it another go.
I’m sorry to hear that. I think at one point in my past, about half my job was tracking down nil dereference errors in Ruby. And probably a quarter was writing tests for things a good type system would catch at compile time.
I don’t know if you’re talking about panics and abort or about crashes caused by memory safety errors. The latter class is very unlikely in safe rust, other than as rare compiler bugs. Panics and aborts are your call. You can easily write code that doesn’t panic or abort.
As a user. I don’t write Rust, but lots of programs I use do and, as I said, they seem to crash about as much as any other compiled language tools I use are written in. I almost never see segfaults; I can’t say I’ve ever seen one in a Go program, and I use a bunch on those.
If we’re only talking about segfaults, the only language I can remember seeing doing that has been C, or C++. If not doing segfaults is what makes a language “safe,” then it seems to me most modern languages are as safe as Rust. If we include crashes, then as I said, I see Rust programs crashing about as much as any other proglang.
This is definitely into the territory of misinformation.
I already addressed this before. Regular crashes are almost always (I can’t remember any exceptions) due to panics or aborts chosen by the user - especially due to unwraps. Using that to equate Rust programs’ stability to ‘any other compiled language tools I use are written in’ is very disingenuous - because it’s just as easy to handle those errors and prevent a crash at all.
You are unnecessarily conflating issues here. ‘Most modern languages’ are not a replacement for what C, C++ and Rust can do. Go most famously had to retract their ‘systems programming language’ tag, for example. If a GC language meets your requirements - then by all means, use it. But it’s not without reason that many companies have rewritten even their web backends in Rust. Memory safety without GC is a very big feature that a lot of professionals care about. It’s not something to dismiss as trivial.
And while at it, you neglecting what segfaults represent. It’s just a benign example of memory safety bug. It’s benign because it gets caught causes the program to crash. There are a whole lot of them that causes the program to continue running - causing serious vulnerabilities. This is why even the US government and agencies recommend memory safety languages and especially Rust if performance and other limitations matter.
I really don’t want to repeat the reason twice in a single comment and 3 times including in my previous comment. But the only way you are going to make Rust crash as much as ‘any other prolang’ is to neglect idiomatic Rust. That isn’t surprising because crashing anything is possible if that’s your intention.
I think you’re missing the point where I said I don’t write Rust. I’m merely making an observation - as a user who’s more than usual, probably, aware of which language any given tool is written in, of what I observe.
I know I’ve seen a Rust program segfault, and I’m certain that I saw this only once. I’m equally confident that almost every other segfault has been from C/C++ code, but not other languages.
What I’m hearing you say is that crashes aren’t a risk, per se, as long as they aren’t memory related and so the crashes I see from Rust programs don’t count because they aren’t segmentation faults. Did I read that right? And I also hear you claiming that, e.g., NPEs are security issues, even if the runtime catches them and safely exits the program in a controlled manner (“crashing out” safely) - is that right?
A crash is different to a SEGFAULT. I’d be very surprised to see a safe rust program segfault unless it was actively exploiting a compiler bug.
Sure. I haven’t seen a proper segfault from any modern, post-C/C++ language in ages. I’ve never seen a Go program segfault, or a Nim one (although, there are comparatively few of those as a sample size).
So, it seems to me that - purely from the perspective of a user of programs - Rust still seems about as safe as any other modern language - since I’ve seen no other modern (say, created in the past decade) compiled language segfault. Even the C segfaults seem to be largely becoming rare occurrences, which I have to chalk up to better tooling, because I highly doubt that there’s been some magical increase in general C programmer quality in the intervening years.