Thread 106342449

Just look at this shit:

https://github.com/rust-lang/rust/tree/master/library/core/src/slice/sort

There is unsafe all over the place in the source code in these folders, including giant blocks of unsafe as part of implementing algorithms.

Why does Rust force developers to learn the intricacies of unsafe and bear the maintenance burden of unsafe when they want to implement common algorithms like sorting algorithms efficiently?

The Rust standard library has had at least several occurrences of undefined behavior and memory unsafety, so don't tell me that unsafe is fine. https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>106342449 (OP)
Anon, post your preferred sorting algorithm.

>>106342467
There are multiple to pick from in https://github.com/rust-lang/rust/tree/master/library/core/src/slice/sort, yet there is unsafe all over the place.

>>106342449 (OP)
Do Rust developers consider this good and idiomatic code? Giant blocks of unsafe? So much memory safety!

>>106342467
I usually implement other types of common algorithms.

I am honestly disappointed that Rust evangelists have no answer to this. Maybe there just is no answer for them.

>>106342467
does this cat have a name

>>106342741
in former yugoslavia someone smarter than you chuds once proved on a napkin that it is safe

>>106342771
>>106342831
Rust evangelists resorting to cat pictures and nonsense.

The utter state.

>>106342841
i've literally never used rust in my life and i couldn't care less about your dumb console war i just wanted to know if the cat had a name

>>106342449 (OP)
That's a state of the art sorting algorithm
https://github.com/rust-lang/rust/pull/124032

>>106342504
In the end, for all the purported benefits, it comes down to "it's ok when WE do it" and "trust the science". Just use C++ or Ada.

>>106342771
Mei Mei or Tole Tole

>>106342449 (OP)
Memory safety is a scam

>>106342952
That's how safety works in every language. Build safe abstractions around unsafe code. End users should have to write the least amount of unsafe code

>>106342952
basically this

>>106342952
C++ is just worse rust though, and ada is a bad joke.

>>106343013
Except unsafe is more difficult in Rust than C++ in general.
>>106342883
The utter state of Rust evangelists.

>>106342841
Seething dog cuck

some clearly marked subset of code is potentially segfaulting your ass vs every line of code is potentially segfaulting your ass

>>106345110
>some clearly marked subset of code is potentially segfaulting your ass vs every line of code is potentially segfaulting your ass

This is such a retarded fucking take...

The parts that are a problem are the parts doing dangerous stuff, whether it's in C++ or Rust. Rust just makes it even more difficult, because unsafe has even fewer guarantees than C++.

>>106342449 (OP)
>low level code
>unsafe everywhere
>high level code
>nobody has time to manually collect their garbage or check their borrows anyway
Does Rust have a SINGLE real usecase?

>>106345110
The clearly marked subset's correctness can rely on many more lines of code for correctness and avoiding UB.
And if using no_std, there can be UB anywhere, such as with a simple stack overflow.
And that subset is harder to get right.

>>106345283
Pascal will be back in 2026

>>106345283
>Does Rust have a SINGLE real usecase?

There's a reason why no one uses it for anything serious.

>>106344211
The utter state of Rust evangelists.

>>106345283
Rust has pattern matching, I hope and believe that C++ will have it in C++29.

>>106345641
Seething cnile

>>106342504
>Do Rust developers consider this good and idiomatic code? Giant blocks of unsafe? So much memory safety!

It is safe because there are tons of comments that say "/// SAFETY".

Problem solved!

>>106346589
Fix your unsafe code, rustacean.

>>106347211
I once saw a case of UB in the standard library of Rust, where the UB was in the section of code with lots of SAFETY comments.

https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259

Since the Rust standard library is chock full of unsafe, Amazon Web Services launched a volunteer effort to verify it.
https://github.com/model-checking/verify-rust-std
It does seem to have some contributors and activity, and some verification "challenges" have been resolved. However, looking through it, I am not quite sure how diligent and careful they are. This verification PR drops some requirements and marks a challenge as resolved:
https://github.com/model-checking/verify-rust-std/pull/422
https://github.com/model-checking/verify-rust-std/issues/283#issuecomment-3106699308
But there is an open PR by the author of the verification PR to mark the involved functions (that were dropped from the requirements) as unsafe in the Rust standard library:
https://github.com/model-checking/verify-rust-std/issues/283#issuecomment-3165564267
https://github.com/rust-lang/rust/pull/145067
Will they undo the resolved status if that PR gets merged?
The effort does seem nice. I hope those volunteering actually get something in return, like recognition if working at a university.

>>106342449 (OP)
Was it really necessary to put it all into one large block? Couldn't they have split it up?

Rustaceans aren't answering.

If anyone makes a successor language to Rust and C++, please ensure that "unsafe" is more isolated, or needed less often and not needed for algorithms, or easier to reason about and learn and not unspecified.

>>106348397
That case is interesting because the bug was for a type like this where u8 has align=1.
#[repr(align(2))]
struct Foo(u8);

After a quick search, there's not much use of read_unaligned like that anymore in std/core outside of some Windows file stuff and ASCII/UTF8 which shouldn't run into issues like that.

There are still a lot of unsafe things that they're deciding on the rules for, so some code that used to be safe might become UB when they decide on the documentation for it.
https://github.com/rust-lang/unsafe-code-guidelines

>>106349076
>please ensure that "unsafe" is more isolated, or needed less often and not needed for algorithms, or easier to reason about and learn and not unspecified.
Solve the halting problem while you're at it.

>>106349298

