this post was submitted on 14 Mar 2024
71 points (100.0% liked)
Programmer Humor
22729 readers
1665 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.
The world isn't clamoring to turn a go app into rust specifically for the memory safety they both enjoy.
Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.
Go, Java, and Nim (in most cases) are all memory safe but are generally slower than C or C++ due to the ways they achieve memory safety.
Rust's memory safety approach is zero-cost performance wise, which makes it practical for low level, high throughput, and low latency applications.
Everything is slower than C (I haven't seen a benchmark yet where a language bests C; even hand-crafted ASM ceded the high ground decades ago when compilers got better than human assembly programmers), but then, C compiler technology has had literally 40+ years to mature.
Go and Java (once warm) do pretty well, but absolutely give up execution speed for coding simplicity and (in Go's case, anyway) speed. Nim is young; I'm curious to see how it matures. They're having a bit of a performance crisis at the moment, but assuming they get past that it seems like a fair middle ground between Go's simplicity and Rust's bare-metal performance. Then again, manual memory management was absolutely my least favorite thing about C and is what eventually drove me away; worst. Boilerplate. Ever. Even worse than Go's error handling (which they almost fixed and looks like will be addressed within the next free releases). Anyhoo, going back to that shit is going to be a hard pill to swallow.
Rust is still having its honeymoon, and is the hip language of the decade now. We'll see!
Rust is roughly similar to C in most of these benchmarks and beats it in a few: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
Arguably when LLVM gets a bit better, Rust can be even faster than C because rust can be optimised in more places safely than C code can. The issue is that LLVM wasn't written with that in mind, so some performance is left on the table.
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.
Rust programmers vastly overestimate how many bugs are caused by memory problems
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.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.
Edit: Responses here have convinced me not to give Rust another shot. Reeks of the Java community. If that's what's happening here, the Java devs can have this one to themselves. They'll probably fill it with XML again. I didn't want to like Rust anyway. And everyone needs to get off my lawn.
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.
Edit: I no longer want Rust to replace Python. Y'all got a problem presenting yourselves, kids. It's going to hurt your language adoption rate.
Edit 2: And get off my lawn!
You're the only person I've ever heard this from. Rust's compiler warnings are amazing. Like 2nd to none
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.
Edit: The responses here are quite revealing. I'm not seeing any of my usability mentors in the Rust diehard fan mix.
None of this has convinced me to give Rust another go. Its community, did not present well here.
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.