(…) rust, since js is much higher level. you should be comparing it with c, c++, zig, maybe nim, etc

Obvious troll.

I develop professionally in C and C++. No they aren’t. At all. C and C++ are so loaded with footguns it’s a surprise people can get anything done in them without triggering UB.

The way you parrot undefined behavior is a telltale sign you do not work with either C or C++. If you had any cursory first-hand professional experience with either one of those languages, you’d understand what UB is, why writing your code by laying unfounded expectations on UB is actually either a bug or design error on your behalf, you’d know that for a decade or so there are tooling that throws warnings and errors if you inadvertently use it, and above all UB only means frameworks are ultimately responsible to specify the behavior that is left purposely undefined.

If your primary exposure to programming is only typescript or JavaScript maybe you shouldn’t be jumping straight into something like rust.

That completely contradicts any claim that Rust is user-friendly and provides a decent user experience.

This is pure junior energy. Or trolling, I honestly can’t tell.

OP makes a valid point, and a strong one to boot.

Other than name calling, do you have anything to add?

You do actually understand that languages that aren’t JavaScript don’t have built in async runtimes and they need to be provided by a library, right?

How do you explain C#?

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz.

Yes, OP’s attempt to bully a maintainer into accepting his PR is a very shitty thing to do.

Throwing veiled personal attacks, such as insinuating a developer is incompetent or dumb, is also very bad form.

This says more about OP than anything. I hope I never have to work with anyone like that. What a shit show of a person.

TIL rust has some sort of ratings for libraries/dependency code.

A random guy going through the trouble of putting together a site to subjectively rate other people’s work is hardly something that’s language-specific.

I’d wager that adding a single tag/field to represent the programming language is all it takes to make the system universal.

Also, that’s not even language-specific. It’s package-centric.

I get it, joining bandwagons is fun. That’s not a substitute for thinking things through, though.

By the way, npm even supports package auditing, warnings, and autopromoting packages and its dependencies. You don’t hear people constantly parroting switching projects to Node.js over this, though.

Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety.

That’s perfectly fine. That’s not a problem caused UB, or involving UB.

Again, UB is a red herring.

It is however the language’s fault to allow UB in the first place.

It really isn’t. Again, mindlessly parroting this doesn’t give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.

Am I blaming those languages? Nah, it was a different time.

It really isn’t. It’s a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.

I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they’re talking about.

I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.

From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don’t know how this helps advocating for Rust.

Doesn’t change the overall quality of the article ?

I’m sorry, but I’m afraid the article is quite good.

It was really bad because the author in his 11y of writing Rust never once heard about the philosophy of Rust/Unsafe Rust.

You’re talking about Steve Klabnik, a guy known for being one of the authors of The Rust Programming Language and the guy who literally ran the @rustlang Twitter account.

Ive never gotten to write rust professionally, but I have always kinda winder d if it was marketed wrong. My thought was always that it should be sold as “easy” though. Its easy to write code. It’s hard(er) to make mistakes.

I agree, but I don’t think the problem is marketing. The problem is how some elements of Rust’s community desperately try to upsell the language beyond the value it actually can provide, and once that fails they fall back to toxic behavior and basically just mindlessly shitting on anything that’s not Rust. It goes well beyond a cargo cult mentality, and it’s sad that a fine technology is dragged through the mud by those who were expected to show its value.

Dangling pointers, double frees and the like, mostly.

Those are bugs you wrote in. UB is not the problem. Your code is the problem.

Tell me you haven’t run into those and I’ll laugh in your face and call you a liar.

I ran into bugs. Do you understand that UB is not the problem if you’re pushing broken code? It’s not the C++ standard that’s messing up if you’re writing in use-after-free bugs.

The irony of your comment is that some implementations take advantage of UB to prevent programs from crashing and actually continue to work in some scenarios such as use-after-free and even dereferencing null pointers. But that’s not caused by UB, is it? Those problems are caused by developers like you and me who didn’t knew what they were doing and even failed to either pay attention to the errors flagged by compiler and static code analysis tools, or even failed to onboard one.

I mean, think about it for a second. Let’s say we have a magic wand that can update any C and C++ standard version of your choosing, and we specify that each and every single instance where behavior is left undefined is updated to specify that the program should automatically crash. Awesome, no more UB. What does this mean for your code? Is it now bug-free? Is it now working well after crashing all the time due to the code you added? What role did UB played in this mess?

Do you understand this?

I repeat: detractors just parrot undefined behavior as some kind of gotcha in ways I’m not even sure they fully understand.

Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.

If you had half the experience you claim to have, you’d know that code that triggers UB is broken code by definition, and represents a bug that you introduced.

It’s not the language’s fault that you added bugs to the code. UB is a red herring.

Sure, sometimes use of undefined behaviour works (…)

You missed the whole point of what I said.

By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it’s up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.

Thus, code with UB is broken code, and if your PR relies on UB then you messed up.

Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?

Each implementation that exhibits different behavior doubles the amount of testing needed to ensure cross-platform correctness.

Not really. The whole point of undefined behavior is that the standard intentionally leaves out any definition of behavior, or the program is already fundamentally broken.

If you insist on unwittingly using code that relies on undefined behavior, you’re the one mindlessly writing broken code. It’s not the standard’s fault that you’re adding bugs.

The irony is that compiler implementations also leverage undefined behavior to save you from yourself and prevent programs to crash when they stumble upon the mess you’ve done with the code.

what is the usecase for going beyond maxint?

There are many examples of applications that leverage integer overflow, either wrapping around or saturating values.

What do you mean wrong “already”?

This is one of the problems in these discussions about undefined behavior: some people feel very strongly about topics they are entirely unfamiliar with.

According to the C++ standard, “undefined behavior may be expected when this document omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data.” Some examples of undefined behavior still lead to the correct execution of a program, but even so the rule of thumb is to interpret all instances as wrong already.

Not sure exactly what you mean, could you elaborate or rephrase?

There is nothing to rephrase. I asked what problem do you think that undefined behavior poses. That’s pretty cut-and-dry. Either you think undefined behavior poses a problem, and you can substantiate your concerns, or you don’t and talking about undefined behavior being a concern is a mute point.

It sounds like you’ve never had to do real work in a language kind C++ where the compiler is always trying to play gotcha with undefined behavior.

I have over a decade of professional experience working with C++, and it’s likely you already used software I worked on.

Throughout those years, the total number of times where undefined behavior posed a problem in any of the projects I worked on was zero.

Please enlighten me about the insurmountable challenges posed by undefined behavior.

How do you succinctly call a language that has all behavior defined or equivalently no undefined behavior (aside from designated regions)?

I don’t understand this fixation with undefined behavior. Its origins are in the design decision of leaving the door open for implementations to employ whatever optimization techniques they see fit without the specification get in the way. This is hardly a problem.

In practical terms, developers are mindful to not rely on those traits because as far as specifications go they have unpredictable implications, but even so they are never a problem. I mean, even in C and C++ it’s trivial to tweak the compiler to flag undefined behavior as warnings/errors.

Sometimes it sounds like detractors just parrot undefined behavior as some kind of gotcha in ways I’m not even sure they fully understand.

What problem do you think that undefined behavior poses?