>Solve the halting problem while you're at it.
Or use C++, C, Ada, or (I assume) Zig.
Or avoid having a model that is implicitly no-aliasing more or less everywhere.
Or make the actual rules defined and specified.
Or avoid having a really complex type system that requires years of research to create new solvers.
Or avoid the type system holes in Rust.
Or experiment with other approaches and models.
Etc.
And the Rust ecosystem has researched improvements and implemented some of them, but it appears like an uphill struggle.

>>106349410
You don't program and that's fine.

>>106342504
This and any other unsafe code probably makes up less than 1% of the code base. So if you get a segfault and need to debug it, you've already narrowed the problem down to 1% of the code and will be able to solve it many times faster than if you were using C++.

>>106343013
>Build safe abstractions around unsafe code
The whole fucking point of rust is so that you can get performance WITHOUT needing to use any unsafe code. If you have to use unsafe code you're right back to C++ """problematic""" unsafe code.
It's especially fucking insane because this unsafe shit will be shoved into ""safe"" code and people will just assume that everything is safe because it's rust.

>>106349591
Wrong, I've fixed bugs in Rust code that the Rust developers weren't able to fix themselves. Any other lies you'd like to come with, Rust evangelist?

>>106349618
Your post regrettably showcases some of the problems, because you clearly do not understand unsafe in Rust (even though this aspect is one of the much easier aspects of unsafe in Rust). The reason is that whether unsafe blocks in Rust have UB or not, can depend on much more code outside those unsafe blocks. So, no, vetting 1% isn't generally anywhere near sufficient, even in the best of cases where the unsafe blocks are isolated as much as possible. Consider for instance:
https://github.com/rust-lang/rust/pull/145067
>Some (module-private) functions in library/alloc/src/raw_vec/mod.rs are unsafe (i.e. may cause UB when called from safe code) but are not marked unsafe.
And the unsafe blocks can easily be much more than 1%. In the subset of the Rust standard library described in the OP, the unsafe blocks are way more than 1%, despite it being algorithm implementations. Other Rust projects can on the whole be way more than 1%. Combined with having to consider potentially way more code than just the unsafe blocks, one might end up having to vet carefully for instance 25% of the code (not to mention dependencies).
And that then combines with unsafe Rust being significantly harder than C and C++

>>106342449 (OP)
>Why does efficient implementation of common algorithms in require unsafe all over the place?

don't look at java, or golang implementations OP. it may buck break your soul. hell don't even look at libstd++ code unless you have autism.

>>106349860
You said Ada and Zig are replacements, which if you knew what you were talking about, you would not recommend since they are completely unrelated.

>>106349644
>The whole fucking point of rust is so that you can get performance WITHOUT needing to use any unsafe code
that's like saying the whole point of C is so that you can get performance WITHOUT hand written ASM. it's just delusional retardation on your end.
Real world demands highly specialized and arguably unreadable code, no matter what language. that's reality. Optimizing compilers are powerful, but not magic. there are limits.

>>106350043
I also mentioned C and C++, you complete and utter retard. Off yourself.

>>106350003
>don't look at java,
Java is a counter-example to your post, since Java doesn't use unsafe or anything like for, for instance, its reverse-function implementation. Instead, it generally relies on JIT.
>C++
Doesn't have a safe/unsafe split, and is generally easier than unsafe Rust.

>Go
I don't know a lot about Go.

>>106350093
>anything like
anything like it

>>106350093
>java doesn't use unsafe
what the fuck? do you even know java at all? clearly you don't know what you're talking about, so last (You). go shit up /g/ somewhere else.

>>106349644
>>106350059
Monologue?
If Rust was needed less often, or was specified, or did not generally depend on outside code for correctness as much, or was not significantly harder than C and C++, etc., it would be much better. >>106349979

>>106350128
Java uses unsafe way, way, way less often than Rust does. And it is perfectly possible to implement for instance an idiomatic doubly linked list in Java without any unsafe usage, or other algorithms generally.

Now please do off yourself and stop your inane shit and trolling, retard.

The Rusr evangelists and trolls migrated away from the other thread. I wonder why?

Things that the Rust community in general did with the Linux kernel, or its reactions towards Microsoft rewriting tsc from Typescript to Go.
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292
https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12464988

Jeremy Bicha.
>SEX BAT BY JUVEN/VCTM UNDER 12; F.S. 794.011(2) (PRINCIPAL - 2 COUNTS)
Pedophile.
Rust developer.
PPA for Rust.
https://launchpad.net/~jbicha/+archive/ubuntu/rust

Mental health, pronouns and alter egos are at the very least trends in Rust. Also as the community Rust Discord server goes.

Hector Martin.
Insisting that Asahi Lina is not his alter ego.

https://aturon.github.io/tech/2019/06/25/back-in-the-saddle/

https://fasterthanli.me/articles/state-of-the-fasterthanlime-2024
https://fasterthanli.me/articles/that-health-is-mental

>>106350211
https://wiki.ubuntu.com/JeremyBicha
>I am a United States Navy Veteran and spent 2007-2010 living in Bahrain. I currently live in Florida. I joined Canonical in 2022 but my Ubuntu story started much earlier.

https://wng.org/articles/the-high-cost-of-negligence-1617309216
>Florida prosecutors weren’t forgetting: The U.S. Navy discharged Jeremy, and when he reached U.S. soil, authorities arrested him. He eventually pleaded no contest to two counts of sexual battery on a child under 12 while he was under 18. His defense attorney asked for less than a year in the county jail. The prosecutor asked for 15 years in state prison.

>>106350176
>Rusr
Rust

