Rust is more like: unless you can mathematically prove to me that this is equivalent to a nut there is no ducking way I’ll ever let you compiled this.
And hot take, but that’s good. I’m absolutely stupid enough for idiot gloves like that.
And then still segfault
https://github.com/Speykious/cve-rs/blob/main/src/segfault.rs
If you can make safe Rust segfault you’re doing something wrong.
To be fair, you are doing something wrong if you’re app segfaults no matter what anguage you wrote it in…
Despite that, some languages make it easier to be wrong than others.
I don’t think so, since memory safe languages are supposed to prevent you from doing that, so it would be the language implementation’s fault.
It actually is possible to segfault in safe Rust, although it is considered a bug. Proofs of concept are shown in this cve-rs crate.
If you want an explanation of why this happens, I recommend this video: https://youtu.be/vfMpIsJwpjU
So you can’t get a Rust program to segfault without trying really hard. I haven’t observed a single segfault in the normal Rust code I wrote in the past 8 years.
The code used in cve-rs is not that complicated, and it’s not out of the realm of possibility that somebody would use lifetimes like this if they had just enough knowledge to be dangerous.
I’m as much a rust evangelist as the next guy, but part of having excellent guard rails is loudly pointing out subtle breakages that can cause hard to diagnose issues.
If that’s so trivial to trigger, people would be doing so everywhere. Have you seen it in the wild or heard of anyone doing so?
If someone did, why would I hear of it?
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!
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 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?
Rust programmers vastly overestimate how many bugs are caused by memory problems
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.
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.
Amen. But they have to, because that’s where they spend most of their cognitive focus, and it’s Rust’s “killer feature.”
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
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.
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.
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.
And I’m sorry to hear about that Ruby experience. I authored one of the Ruby stdlibs, and similar issues with the language, and the inevitable encroachment of Rails into every project, eventually drove me away from it.
I was, however, excluding interpreted languages from my comparison. Dynamically typed languages are a different matter and can’t hope to be any kind of safe - but that’s not the game where they excel.
Have you really used Rust or are you spreading FUD? I have not managed to cause even a single segfault in my 8 years of writing Rust code. Nor have I heard anyone else complaining about it, other than deliberately as proof of concept.
Refering to cve-rs but only one commenter got it
It won’t segfault but it’ll absolutely panic over an unwrap at some point.
Why are you getting downwoted man, getting segfaults in safe rust is on compiler not us. When you segfault in C and such it’s almost always your fault, if you manage to do that in rust it’s a bug in compiler.
Because the rust crowd spent a lot of time learning rust, and they’ll be damned if it isn’t the literal savior catch all silver bullet solution to programming.
StackOverflow: Question closed as duplicate. Someone else already asked whether or not something is a nut.
“Question closed as duplicate”
The question it’s a duplicate of: “How to programmatically prove a hotdog is a sandwich?”
Seriously, i just googled how much energy would be needed to put 1Kg in LEO. Ofc there’s a StakOverflow to it asking the same question and none of 4 answers answer the question and one is like “This seems like a complicated way of doing it. Instead of asking the minimum energy…”.
1 answer: use the fucking search
First search result brings you to this answer.
“It’s 2024! Why are people still trying to classify nuts? Just use some expensive cloud solution that doesn’t really solve your problem”
Java: “Sorry, but the developers of
Peanutdidn’t declare it to implement theCrackableinterface, even though it has all the relevant methods, so if you want to treat it like a nut your choices are write a wrapper class or call those methods using Reflections”Swift’s extensions system has spoiled me, and I feel the pain of this whenever I have to write Java
You should take a look at kotlin, pretty similar to swift and fully interoperable with java.
Ditto, but Rust’s traits. God those are so fun. It’s like duck typing a la Python but you can just slap whatever methods you want on a foreign type without worrying about breaking anything because they’re only visible to the current crate (or other crates that import the Trait)
C# should actually be “What Java said, except it’s
ICrackable”.No, actually C#'s answer should be: “What Java said - hold on, what Python said sounds good too, and C++'s stuff is pretty cool too - let’s go with all of the above.”
C#, or as I like to call it “the Borg of programming languages”.
I got my first software developer role last year and it was the first time I’d written C#, I was more TypeScript. Now we use both but I must say I really like C# now that I’m used to it.
I think most programmers would like C# if they spent time with it. It is getting a bit complex because the joke about it over borrowing from other languages is on the money. It is a nice language though and pretty damn fast these days all things considered.
There’s too much MS in the language and runtime for me. The fact that it gives my Linux programs DLL files and the fact that by default the SDK phones home makes me run away in horror from not only writing it but also running other projects written in it.
even nicer is F#. join us brother, you can do everything that you can do in C# but better
What does it offer that would make it better? Just curious and I’m not in a position to change out tech stack at work though.
Removed by mod
Would the equivalent Rust trait be
Crack?AsCrackInto<dyn AsCrack>Into’s type parameter has an implicitSizedbound. I thinkAsRef<dyn Crack>would be the trait of choice :D
pervert
In Java, it’s not called the
Crackableinterface.It’s the
Nuttableinterface.Actually it’s
AbstractNutAndShellsFactoryProvided your method specifies a strongly bound type you can ensure that you get your nut.
void dischargeNut(T extends Nut) { ... }strongly bound you say?
How do I know if something is
Nuttable?
I am
static_casting thenut_t*. Pray I don’tstatic_castit any further.reinterpret_cast<int*>(&a_nut)
I like to live dangerously.
Ruby: No, it has been redefined as the number 5 so buckle your seatbelts, kiddos, cuz shit’s about to get wild!
C can STRUCTurise classes thoI want my vs code to look like this
Yeah, you can technically write object oriented code in C. Or any other language. Just that actual OOP languages provide a nicer syntax and compile time checks.
Rust is kind of a good example of this. It’s technically not an object oriented language, but the trait system brings it close.
Time for Rust++
Stop this or I’m gonna find you and I’m gonna kill your dog
Whoa now, them there fighting words.
Ah yes, what C needs is VTABLEs.
But, why?
most C programs are just C++ programs with extra steps if you look at them close enough
“What Java said.”
Okay, that one made me chuckle.
All those memes picturing C++ as unsafe and unstable yet the server that serves these memes is running mostly C/C++ and has an uptime of months.
Lemmy is written in Rust. There might be bits of C at the periphery behind bindings.
And linux is written in C.
Predominantly C. But even the kernel is beginning to use Rust as a way of avoiding entire classes of programming error.
well and it’s only running this well because of decades of effort and millions of effort spent on security reviews
They implemented some sort of OOP tho.
edit: I meant: the Linux devs implemented some sort of OOP in their C code in the kernel – is something i read forever ago.
Rust isn’t really OOP like C#, Java or C++ - it has structs with functions that you could consider an “object” but there is no inheritance. Instead Rust uses traits which are a little bit like interfaces in some languages.
The way the kernel is using Rust at the moment is to produce safe bindings for modules to be written in Rust, i.e. you can create a module in Rust source which will be correctly loaded up, the code is safe by default and will have access to kernel services via bindings. I expect over time that more of the kernel will become Rust, but the biggest impediment right now is Rust relies on LLVM and LLVM only supports a subset of targets that a kernel could potentially support with another compiler like gcc.
Lemmy is written in Rust.
Wow, way to ruin my joke.
True, but that’s partly because the Linux is beyond mature, and you can ferret out a lot of bugs with millions of users over decades.
Also they’re always treating C++ like it’s some arcane enterprise variant that uses 1990s C++
Using modern C++ you can write much cleaner, more usable, and really safe code
Having a thorough process and an engineer approach in software development is also pretty handy. There weren’t many bugs in the AGC. Yet it was programmed mostly in assembly and people had no trouble trusting it with their life.
yet the server that serves these memes is running mostly C/C++
Time to rewrite it in Rust!
/ducksandruns
if i remember lemmy is written in rust
Lemmy is rust and it’s alternative sublinks is java…your comment has now power here
Excel: 12th of Nutuary 1970
C++: Nuh, uh …
template <typename T> concept Crackable = requires(T obj) { { obj.crack() }; }; auto crack(Crackable auto& nut) { nut.crack(); }This is dangerous. The object might not have the crack() method, and this bloats the compiled size by a lot if you use it with different types. There’s also no reason I can see to use concepts here. The saner way would probably be to use inheritance and objects to mimic Java interfaces.
This is dangerous
Well, they say you do have to be over 18 to use Concepts
I just dabbled in javascript again, and that description is spot on!
console.log(‘javascript operators are b’ + ‘a’ + + ‘a’ + ‘a’);
BaNaNa
Terracotta
Pepperoni and green peppers, mushrooms, olives, chives!
Oh wait wrong song.
The only reason people use JS is because it’s the defacto language of browsers. As a language it’s dogshit filled with all kinds of unpleasant traps.
Here is a fun one I discovered the other day:
new Date('2022-10-9').toUTCString() === 'Sat, 08 Oct 2022 23:00:00 GMT' new Date('2022-10-09').toUTCString() === 'Sun, 09 Oct 2022 00:00:00 GMT'So padding a day of the month with a 0 or not changes the result by 1 hour. Every browser does the same so I assume this is a legacy thing. It’s supposed to be padded but any sane language would throw an exception if it was malformed. Not JavaScript.
I can‘t believe you’ve done this
Well, not by accident.
Ce n’est pas une cacahuète
But… It’s a legume?!
Which tracks perfectly with the meme if you read it again
