“What Java said.”
Okay, that one made me chuckle.
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)
I am
static_casting thenut_t*. Pray I don’tstatic_castit any further.reinterpret_cast<int*>(&a_nut)
I like to live dangerously.
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 then still segfault
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.
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.
If you can make safe Rust segfault you’re doing something wrong.
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?
To be fair, you are doing something wrong if you’re app segfaults no matter what anguage you wrote it in…
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.
Despite that, some languages make it easier to be wrong than others.
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.
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
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.
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
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.
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.
Amen. But they have to, because that’s where they spend most of their cognitive focus, and it’s Rust’s “killer feature.”
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.
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.
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!
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.
It won’t segfault but it’ll absolutely panic over an unwrap at some point.
And hot take, but that’s good. I’m absolutely stupid enough for idiot gloves like that.
I just dabbled in javascript again, and that description is spot on!
console.log(‘javascript operators are b’ + ‘a’ + + ‘a’ + ‘a’);
I can‘t believe you’ve done this
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.
BaNaNa
Terracotta
Pepperoni and green peppers, mushrooms, olives, chives!
Oh wait wrong song.
But… It’s a legume?!
Which tracks perfectly with the meme if you read it again
In Java, it’s not called the
Crackableinterface.It’s the
Nuttableinterface.Provided your method specifies a strongly bound type you can ensure that you get your nut.
void dischargeNut(T extends Nut) { ... }strongly bound you say?
Actually it’s
AbstractNutAndShellsFactoryHow do I know if something is
Nuttable?
Excel: 12th of Nutuary 1970
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?”
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”
wheres scala?
It’s incompatible with the version of this meme
Ce n’est pas une cacahuète
Ruby: No, it has been redefined as the number 5 so buckle your seatbelts, kiddos, cuz shit’s about to get wild!
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.
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
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.
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
deleted by creator
C can STRUCTurise classes thoYeah, 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
But, why?
most C programs are just C++ programs with extra steps if you look at them close enough
I want my vs code to look like this
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