>>106342741
No answer to fucking what? There is no argument beyond "oh, you say safe? I spy with my little eye a the word 'unsafe', that's the opposite of safe!". Are you disappointed nobody will talk to you about a tcp "stream" having no water, "classes" having no teacher s or student and "debugging" involving zero insects?

>>106350516
>>106349979

>>106351047
I decided to bite, despite that other anon being 100% truth nuke on your ass.
If people struggle to get unsafe Rust right (which is true) imagine how people manage with C(++), Pascal or whatever other compiled language. The answer may shock you.

>>106351170
>despite that other anon
Off yourself, you incompetent, inept troll, you aren't even pretending to read the posts.

An unsafe block exists??? Good heavens, that's terrible.
Now, we know where to look for what's causing a miscompilation or unintended behaviour.

>>106351209
>>106349979

>>106351047
>>106349979
>The reason is that whether unsafe blocks in Rust have UB or not, can depend on much more code outside those unsafe blocks.
>Consider for instance:
>https://github.com/rust-lang/rust/pull/145067
What's "can depend on"? All possible UB fixed by that pr happens in unsafe. Unsafe that can only be reached by either calling an unsafe function, in which case the onus to verify preconditions are valid is on the calller, or by calling a safe function, in which case the onus is strictly on the safe code inbetween the function signature and the unsafe block within the function. No other code is relevant. No matter how many safe functions you stack on top of it.

>>106351506
Retarded, moronic, stupid, idiot, worthless troll, off yourself. You are completely wrong. Pro-tip: Try actually understanding unsafe and reading the documentation.

>>106351506
>>106351876
For the sake of anyone else reading this: As basically described in the official Rust documentation:

// Invariant A: Must have some specific range of values.
let mut x = ...;

pub fn f() {
...
unsafe {
...
// Invariant A must hold, otherwise UB.
using_x_for_something_assuming_A(x);
...
}
...
}

// Newly added function, but with bug.
pub fn g() {
...
// Bug: Break invariant A, no "unsafe" needed.
x = ...;
...
}


This is why the PR describes
>(module-private)
Since then the invariants can be maintained and be kept isolated inside a module.

>>106348037
What's there to be fixed?

>>106342449 (OP)
Yes, working with null pointer is unsafe. What are you trying to say here, OP?

>>106343022
>Ada is a bad joke
because it isn't popular? sad
still it has better libraries that don't take up 5 gb and bundle is-even along the way

>>106352539
>>106352562
Off yourself, you lazy, retarded, worthless troll.

>>106352621
And apparently the rust community is toxic.

>>106352592
Here's your ecosystem, sis
https://alire.ada.dev/crates.html

The problem I have with Rust isn't necessarily unsafe, it's that when you do unsafe the tooling shits its pants and you're in glhf mode.
C and C++ at least have like a gorillion years worth of engineering years invested in tooling, debuggers, trace allocators, etc.

>>106352865
You can use those tools with Rust

>>106352642
I'm not the one running around raping children.
>>106350176
>>106350211
>>106350227
Also not a part of any language community.

>>106345283
>Does Rust have a SINGLE real usecase?
turning males into uglier males with skirts

>>106342449 (OP)
>Why does Rust force developers to learn the intricacies of unsafe and bear the maintenance burden of unsafe when they want to implement common algorithms like sorting algorithms efficiently?
because implementing these algorithms efficiently requires access to the tools that unsafe gives you
The alternative is either having those tools all the time, even when you don't need them (C/C++) and potentially shooting yourself in the foot as a result, or not having access to them at all and being unable to efficiently implement things in the language.

>>106353728
>uglier males with skirts
wtf you described me

>>106351958
The point of safe functions is that the entirety of the invariants required to not exhibit UB are expressed within it's signature.
If there are extra invariants required to call function f safely then it should not be safe.
If f fails to properly verify it's invariants then the code inside is wrong.
Either way, the possible bugged code is entirely within f. Oh look that's the function with the unsafe block in it, unsafe helped us find the bug.
Unsafe is for invariants the compiler cannot verify, safe is for those it can. When you provide a safe interface over unsafe functionality you are guaranteeing that as long as that interface is upheld the unsafe functionality won't be called in a UB-causing way. If that's not true the issue is between the interface and the unsafe block, not anywhere else. The safe guarantee function f provides is wrong. Function g is completely irrelevant.
Being module-private has nothing to do with it.

>>106352865
Mir is better than valgrind tho

>>106354894
/thread
OP is a nig-nog

>>106342449 (OP)
seems pretty safe to me
t. chud

>>106355177
This is as bad as any C++ footgun and the Rust community shills this language as being safe, with clearly defined behavior you can be assured of. The language is worse than C++ because it's hiding the fact it can have UB in any function that has ever interacted with unsafe and yet the language markets this sort of shit as impossible in Rust. The more I use and learn about Rust, the more I think it is a regression over C++.

>>106356121
what a fucking retard you are lmao

unsafe is used to implement small snippets or utilities that can be proved to be correct and thoroughly checked

>>106356147
All the bug reports in this thread prove otherwise.

>>106356147
>that can be proved to be correct and thoroughly checked

In theory you can prove and thoroughly check any piece of code in any language.
The question, of course, is: does it actually happen in practice?

It is dubious that it happens outside of C, C++, Ada and Java, the only languages that have serious tooling for proving and checking correctness.

Rustroons think they've done anything useful by requiring the programmer to write 'unsafe' around unsafe code. But this achieves precisely fuck all.

>Build a hammer-your-dick machine
>It is clearly unsafe
>Add a sign saying "UNSAFE" on it, so people can now use it safely

>>106342985
It really is. By the time you've found an actual exploitable memory vulnerability in C in 2025 on an actual machine you've probably found a cargo vulnerability affecting 100% of all rust codebase

>>106356359
Are you a fucking bot? Do you understand the difference between writing and checking an entire fucking program and just a few crucial lines?

>>106354894
>>106355414
Yet unsafe in Rust is significantly harder than C and C++. And unsafe is required, as seen in the OP, even for algorithms, and large amounts of it. >>106349979

>>106355177
>>106356061
You come with several lies and falsehoods that have already been cleared up in this thread, incompetent, moronic, retarded troll. For instance in
>>106349979
>>106351958
Are you just spamming LLM? Off yourself.

>>106355177
>within it's signature.
ESL.

>>106342449 (OP)
There is nothing wrong with unsafe.

>>106355187
They complement each other. Also consider the recommendations in https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/ .

>>106356121
>>106356147
>>106356359
>>106356454
Monologue? Unsafe Rust is significantly harder than C and C++, which is a major aspect of the issues with this, and why parts of the Rust community heavily discourages usage of unsafe.

>>106357024
Why does the Rust community heavily discourage it then? Why does broad parts of the Rust community itself warn about unsafe and agree that it is more difficult than C and C++?

>>106357070
does the rust community heavily discourage it when it comes to implementing small, foundational, proven algorithms?

>>106357106
Are you seriously arguing that efficient implementation of algorithms is meant to be "foundational", restricted to a few libraries? Do you consider the utter state of https://rust-unofficial.github.io/too-many-lists/ a good thing? What are you even smoking? Are you the same retard that keeps trolling?

>>106357047
>Monologue?
this schizo retard still isn't banned for low quality posting?
really wish we'd have poster IDs only so I can
a) filter retards like this
b) dispell "muh samefagging" schizo retards who had a melty over "unique IP posters" being removed.

get to it jannies.

>>106357288
what's wrong with that book? it shows you how you can do stuff in Rust. It's actually a good book if you're struggling to understand some of the APIs around standard library types, like Option<_>.take() etc.

>>106357350
The only schizo retard here is (You), moronic, inept, worthless, trolling retard. Off yourself.

>>106357362
Why would you consider it a good thing that a whole book is required just to teach people how to implement doubly linked lists correctly and efficiently in Rust? Trivial in other languages. Are you the low-IQ rustacean troll that keeps spamming?

>>106357070
It discourages it for the same reason people discourage writing software in C. because you'll shoot your dick off in some spectacular way. It's not hard to understand unless you're low IQ like this mass replying schizo.

When you write unsafe code you need to make sure you actually understand what you're doing. If you're calling some C ABI with a Vec::as_mut_ptr() you need to know if the ABI called function will access it in an expected way and you need to know how Vec works as well. This is how "low level" programming works and rustc static analysis is not turing complete.

>>106357288
I ask you again, where are the people complaining about using unsafe when implementing proven basic algorithms and data structures that are performance critical?

>>106357407
>Trivial in other languages
it actually isn't though. starting to think you've never programmed in your life.

>>106357428
>>106357431
>>106357447
Please stop your trolling, you utterly and completely retarded, dishonest, inept, zero-IQ, evangelist fraud, and off yourself.

For anyone actually reading this, consult the thread, that troll has no honesty nor competence.

>>106357511
>heh, see how easy it is to build a doubly linked list in X lang--
*segfaults*
*leaks memory because of ref cycles*

Rust just keeps you honest. I don't know why this language buck breaks you seething incompetent shitters so much. God forbid a language force you to be explicit instead of implicit.

>>106342449 (OP)
Pretending that your computer doesn't run on an archtechture with flat memory addressing is detrimental to its performance if you couldn't tell.

>>106357654
>>Pretending that your computer doesn't run on an archtechture with flat memory addressing
>everyone knows pointers are just integer indexes into a 2^64-1 array, bro
>what is virtual memory?
>what are authenticated pointers?
>what is MMIO?

are you retarded or something?

>>106357549
You are being too incompetent, low-IQ, retarded troll. Off yourself.

>>106356968
skill issue
>even for algorithms
what does this even mean? what else would you be using it for?

>>106358579
>skill issue
Yes, it is a skill issue for rustaceans like you.
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>what does this even mean? what else would you be using it for?
Off yourself, retarded troll.

>>106356121
>it's hiding the fact it can have UB in any function that has ever interacted with unsafe
DIRECTLY interacted. You don't understand the safety model and think it's some other safe function's respobsibility to maintain invariants of another safe function. It isn't. The g in your example is completely irrelevant. Same with h, i, j, k and however many other functions you stack on top. F is the one directly interacting with an unsafe block, f is the one providing the safe interface for that interaction and f is not properly upholding said interface. The bug is in f.

>>106359083
if this is all inside of a private module I think the bug could be inside of g. It depends on where you consider the invariant to be important to the module as a whole or just do the function f I guess?
For example, if you're writing a data structure of some kind it doesn't necessarily make sense to repeatedly verify bounds or whatever, rather than just doing it at API boundaries.

>>106356409
>made a machine that takes a number and hammers your dick if it's odd
>option one: require a special unsafe cable nobody keeps around to run it, and engrave a warning on how it will smash your balls next to the machine's electrical socket to maximize the chances of someone heeding the warning
>put it inside another machine that rejects all odd numbers before passing the number to your first machibe, use a standard power cable everyone has around

>>106359083
>>106359204
More monologuing, retarded troll? Off yourself.

>>106357070
The same reason any other thing is discouraged. Because most people are stupid retards with no self control and will abuse an "easier" tool instead of properly learning the appropriate one. See, retards in this thread, who would have no issues hammering screws

>>106359360
But at the same time, unsafe Rust is frequently required for fairly basic and common things like efficient implementation of algorithms, so not learning unsafe Rust thoroughly and not using it is not in the general case an option. And the utter retards like >>106358579 have no business doing systems programming in the first place where lives or critical infrastructure may be at risk. Also >>106350135 .

>>106359204
Every invariant of a safe function has to be expressed in it's signature. More broadly, every invariant required for safe rust needs to be expressed in it's type system.
There are three options
>f doesn't check all of it's unsafe block preconditions and you don't want it to - mark it unsafe
>f doesn't check all of it's unsafe block preconditions and you want it to - fix/add the checks and if required change the return to something that can indicate a failure (bool/option/result)
>f doesn't check all of it's unsafe block preconditions and you don't want it to but you still want it to be safe - add an "access token" parameter that is created by verifying f's preconditions and borrows the precondition data in a way that prevents invalidating the preconditions
Remember, the compiler in safe only has to consider the rules of safe, and it's free to optimize over any invariants you may have, but didn't express in safe

>>106359499
Are you the low-IQ retard who keeps trolling the thread? If so, learn to write proper English and off yourself.

>>106359499
Are you sure about that? I would think that the invariants only have to be expressed when it's a something public facing - internal functions should be free to assume invariants just fine
When you call get() on a vec or similar that function doesn't need to make sure that the internal pointer to the data is valid, all you're doing is verifying the bounds of what you pass in.
To put it another way, you're not constantly making sure that your pointers aren't null - you just make sure that they're correctly set when they are

>>106357806
Yes, i fucking know do you really expect me to list all of its nuances when you already get the fucking point?

>>106342449 (OP)
>>The Rust standard library has had at least several occurrences of undefined behavior and memory unsafety, so don't tell me that unsafe is fine. https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
>click link
>unbounded channels of crossbeam
>crossbeam isn't part of std lib
what did OP mean by this?

>>106361756
OP is most likely a nocoder and used AI to find issues with Rust. Everytime he gets the slightest pushback he calls you a troll and a pedophile, while complaining about the so-called toxic Rust community.

>>106359555
So in case of a Vec the self is the "access token". All the functions creating a Vec ensure a valid buffer, same with all the functions modifying the buffer (not it's contents), meaning the existence of Vec a enforces the validity of a buffer inside it.

>>106359555
>>106362060
Is this an LLM?

>>106361756
>>106361861
Retarded (yes, you are retarded), trolling (yes, you are trolling), worthless, inept moron, try to actually read the article. Parts of that library was adapted into the Rust standard library. And ended up having the same or similar memory unsafety and UB bugs. As is clear if you actually followed the links in the article to the Rust language's Github repository.
https://github.com/rust-lang/rust/pull/121646
https://github.com/rust-lang/rust/pull/139553
Now off yourself.

>>106361861
Maybe clean up your community and stop raping children.
>>106350176
>>106350211
>>106350227
Though maybe that is too difficult for you, if the core of your community is the problem.

>>106342946
That wasn't the point. Are you lying to yourself, or are you trying to lie to us? pic rel

>>106350003
False equivalency, a classic Rustard strategy. I've never seen a significant number of C++ or Java developers make delusional claims about safety regarding their language of choice. They're more likely to say "skill issue", which is way more honest and truthful.

>>106350043
Fine replacements for a language that's controlled and maintained by the most delusional retards you'll find in the software development space, yes. I'd rather use Objective-C and hang around with Apple faggots than touch Rust voluntarily.

>>106364995
>>106365061
>>106365073
Rust evangelist detected.

>>106363644
>>106363664
Speaking of child porn, why does the C++ community continue to hide and offer protection to someone who is a sex offender and got caught with CSAM?
Funny I never heard you complain about that, very funny coincidence.

>>106350003
You have no idea what you're talking about.
The use of unsafe code in the Go standard library is extremely sparse and pretty much only used when calling optimized assembly for hot paths.

>>106366149
The mere mention of his name gets you banned from their subreddit.
Why does the C++ community continue to shelter a registered child sex offender?

>>106349076
You just described ‘go’

>>106366179
>Arthur O'Dwyer
Welp, that's unfortunate. I liked his Back to Basic talks at CppCon

>cp convicted

>>106366149
>>106366179
>>106366244
That's fair, I've also seen questions asked about Arthur O'Dwyer get deleted on reddit.com/r/cpp .

But, this actually counts against the Rust community, not the C++ community, perhaps surprisingly.

First off, as I understand it, ISO rules are strict and prevents people from being excluded. A person just needs someone sponsoring them. So the C++ ISO community's hands are tied as long as someone sponsors Arthur O'Dwyer. Who sponsors Arthur? Who knows. The C++ community did take indirect action, however. Every single proposal that Arthur O'Dwyer made for C++26 got rejected, and Arthur even included a paragraph in one revision of a proposal whining about in his eyes poor or unfair treatment if I recall correctly.

Second off, the top reddit.com/r/cpp moderators, u/STL (Stephan T. Lavavej) and u/foonathan (Jonathan Müller) are rustaceans and actively moderate their subreddit, reddit.com/r/cpp, against C++ and in favor of Rust. And it appears that it is them that is protecting Arthur O'Dwyer in regards to moderation of their subreddit.

Why think-cell, a company with a large C++ focus, employs someone like foonathan/Jonathan Müller, who is actively working against C++, I've no idea. Maybe they just don't know about it.

>>106366223
But Go-the-language and Go-the-libraries generally assume a garbage collector, right? Does that really cover all areas and topics of embedded programming well, and is Go suitable for writing operating systems?

>>106365727
Every single post is negative towards Rust, so very low quality bait.

>>106367084
And the posts (your posts) are obviously of intentionally very poor quality. Now off yourself, retarded troll.

>>106366974
>u/foonathan (Jonathan Müller) are rustaceans
Stuff like this?

>>106367208
No, way worse stuff, especially what foonathan moderated on r/cpp.

Computers are fast.
safety > speed

>>106345654
>it will be in the standard by 2029 and in GCC by 2034 hopefully !

>>106367566
Shouldn't it be the other way around? First in compilers and used in the wild, then possibly adopted by the ISO standard?

>>106367596
C++ modules have been added to the standard in 2020 yet using to this day CMake and clangd only provide experimental support.
And don't even think about using import std;

>>106367658
C++ modules were a special case in my opinion. I believe several significant mistakes were made, and it could have been done so much better, but retrofitting a module system was never going to be easy, and the alternative might have been waiting a number of decades before some module system got adopted, and that waiting would have costs in itself. C++ isn't owned by any one company, it is an ISO standard, so individuals, organizations and companies basically volunteer or cooperate for developing the language, tooling, ecosystem, etc. Who foots the bill for lots of experimentation with modules? And are there even enough experts whose expertise covers the intersection of fields needed (C++, programming language design, module systems, etc.) in the world? Funding programming language development isn't necessarily trivial. I am guessing that the modules feature was not one of the features that would be easy to try out a lot in the compilers and ecosystem, since it involves so many things and so much effort and expertise.
Pattern matching, on the other hand, is one of those features that would only really involve compilers, and should be possible to toggle with a flag.
Different features, different approaches, different requirements and expectations.

Maybe Bjarne Stroustrup tried to make modules happen 30 years ago, and got impatient and wanted modules in the standard before he died of old age. But I am just blindly speculating about that.

>>106367658
>>106367942
While Rust's crate system is widely acknowledged to be good and tremendously better than what C++ in practice has currently, there are still issues and complaints about it. One minor complaint, which involves the Rust language itself, is the orphan rule, somewhat shared with Haskell. Scala solved it, OCaml have as I understand it not adopted type classes because they want a solution that also solves that issue (also backwards compatibility concerns).

>>106367121
"I don't like these posts so you can't be serious"

>>106368766
More inanity. Off yourself, inept, worthless troll.

>>106370161
Zero arguments. This is why you are losing.

>>106363644
>click link again
>first one
>This is a nightly-only experimental API. (mpmc_channel #126840)

nigga....

>>106367658
>include for memes
>compile time drops significantly
power of C++ Modules?

>>106371133
>Zero arguments.
That describes you, not me.

>This is why you are losing.
The software development ecosystems losing because of deceitful, low-IQ trolls like you? True.
Now off yourself, you moronic, retarded troll.

>>106371295
Cope. https://github.com/rust-lang/rust/pull/139553

>>106371416
>n-no u
Lmao what a bitter minded loser. Can’t argue, all you can do is point fingers.

>>106371426
>sync::mpsc
>This is a nightly-only experimental API. (mpmc_channel #126840)
nigga, plz. You're killing me here.

>>106371446
eh. ok, I am blind. good job retard. you found one.

>>106342449 (OP)
>Rust
RETARD
ALERT!

>>106371446
>>106371483
The retard is you, as you at least admit and acknowledge here. Off yourself, low-IQ troll.

This shit really is a tranny language... isn't it...

>>106371440
Deceitful troll, you are describing yourself, not me. Off yourself, moronic retard.

>>106345654
>Rust has pattern matching
Did it detect that the "women" coding with it were actually men in dresses?

>>106371582
That's a different kind of pattern matching, more in the ballpark of statistics, machine learning, AI, neural networks, etc.

>>106342741
Read https://plv.mpi-sws.org/rustbelt/
Basically they opt out of the safety system for performance reasons because they're trying to compete with libc(++) implementations, which are hard tuned by very smart people. I haven't tracked rust in a minute, but it used to be they would have proofs for those unsafe blocks and you could just check the transliteration yourself if you don't believe them.

It's not like you can't write data structures in safe rust. It's just a pain in the balls.

>>106374466
>I haven't tracked rust in a minute, but it used to be they would have proofs for those unsafe blocks and you could just check the transliteration yourself if you don't believe them.
More like they just had comments with "SAFETY" prefixed, and sometimes having UB in the Rust standard library.
https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259

More recently, AWS have launched a volunteer project for people to do verification of the unsafe bits of code in the Rust standard library >>106348397 .

>>106342449 (OP)
rust is unsafe

>>106342449 (OP)
I was building a workout application for a handheld device in rust, and when it got to using the buzzer on the device, I had the most insane time trying to get it to work. Went to an AI with functional C and Python code, and got something back that was 3-4 times the size with tons of imports and unsafes everywhere.

Wound up compiling the C code, and just making calls to it when I wanted to run the buzzer. Makes no sense to make it in Rust because of the unnecessary mental overhead.

This python code is apparently too difficult to do in a Rustful method.

```
with open(DEV_PATH, "rb+", buffering=0) as fd:
eff = ff_effect()
eff.type = FF_RUMBLE
eff.id = -1 # new
eff.u = ff_rumble_effect(0x6000, 0) # strong, weak
eff.replay = (500, 0) # 500 ms duration

# upload effect
fcntl.ioctl(fd, EVIOCSFF, eff)

# play (start)
play = input_event(0, 0, EV_FF, eff.id, 1)
fd.write(play) # struct write – py <3.11 requires bytes()
time.sleep(0.5)

# stop
stop = input_event(0, 0, EV_FF, eff.id, 0)
fd.write(stop)

# erase
# fcntl.ioctl(fd, EVIOCRMFF, ctypes.c_int(eff.id))
fcntl.ioctl(fd, EVIOCRMFF, eff.id) # pass plain int by value

print("Done – motor should have buzzed for 0.5 s.")

```

>>106375314
Rust fits pretty much every definition of a Turing Tarpit - sure, it technically CAN do anything, but holy shit is it painful to figure out HOW and why did anyone think the Befunge-esque syntax was a good idea for what’s supposedly a serious language for serious people?

>>106342449 (OP)
The people complaining about unsafe Rust are the biggest midwits on the planet. There is literally nothing wrong with using unsafe. All unsafe does is let you
>Dereference a raw pointer
>Call an unsafe function
>Implement an unsafe trait
>Mutate a static variable
You still have the borrow checker, you still have explicit ownership semantics and you still have the type system. Which collectively makes unsafe Rust significantly safer to use than normal C++.

>>106375314
Why did you attempt to use ``` instead of [code ][/code ] (remove spaces)?

Are rustaceans just using LLM chatbots to spam?

>>106375950
why can't rust safely deference a raw pointer and mutate a static variable?

>>106375950
Why do you keep lying, moronic, retarded troll? Off yourself.
Even the Rust community at large agrees that unsafe Rust is significantly harder than C++ or C. Due aspects such as unsafe Rust not even being fully specified yet and there being on-going research, and Rust assuming no-aliasing more or less everywhere.
And Rust standard library developers have difficulty avoiding memory unsafety.
https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>106376177
Neither can C or C++ or most other systems languages, but among other aspects, in Rust, more or less everything is assumed to be noalias. And that assumption is significantly more difficult than C and C++.

because it is potentially unsafe behaviour. it has been implemented in a way that works. just use it

>>106376174
reddit
cant even say anything about it anymore it's most of the people here now

>>106342449 (OP)
>Our code is fast and safe! We should replace C!
>*looks inside* The only fast code is covered in unsafe tons of shit.

>>106342449 (OP)

>Why does Rust force developers to learn the intricacies of unsafe and bear the maintenance burden of unsafe when they want to implement common algorithms like sorting algorithms efficiently?

Because random access is unsafe. If you want to guarantee that a user will NEVER write to invalid memory, then every random access on an array, slice, or vector has to be bounds checked. Do you want to not bounds check? Do you want to do things the C way? You use the unsafe keyword. Unsafe means "we're doing it the C way".

I challenge you to find a way to guarantee memory errors are impossible in user generated code while allowing random access to arrays without bounds checks.

Also, if you're complaining about having to learn new things, you need to kill yourself immediately. "Waaaaah, I don't want to read about the intricacies of..." Shut the fuck up and put a revolver in your mouth.

>>106376245

back to

reddit you

go

>>106376287
I have no account on reddit and have likely been on 4chan longer than you have. Let me guess what you're going to say... "Reddit spacing", right? That shit has been a forced meme for far too long. Oh, Reddit fucks up paragraphs so anyone who deliberately adds vertical space between paragraphs must be from Reddit. Wrong, you fucking illiterate nigger.

>>106376177
You can't create a compile time guarantee about the pointer.
>>106376195
Midwit spotted.
>significantly harder
I didn't say it was easier, I said it was safer than C++ (and it is).

>>106376225
If it works, why do core Rust developers keep introducing UB and memory unsafety with it? >>106376195

>>106376245
>Do you want to do things the C way? You use the unsafe keyword. Unsafe means "we're doing it the C way".
Completely wrong, you lying, deceitful, incompetent, negative-worth retard. Linus Torvalds was fed that lie as well, to help sell him on Rust. Unsafe Rust requires you to handle no-aliasing basically everywhere, which is one aspect of why unsafe Rust is significantly harder than C and C++. In C, one has to use the +restrict+ keyword to opt into no-aliasing. And as seen by UB introduced by Rust developers in Rust's standard library, apparently too difficult for Rust developers.

>Also, if you're complaining about having to learn new things, you need to kill yourself immediately. "Waaaaah, I don't want to read about the intricacies of..." Shut the fuck up and put a revolver in your mouth.
Make Rust developers learn it first without introducing UB >>106376195 . And you are the one that should off itself, not me, you zero-IQ, retarded troll.

>>106376496
>Midwit spotted.
You must have been looking in a mirror, considering:
https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>significantly harder
>I didn't say it was easier, I said it was safer than C++ (and it is).
You lying, deceitful, zero-IQ, negative-worth, retarded troll, off yourself.

>>106376614
>mfw fearless concurrency
lamao

>>106376666
For practical Rust programmers, even if the internal implementation was correct, the concurrency would still not be fearless, since spamming Arc> everywhere includes the risk of deadlocks as I understand Rust. And the rules of when a lock is held or not has changed across editions.
https://doc.rust-lang.org/stable/edition-guide/rust-2024/temporary-if-let-scope.html
At least Rust supports automatic upgrades between editions.
But not warning people properly about concurrency not being fearless, is not honest by the Rust community and its evangelists. Fearlessly believing something to be safe, especially when it is not, can cause extreme losses.
https://en.wikipedia.org/wiki/Ariane_flight_V88
>The subsequent automated analysis of the Ariane code (written in Ada) was the first example of large-scale static code analysis by abstract interpretation.[9]

Opinions on async in the Rust community appear deeply divided. Some love it, others hate it.

>>106376751
>Fearlessly believing something to be safe, especially when it is not, can cause extreme losses.
yeah, false positives. rock climbing analogy: you think you can rely on your harness so once you climbed to the top you try to use it to descend.
thats when it breaks and you die
false negatives are safer than false positives- the former make you do a check which may or may not be redundant, the latter causes unexpected failure

>Opinions on async in the Rust community appear deeply divided. Some love it, others hate it.
i imagine the former turn into the latter with experience, kek
i would have aboslutely hated a framework if it gave me false positives

>>106376815
I'm not sure false positives and false negatives really play into things here, it is more about evangelism that is directly lying about what has to be handled by the programmer and what their responsibilities are.

As for async, writing async libraries is apparently painful.
https://www.reddit.com/r/rust/comments/1ahnu7n/why_is_async_rust_controvercial/

>>106342449 (OP)
Because Rust doesn't have the necessary compiler optimizations to do that efficiently. It's imperative first so you're going to need to hack.

>>106376852
More like a successor to C++ and Rust might be possible to create that is significantly better than both C++ and Rust, also in this regard.

>>106376852
>>106349979

Apple solved concurrency in C 15 years ago (look up dispatch_async) but freetards refused to adopt it because of muh ebil apple

>>106376845
>I'm not sure false positives and false negatives really play into things here
the article you posted could be described as such. i dont have a larger cognizance of the rust's community discussion dynamics
>As for async, writing async libraries is apparently painful.
that one doesnt surprize me though
rust hasnt been engineered with usability in mind
>inb4
yea, no. even the most basic rules of visual communication arent respected.
and in its original design goals, the aim was to force the user into a rigid system with syntax.
and you cannot achieve that without adding complexity, which goes against usability
i guess when they balanced all things they decided that interfacing is where concessions will be made
and then on top of that they smothered the thing with incompetent design

>>106376614
It's hilarious when c++ tards get angry.
>>106376666
>>106376751
"Fearless concurrency" doesn't mean "bug free", it means "data race free". That's all.

>>106376984
>"Fearless concurrency" doesn't mean "bug free", it means "data race free". That's all.
read the picrel
or even better, the og article

the problem IS a race condition
pff, the absolute state of crabs

>>106376926
>and then on top of that they smothered the thing with incompetent design
Well, to be fair, that seems to be a common theme across programming languages. Programming language design can be really difficult, even for basic stuff. Consider how Swift for instance royally fucked up its type inference and type system. What irks me way more is the ridiculous amount of dishonesty in the Rust community about certain of Rust's issues, for it makes it harder for everyone, themselves included, to work around, mitigate or fix Rust's issues. Selling and spreading Rust appears way more important to them than responsibility and genuine safety and security.

>>106377004
>the problem IS a race condition
Not a data race though, is it. Dumb dumb. The Book literally says that Rust can't protect you from an arbitrary race conditions.

>>106376984
I am not a member of any C++ community.
Either way, you should off yourself, incompetent, trolling, drooling, zero-IQ retard.

>>106376984
>>106377004
>>106377018
Is this more monologuing? Off yourself, you inept, zero-worth troll.

>>106377008
>Well, to be fair, that seems to be a common theme across programming languages.
im not gonna say that is not true
but why compare to the worst? its not really an excuse, nor does it make the actual product better. it only changes the perception thereof, if anything
>What irks me way more is the ridiculous amount of dishonesty in the Rust community about certain of Rust's issues, for it makes it harder for everyone, themselves included, to work around, mitigate or fix Rust's issues. Selling and spreading Rust appears way more important to them than responsibility and genuine safety and security.
to an exterior observer this signals that theres ulterior motives

is the rust foundation a grift?
is it a matter of licences?
is it a political assault on the world of programming?

is it caltrops deliberately pushed by big corpo to penalize small teams?
or maybe is it all of the above?

>>106377020
>>106377029
C++ tards be maaaaaad lmao. It's not my fault you've made such a fool of yourself. Maybe next time, just be a little bit more knowledgeable.

>>106377045
i misread
>the last defence of the crab hibges on it
ah, such is the power of fearless concurrency, i see

>>106377034
>is it a political assault on the world of programming?
Lmao, deranged.

>>106377066
>be shartypedo
>calls you deranged
ok, i think youre trolling

>>106377034
>>106377045
Cease your lies and inanity, negative-worth, incompent, bungling troll.

>>106377068
were not the same people
for better and for worse lowercasing is a thing on 4 keks

>>106377068
>Calls other people inane
>Post in a language wars thread
Topest kek.

>>106377084
>implying theres no legit grievances to be had about languages

>>106377077
>>106377084
>>106377094

>>106377068

>>106342467
>favorite
assumesort

>>106352748
let me guess, you need more?

>>106377113
not lies doe
rust is being worked on since 18 years
thats 1/3rd of the life of C and half of C++
still not stable in features
still not v1.0
still gets pushed by:
-lgbtetc
-big corpo
-governments

occam's razor: they have ulterior motives

>>106377135
>>106377068

>>106342467
stalins sort

>>106377318
>Y-y-you're a t-troll!!!!!!!!!!
STFU, tranny.

>>106377416
Off yourself, retarded, negative-worth troll.