[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


Janitor application acceptance emails are being sent out. Please remember to check your spam box!


[Advertise on 4chan]


I've still not seen a convincing argument for why Rust makes software worse for the end user. Show me why the code is bad instead of saying "but trannies".
>>
File: crab-knife.png (12 KB, 749x750)
12 KB
12 KB PNG
>>107370496
its bad in many wonderous and surprizing ways
it depends what rust is peddled as replacement for

for instance: its an asinine c replacement because it awfully high level in relation to c's usecase
>>
>>107370546
Yup, i really like but imo it's more of a cpp replacement than a c replacement.
If you want a better c that's more zig than rust.
>>
>>107370566
i think theyre missing the point of c
c is for when you do hacky stuff
so a development of c should go into hacky stuff maximization
of which theres plenty provided by the cimpilers already
that should get standardized i think
thats whats gonna make a better c
>>
>>107370496
 .unwrap() 

>b-b-but...
b-b-but your shitlang is supposed to be safe.
>>
>>107370623
unwrap is not unsafe retard.
No programming language is gonna prevent the developer from writing "if this fails exit with an error".
Rust devs know exactly what unwrap does and it has its place, ie unrecoverable errors.
>>
>>107370496
I'm a white male, I can't use rust
>>
>>107370658
>use rust because it makes your code safe!!
>well, ackshually, it doesn't make your code safe
then what's the point?
>>
>>107370658
>unrecoverable errors
name one that doesn't sound made up
>>
>>107370496
>Show me why the code is bad
Ok.
>1) Retarded and pervasive borrow checker
>2) Explicit lifetimes when the compiler can infer them in most cases
>3) Overreliance on unwrap() for error handling
>4) Excessive use of annotations
>5) Pattern matching for error handling is overly verbose
>6) Ad-hod and convoluted syntax
>7) ?
>8) The underscore can mean different things depending on the context.
>>
>>107370685
The reason i use rust is not its safety features, yes, it's what initially got me interested but i just found it to be a pretty good language with good tooling and ecosystem, the safety features are the cherry on top but i don't care so much about them.
Also, as i said, unwrap is not unsafe.
The language is made to be memory safe, ie, avoid memory related errors (ie buffer overflow, use after free, race conditions etc) that could lead to arbitrary code execution.

>>107370686
A program needing a config file to do its job and it being given an invalid file.
If you give a blender file to a music player or unzip, the expected behavior is to exit with an error saying the file is invalid /not a supported format.

unzip expects a zip file, if you give it something that's not a zip file (in content, not file extension) it shouldn't try to run anyway.
There are many cases where an error should result in exiting the program.

And imo in the cloudflare case, the proxy was well behaved, it exited with an error after being given a broken file, it mitigating the issue is imo outside its scope of responsability, the file should have been validated before it ever got to it, and the orchestrator / monitoring should have rolled back automatically upon failure to start.
No, crashing cloudflare is not the desired behavior but mitigation is imo outside the scope of responsability of the proxy ie separation of concerns.
Also this was not an accident, the dev that used the unwrap understood what the consequence would be, but maybe he didn't understood that the rest of the architecture was broken and would not rollback on top of not validating but exiting with an error when given an invalid broken file is proper behavior.
>>
Rust is more verbose than Java. Less safe too.
>>
>>107370780
? Is just amazing imo.
>>
>>107370658
>unwrap is not unsafe retard.
>panic and close the software is not unsafe
sure thing buddy
>No programming language is gonna prevent the developer from writing "if this fails exit with an error".
in C if you don't test return value then oyu're a fucking moron, it was a solved issues decades ago, there is a reason why $? exists in bash... ALWAYS CHECK RETURN VALUES, that's programming 101.
>Rust devs know exactly what unwrap does and it has its place, ie unrecoverable errors.
the only irrecoverable errors are hardware failures and you can't prove me wrong.
every other fucking errors are recoverable, most just decide not to do it, the retards who did not check the unwrap should be fired and prosecuted, there is no consequences to writing shit code so no one is willing to learn about how to write robust software anymore.
when doctors kill people there are investigations, it should be the same when you disrupt the economy world-wide because you can't write code for shit.
>>
>>107370820
Doubly false.
>>
>>107370828
You do not understand what memory safety is.
> muh return value
Rust doesn't let you use a function result without handling possible errors, you can choose to "exit the program with an error" if a result is an err but it's still a form of error handling.
In c you can use a function result without even checking if it was successful, which will lead to a lot more issue, if this program had been written in c they probably would have overflowed the array like retards, which is worse because UB.
> every other fucking errors are recoverable
There is no point in continuing to run a program if it is functionally useless because it doesn't have what it needs to run, ie invalid config file.

Sure you could continue running your backend if the db was invalid on startup but that'd be retarded a crash is much better than a silent failure.
>>
>>107370804
>A program needing a config file to do its job and it being given an invalid file.
lmao retard, that 100% recoverable
>If you give a blender file to a music player or unzip, the expected behavior is to exit with an error saying the file is invalid /not a supported format.
wrong, the expected behavior is to warn the user and wait for another file to read.
>There are many cases where an error should result in exiting the program.
only in cmd programs that execute the task and escape, you can't just force exit a GUI program because of a one error, you display some warning and wait for user input
>And imo in the cloudflare case, the proxy was well behaved, it exited with an error after being given a broken file,
wrong, the only good answer is to use the last previous known working config and to send alarm to whoever the fuck is managing the system.
> it mitigating the issue is imo outside its scope of responsability
it should have been caught during CI/CD, feeding more data that your software should handle is basically the second tet you should write, these fuckign retards did not even do that.
>No, crashing cloudflare is not the desired behavior but mitigation is imo outside the scope of responsability of the proxy ie separation of concerns.
absolutely fucking not, it's a laregely distributed system, any error propagate to every fucking DC around the world, the ONLY correct behavior is to fall back to known working config.
>the dev that used the unwrap understood what the consequence would be, but maybe he didn't understood that the rest of the architecture was broken
then he is a fucking moron, harden every fucking piece of code you write, your code your responsibility.
>would not rollback on top of not validating but exiting with an error when given an invalid broken file is proper behavior.
child behavior
>the adults probably already child-proofed the house for me so I can run around and throw shit on the walls
absoltely disgusting.
>>
File: unwrap_experts.png (3.26 MB, 2000x4000)
3.26 MB
3.26 MB PNG
>>107370623
/g/igger
>>
>>107370863
>You do not understand what memory safety is.
yes I do.
>Rust doesn't let you use a function result without handling possible errors, you can choose to "exit the program with an error" if a result is an err but it's still a form of error handling.
no shit, I was explicitely talking about C... Rust also has a similar system so use that.
>, if this program had been written in c they probably would have overflowed the array like retards, which is worse because UB.
it was previosuly written (partly) in C and it was working just fine.
>There is no point in continuing to run a program if it is functionally useless because it doesn't have what it needs to run, ie invalid config file.
because it was written by smoothbrains, every software that is regularly updated has a known-working state, also it's NOT fucking useless ot run your last working version instead of exiting when 30 FUCKING PERCENT OF THE PLANET IS RELYING ON YOUR SHITWARE.
people don't give a fucking fuck about the config of the software, it has basically 0 impact on their job, it's all part of the blackbox but the ENTIRE FUCKING SYSTEM BEING OFFLINE, that's an issue.
>Sure you could continue running your backend if the db was invalid on startup but that'd be retarded a crash is much better than a silent failure.
use the last backup, duh.

I've written software for critical infrastructure in ada spark, hand-written C and simulink generated C, we ALWAYS AT EVERY POINT IN TIME have the ability to rollback in real-time to a known-working state, dudes like Leslie Lamport have working extensively on the theories behind software that can recover by themselves, it's critical to run the world and any software that graduate from hobby to running the entire fucking world must be updated to reflect its new status as critical infrastructure.
yes you can write robust code in rust and you HAVE TO write robust code if you're the world leadning CDN/proxy/whateve_the_fuck_they_provide_to_users.
>>
>>107370878
>every other fucking errors are recoverable
Not its responsability but the monitoring tool / orchestrator, you do not understand separation of concern.
I'd agree if it was a program updated whilst running but not if it is one started with a config.
> these fuckign retards did not even do that
I'm not disagreeing with them being retard, but again that's not an issue of rust, no programming language can prevent stupid, it can just make things nicer / less error prone.
> the ONLY correct behavior is to fall back to known working config.
Yes, but that's not the the proxy's responsability but the orchestrator's.

Also not in this case but in many reverting to a previous config could have disastrous consequence and lead to data loss / corruption.
It mostly depends of business priorities ie do you care more about correctness or uptime.
If this was banking using an old config pointing to an old db that is gonna be deleted would be unacceptable.

> then he is a fucking moron, harden every fucking piece of code you write, your code your responsibility.

Fair enough, I'm not arguing that he was not a moron but I'm giving the benefit of the doubt in miscommunication, maybe he was told that the file would be always validated before being deployed and that the ci/cd would handle rollback and that it was not his responsibility.

> child behavior
Silent failure is worse and a program immediately crashing on startup allows orchestrator to manage automatic rollbacks.

> absoltely disgusting.
This is what a sane architecture would do, separation of concern.
A proxy shouldn't have to monitor infra health, that's the monitoring software's job.
>>
>>107370780
>unwrap() for error handling
another /g/igger
>>
>>107370982
No programming language is gonna prevent a retard from exiting the program with an error when a failure happened.
Not really rust's fault. The retard knew the consequences of using unwrap it wasn't an "accident".
>>
File: image2.png (66 KB, 1200x742)
66 KB
66 KB PNG
>>107370496
>I've still not seen a convincing argument for why Rust makes software worse for the end user.
It doesn't. There is a reason why all the biggest corpos use Rust more and more. It makes it much easier to write safe software without sacrificing performance. It's also much nicer to work with for the developer.
>>
>>107370828
>>107370623
>>107370780
>t. never heard of assert
>>
>>107370971
> yes I do.
Then you understand that unwrap is not memory unsafe nor UB.
Rust makes it harder to write memory unsafe shit, ie buffer overflow, use after free, race conditions etc.
It does not prevent a dev from choosing to exit the program when an error happens.

Whether it is good design to do so or not is another question but mostly unrelated to rust.
Imo you can have really elegant error handling with "?" and sending errors up the stack.
>>
>>107370685
>rust haters: rust doesn't do what i tell it to do therefore rust is bad
>also rust haters: rust does exactly what i tell it to do therefore rust is bad
See, this is why you're a jeet.
>>
>>107371037
Asserts are only for debugging and don't exist in production because C++ programmers don't make mistakes like pushing a broken untested config.
>>
>>107371025
> It's also much nicer to work with for the developer.
That's the only reason i use it, i used c++ for a decade before using rust, it's just a much nicer language you can be more productive with.
Also less time is spent debugging coworker's race conditions.

Also, this must be the second best reason i've been using it professionally in the last 5 years, it's the only language i never had to deal with a jeet with.
All my colleagues have been straight white men so far, haven't met a tranny irl, i believe they are over represented online because they are attention whore and white men only care about getting shit done and much less so about the upcummies.

Cpp isn't the worse but go has been a jeet fest.
>>
>>107371070
>Asserts are only for debugging and don't exist in production
Kek

>C++ programmers don't make mistakes
Lmao
>>
>>107371070
> C++ programmers don't make mistakes like pushing a broken untested config.

Boy i have news to tell you.
Issues with c++ happen all the fucking time, no one talks about it because we are just used to it.
Whenever there is something with rust even remotely involved it's suddenly becomes the biggest news for 2 weeks.
That information alone should tell you how reliable rust software tend to be.
>>
>>107370496
Only people hating rust are either kikes that like their arbitrary code execution vulnerabilities and jeets that are filtered by it and thus feel threatened by it gaining popularity.
Oh and the eventual boomer cnile that don't want to learn anything new and use strawman arguments to reinforce their own beliefs and reassure themselves.
I've yet to meet a single person that masters the language that dislike it.

Yes there are things i don't like about it but it's overall one of the better ones out there imo.
>>
>>107370878
>wrong, the expected behavior is to warn the user and wait for another file to read.
Holy mother of retarded gui toddler
>only in cmd programs that execute the task and escape
A proxy is generally a cmd program started with a config file as argument.

Even nginx exits with an error if you give it a broken config file.
>>
>>107370780
None of this is relevant to end users though?
>>
>>107371087
>>107371103
I recommend you learn how to avoid formatting your post like a redditor because I don't read redditor posts.
>>
>>107371166
I'm the second you quoted not the first, different authors.
Also newline isn't reddit posting, double newline is.
And i don't use reddit.
>>
>>107371132
this covers all bases. upvoted.
>>
>>107371177
(https://en.wikipedia.org/wiki/You)
>>
>>107371166
>Get thoroughly buttfucked
>resort to posting worthless noise
kill yourself. The cancer killing /g/ right here.

asserts are specifically for production and if you disagree, you're a fucking moron. You use asserts to assert a possible, but extremely unlikely condition.
>>
>>107371079
>>107371103
How much time have you spent debugging panics, like Cloudflare recently did in their Rust code?
https://news.ycombinator.com/item?id=45973709
I know that some Rust projects are diligent with minimizing usage of unwrap(), and prefer expect() or something that does not panic, etc., but there are definitely also Rust projects that are very sloppy about panics and using panicking functions.
>>
>>107371361
>How much time have you spent debugging panics, like Cloudflare recently did in their Rust code?
NTA, I would say less than 3% of my dev time.
>>
>>107371165
no locale support
>>
>>107371346
I wonder why -DNDEBUG replaces assert with nothing if they're meant for production.
>>
>>107371370
that's too much though
it must be
10% writing/debugging/improving the code
30% writing tests
30% documentation
and 30% pr
>>
>>107371370
And how many of those panics were from code running in production? Some Rust projects aim to have zero panics from production code, but that definitely does not hold for all Rust projects.
>>
>>107371380
you're talking to a 15 year old indian kid who doesn't even own a computer
>>
>>107371380
Don't know. Even my Linux kernel has asserts on and it was very helpfulfor debugging problems. Can't fathom what absolute fucking retard would remove them.
>>
>>107370496
It is not the language, but the Rust "community". It is the most obnoxious, violent retards, who call anyone a nazi who doesn't share their views.
>"Stop using [language], it is unsafe, because if the programmer..."
If you read carefully their arguments, this is what their argument always boils down to, "if the programmer..."
So here is a n+1th "safe" programming language that "solves" all the problems and holds the hands of the programmer, even when going to take a piss.
And then everyone acts surprised that retards still can write retarded code.
A retard doesn't need a gun to inflict self harm, somehow they can manage to do it with a fucking paper towel.

Instead of actually teaching how the computer works, lets create another fucking tool, maybe this time retards won't be able to do bad things.

And top of that we got Cargo...
This is what I fucking wanted in back-end, another fucking dependency hell shit, like npm, with all the fucking attack vectors with it.
>>
>>107371399
>low IQ retard will trade correctness and debuggabilty for a 0.001% speed up
Legitimately kek. And you call me a jeet? Maybe you should look in a mirror.
>>
>>107371402
I've been running Linux for almost 3 decades and had a kernel panic for a total of 0 times so far.
>>
>>107370976
>Not its responsability but the monitoring tool / orchestrator, you do not understand separation of concern.
holy mother of cope, the one who write the code is responsible for any bug that arise because of the code.
>>107371037
>assert in prod
just use C++ contracts if you want runtime assert that are designed for prod
>>107371047
>Then you understand that unwrap is not memory unsafe nor UB.
I understand that panicking is bad, if unwrap panic when it can't find some shit then why the fuck would use that?
the panic first mentality is peak brainrot and some idiots designed an entire language around it and called it safe lmao.
>Rust makes it harder to write memory unsafe shit, ie buffer overflow, use after free, race conditions etc.
yeah
>It does not prevent a dev from choosing to exit the program when an error happens.
exactly, that's what C devs have been saying to rustroons since forever.
>Whether it is good design to do so or not is another question but mostly unrelated to rust.
they have option, the entire point of it is to not panic, just like how javasirs are pushing for Optional to avoid null pointer exception, why the hell are rustroon pushing for panic everywhere? it does not make sense if your language is designed to have a main loop and run 24/7/365.
if panicking is the correct behavior then that's a language designed to write one-off program like gnu coreutils or something.
>Imo you can have really elegant error handling with "?" and sending errors up the stack.
yeah, that's the correct behavior in rust, all errors must be handle in code
>>107371164
>Holy mother of retarded gui toddler
as a user I don't want my gui to crash, if vlc can't read a file I want an error pop-up, how is this weird lmao
>A proxy is generally a cmd program started with a config file as argument.
I was talking about command-line like ls or cd taht will exit no matter what you do with them, exiting on success or failure just change the return code
>>
>>107371416
If your code was correct, you wouldn't need asserts, but you're incompetent, and deep down your employers know it too.
>>
>>107370828
>panic and close the software is not unsafe
that's... literally the point. it would be unsafe NOT to close the software, I think for some reason you think safety is a synonym for "don't be annoying"
>>
>>107371361
So i have a rule of using unwrap only for development but removing all occurrence for prod
I do allow except, because you can put a message with it and us sementicaly more intended, i generally use it either on things that can't fail or on things that the program should stop if it did.

Nice thing is that i can just rg unwrap to remove them, I know except is well intended.

Also except will panic just like unwrap, it just adds an extra custom message.
Though panics will tell you the error, where it happened (file, line, column) and a full backtrace if you use the RUST_BACKTRACE=1 env variable so it's not hard to debug imo.
You can also choose to use stuff like catch unwind to catch panics, libraries like actix web do it but you can disable it.
Anyway, the default behavior of panics is something you can change.

Generaly I have my custom error type wrapper that has built-in backtraces and i use "?" a lot, nice thing about it is that as errors are automatically converted to my error type i can impl from such that it adds useful Metadata, ie error kind, errored function arguments etc.
also use a lot of map() or unwrap_or_default().
I think panicking definitely has its uses though, but yea not using "?" is a sloppy way to handle errors.

So far I've not had a rust side error happen i couldn't immediately find with the error message.
>>
>>107370496
>try to force C programmers to adopt a kitchen sink language that takes 109 years to compile
>no, thanks.
>"Ermm what about the end user though???"
Fuck off
>>
>>107371427
What do you think an out of bounds index access is if not an assert? If you don't bounds check (assert), the result is not only incorrect, but potentially fatal.
Not everything can be perfectly expressed in a type system since inevitably the type system becomes turing complete otherwise.
>>
File: 1736073644086896.png (137 KB, 965x623)
137 KB
137 KB PNG
>>107370804
>>
>>107371373
I speak English.
>>
>omg rust bad
>omg c++ is bad too
it's almost like ever programming language is shit and anything advertising their main features are straight up lies. rust devs just never concied they fucked up memory safety and make shitty code while c++ devs know the c++ comitee is full of shit
>>
>>107371424
> the one who write the code is responsible for any bug that arise because of the code.
Why don't you blame the jeet responsible for the broken config instead of the program that was given said config
> the panic first mentality is peak brainrot and some idiots designed an entire language around it and called it safe lmao.

You don't understand rust, you can write code that will never panic, you don't have to ever use unwrap / except / panic

> if panicking is the correct behavior then that's a language designed to write one-off program like gnu coreutils or something.
Again, entirely the dev's choice, you don't have to ever write code that can panic, that's why we have "?" which imo is a very elegant way to handle errors.

> as a user I don't want my gui to crash, if vlc can't read a file I want an error pop-up, how is this weird lmao
We weren't talking about gui, when i mentioned unzip or music player i was talking about cli programs.

> I was talking about command-line like ls or cd taht will exit no matter what you do with them, exiting on success or failure just change the return code

As i said, even nginx will exit with an error if given a bad config file.
>>
>>107371461
My code doesn't check for out of bounds indices at all.
>>
>>107371515
sanest anon itt
>>
>>107371520
And that's because you're literally retarded and your opinion is irrelevant.
>>
>>107371537
No, it's because I'm intelligent and don't perform invalid memory accesses, dipshit.
>>
>>107370496
Syntax is an ungodly mix of Python and C++.
>>
>>107370496
.unwrap()
>>
>>107371543
Most Linux distros compile Linux with _FORTIFY_SOURCE and I have seen dmesg logs of out of bounds access caught. You aren't more intelligent than Linux devs. Kill yourself.
>>
>>107371562
>user input must be validated therefore every memory access should be revalidated just in case I forgot to validate user input specifically
okay rakesh, go smell somewhere else
>>
>>107371554
You are either brown or a nocoder
>>
>>107371571
Yes. Learn to code. If you aren't doing bounds checking, you're doing a disservice to your users and yourself. Even zig encourages release with bounds checking.
>>
>>107370496
recent global outage caused by rust shattered all my confidence in it
>>
>>107371599
I already did the bounds checking right where user input was parsed and I don't care to do it again, jeet.
>>
>>107370496
People who write Software in Rust are based. At least their software performs well, doesn't consume hundreds of megabytes of RAM just idling and won't include hundreds of backdoored NPM dependencies that steal your cookies.

I'd be mad at the people who ship entire web browsers with fucking react shitware that performs like absolute ass instead if I were you.
It's fair to be mad at people who want to replace mature C software like GNU coreutils with a Rust rewrite that's literally in beta, that's irresponsible. Not by the people rewriting coreutils, but by the people who put beta software into production.
>>
>>107371614
As much as i like rust and it has become my main lang i think trying to rewrite everything with it is kinda retarded.
Rewrites should only be done when it is the simpler way to add new functionality imo.
Though I get wanting memory safe(r) replacement for stuff.
Still, i think putting it in the linux kernel is not the best idea, mixed codebases rarely end well.
>>
>>107371614
I'm not. fd heems find-utils. rg is better than grep.
>>
>>107371454
>Also except will panic just like unwrap, it just adds an extra custom message.
>Though panics will tell you the error, where it happened (file, line, column) and a full backtrace if you use the RUST_BACKTRACE=1 env variable so it's not hard to debug imo.
expect(), not except(), sorry. The extra error message would probably have helped Cloudflare debug the major outage more quickly, which is one advantage over unwrap(). And the error message ought to also make it easier in general to read the code, since it (if the message is accurate) should indicate what the circumstances are that can cause it, like a documentation comment.

>You can also choose to use stuff like catch unwind to catch panics, libraries like actix web do it but you can disable it.
catch_unwind() has some limitations AFAIK relative to catching exceptions in most other programming languages, and for panics to unwind, a setting must be set. And if panics are caught and the program must go on, unwind safety, similar to C++ exception safety, has to be considered.

I wish that names of functions in Rust that can panic would be more, not less, verbose than their non-panicking variants. Like, unwrap_or_default() should have been more concise than unwrap(). Some other programming languages have similar faults, but Rust is younger than them, and had a clean slate to go from. Oh well. Some projects do panic a lot, though.

There are anyhow and thiserror, but they have drawbacks. C++ has std::variant, but has no pattern matching and also lack other ergonomics, I believe.
>>
>>107370804
>Also, as i said, unwrap is not unsafe.
NTA, but safety is not generally the same as "memory safety".
"Memory safety" is basically the absence of undefined behavior. A program can be memory safe and also (not the Rust term) unsafe, in the sense that it can for instance unsafely make the lights in an intersection green at the same time due to a logic error, while never having any UB.
Likewise, a programming language might have few or zero memory safety guard rails, like C, but a program written in C might be 100% safe, secure and correct, maybe even proven with formal tools.
Conflating safety and memory safety, or havihg terms that mean different things in overlapping contexts, is unfortunate. What makes it more difficult is that there are not necessarily consensus across programming communities, or even inside a specific programming language community, what different terms mean and what terms should be used.
>>
>>107371814
The correct term is training wheels for nocoders.
>>
>>107371825
>>107371814
>>
>>107371590
>>107371554
>>
File: safe knife.png (761 KB, 952x635)
761 KB
761 KB PNG
>>107370546
We had more knife stabbenings recently so we made knives that can't be used to stab, you cannot cut yourself now.
>>
>>107371458
Poor jeets should stay with C, I agree
>>
File: billy gothic.gif (2.26 MB, 450x253)
2.26 MB
2.26 MB GIF
>>107370496
It's inextricably tied to the hip to MICROSOFT Github, by design, on purpose. Cargo was a antifeature and the chickens are coming home to roost now that the AI data harvesting shit has infested Github to the core. In order for the language to be unfucked, you either need to twist EVERY SINGLE MICRODEPENDENCY AUTHOR'S arm into switching off, or NIH everything yourself and bypass cargo entirely.
No refunds by the way.
>>
>>107371889
>need to twist EVERY SINGLE MICRODEPENDENCY AUTHOR'S arm into switching off
why
>>
>>107371761
> I wish that names of functions in Rust that can panic would be more, not less, verbose than their non-panicking variants.
I understand where you are coming from but I've yet to find a rust devs that thinks it, imo it's fine, all rust devs understand what unwrap does.
>There are anyhow and thiserror, but they have drawbacks
I personally don't use them, i define my own error type and wrote my own macro as a quality of life improvement.
It is a struct that contains a bunch of metadata field and an enum that wraps the error types.

One of my nitpick with rust is that proc_macros are great but i wish you could just use them without having to make a separate crate.
I'm also mildly annoyed when i want to use "?" and await in map closures but you generally can go around it by telling the compiler the type explicitly.
Manually specifying lifetimes when they are obvious is also a bit annoying but i don't have to do it often enough for it to bother me.
>>
>>107370496
Rust is genuinely cozy.
Everyone 'hating' on it is just a Rust programmer being ironic.
>>
>>107371918
thiserror is more just for being lazy desu. Writing the trait impls isn't really that hard desu.
>>
>>107371962
Yea, it's basically just macros for quality of life, reason i don't use it is because it was limiting and i wanted a bunch more things in my error struct.
I also have conditional backtraces and a bunch of other things.

I kinda want to make my error library at some point as rn I'm more copying a snippet between projects.
>>
>>107371944
Yea, idgaf about muh memory safety, it just has really nice features and ecosystem, i enjoy working with it.
Things like serde are also amazing.
>>
>>107371458
>"Ermm what about the end user though???"
Yes??? How has Rust made my computing experience worse?
>>
>>107371554
>>107371552
>>107370623
>>107370780
Is it so difficult for you to read the OP?
>I've still not seen a convincing argument for why Rust makes software worse for the end user
The end user does not engage with the syntax; the end user downloads Mozilla Firefox and browses the web.

How has Rust worsened this?
>>
>>107372129
I compile my browser.
>>
>>107370496
the language is fine, a slightly better c++ with a decent integrated toolchain and a less approachable metaprogramming system (not by much, but still)
the culture surrounding it is awful, inheriting the worst traits of web development culture (overengineering, hysteria, hype)
rust is decent if you approach it like c++ (minimal deps, cohesive monorepo) but shitty if you approach it like typescript (import everything, make 250+ network calls per build)
unfortunately the vocal crowd is mostly from the latter camp
>>
>>107372159
If you're feeding the source straight into a compiler instead of modifying the code then you're not even engaging with the syntax; you're an end user LARPing as a grease monkey.
>>
>>107372129
>The end user does not engage with the syntax; the end user downloads Mozilla Firefox and browses the web.
Except when unwrap() disrupts that browsing for the end user.
>>
>>107372129
><%2 market share
>>
Doesn't have a garbage collector. Is not memory safe.
>but performance
slower than java for most use cases
>>
>>107371392
>that's too much though
[citation needed]

>>107371393
>And how many of those panics were from code running in production?
None. My Rust service has been working uninterrupted since 2020.
>>
>>107371424
>just use C++ contracts if you want runtime assert that are designed for prod
Ok but what does this change in the context of the conversation at hand?
>>
>>107371761
>I wish that names of functions in Rust that can panic would be more, not less, verbose than their non-panicking variants. Like, unwrap_or_default() should have been more concise than unwrap().
Why would you want silently ignoring errors as the default behavior wtf
>>
It's not verifiably memory safe
https://github.com/Speykious/cve-rs
The compiler is self-hosted (not bad) but REQUIRES incremental updating to bootstrap
Still no official spec, nobody is able to replicate the "borrow checker". Mrustc is close but without a spec it's a sisyphean task
>>
>>107372739
>nobody is able to replicate the "borrow checker". Mrustc is close but without a spec it's a sisyphean task
sounds scary
>>
>>107372753
My brain has no spec but can replicate borrow checker without making you wait x10 longer when code is compiling.
>>
>>107372739
>It's not verifiably memory safe
>https://github.com/Speykious/cve-rs
Ada has much worse soundness hole, yet it was never a deal breaker.
>>
>>107371883
You know that blade still looks awfully exposed. You should also implement a way to require you to lift up some kind of guard before you can use the blade with some models that require a key to lift the guard, you know for your own safety, the safety of your children and the safety of the man who sneaks into your kids bedroom at 2am to brutally rape and murder them in front of you while you do nothing.
>>
>>107373034
That's not what we meant by safety, chud.
t. rustrannies
>>
>>107370496

i'm getting suspicious about the so-called near performance of C and C++ personally.
eerytime i have compared ,it's like 1.5x2 comsumption than C equivalent.
>>
>>107373070
Every time you type something like s[0..n], it inserts a branch to a panic.
Did you really expect such cucked language to be competitive with languages that don't baby you?
>>
>>107372995
Then explain why Ada is a failed language lmao
>>
>>107373108
Because people who used it realized that they could just not make mistakes.
But history is bound to repeat itself...
>>
>>107373108
>explain why Ada is a failed language
The burden of proof lies with someone who is making a claim
>>
>>107373070
and theyre comparing against libc implementations with its set of very severe limitations like null terminated strings
also most comparisons are made with all optis enabled on rust, but without -march=native or its equivalent for the libc
and im fairly certain -O3 doesnt enable simd instructions
so its not only vanilla libc
but its fighting with a hand behind its back
>>
>>107372691
Better than Cloudflare then. Or https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
>>
>>107372723
unwrap_or_default() could give an error value, or more complex value, or in a specific situation a default value if that is appropriate. Yes, it has to not be abused.
>>
>>107373070
>eerytime i have compared ,it's like 1.5x2 comsumption than C equivalent.
I have done a lot of benchmarks and I never had any issues matching C performance. You just have to spent some time in godbolt to understand how to write performant code. This applies to every compiled language.
>>
>>107373216
>unwrap_or_default() could give an error value,
That's not what it does.
>>
>>107372739
>Still no official spec
There is the specification from Ferrocene. But last I looked, it honestly seemed both incomplete and fake.

I hope that gccrs will get up and running, though I think that is planned to reuse some of the code from rustc.

And then there is stuff like https://github.com/lcnr/solver-woes/issues

Arguably the worst is that the core Rust community is much less than forthright on this topic. Especially the Rust Foundation is not good on this point.
>>
>>107373275
Depends on the type and its type parameter(s) in question. Option<MyEnum>, with MyEnum being MyEnumValue or MyEnumError, as an example. And there are other functions than unwrap_or_default().
>>
>>107373344
>Depends on the type and its type parameter(s) in question.
Result::<T, E>::unwrap_or_default() returns T
Option::<T>::unwrap_or_default() returns T as well
Result::<T, E>::err() is the method is the one that "gives an error value"
>>
>>107373362
>Option::<T>::unwrap_or_default() returns T as well
And my example covered that. It depends on how it is modeled and used.
>>
>>107373640
No matter how you model it, err() is the function that gives the error value, not unwrap_or_default.
>>
Because it has more unexpected bullshit than C++.
>>
>>107373093
If you think c doesn't baby you, you are a retard.
What even is the stack canary.
>>
>>107374286
>What even is the stack canary.
Something that I cannot find in my binary.
>>
>>107374619
You literally do, you seem to have no idea about how executable work.
Most c programs are compiled with the canary nowadays, and it's considered bad practice not to have one then if it has a slight performance cost.
>>
>>107374662
Even if it has a slight performance cost *
>>
File: pepe-eyeroll-eyeroll.gif (14 KB, 220x220)
14 KB
14 KB GIF
>>107374662
I don't care what midwits consider bad practise, consider proofreading your posts before pressing Post before you evangelize to me about making mistakes.
>>
>>107374758
That's besides the point, I'm tired and going to bed.
Point is, even c programs with default gcc or clang options you will have a stack canary.
Goodnight now.
>>
>>107374787
Gee, good thing only midwits use defaults, meanwhile in Rust there's no option to disable that useless slop at all.
>>
>>107372703
you mentionned assert first you smoothbrain
>>
File: bloat.png (8 KB, 280x108)
8 KB
8 KB PNG
>>
>>107374898
Yea, that c executable seems bloated.
>>
>>107374801
There is, you just showed your ignorance.
>>
>>107374966
There isn't. #![no_std] is a circus, your tranny compiler keeps suiciding constantly about missing eh frames when I don't remember asking for any.
>>
>>107374898
>tcc
>>
>>107375031
tranny c compiler :3
>>
>>107373132
>>107373108
Because bullshit corporate compiler bullshit. Oh wow, we never had this one. How original

>>107370496
In short, there's no other point. The community is it's biggest problem and to an absurd level so. Go to any dev con, you see lots of average nerds. Go to a rust lecture and a tranny will walk up the stage, it's really bizarre.
t.rustnigger, at least it pays decent
>>
>>107370804
>>107370496

it's not even a good language, it's extremely verbose and ugly as fuck.
Large code base are an unreadable trashy mess, so much for complaining about C verbosity and C++ abstraction shit show.
Half the crates are abandoned.
It did the same mistake as Javascript by adding async/await very late.
>>
>>107376578
compilation time is much much worse than C++
>>
>>107373266
with C you remain close to assembly but with Rust abstraction bloat every single line of code can generate shit-ton of assembly
>>
>>107374816
Yes, that's true. I don't see how your preference of C++ contracts over C++ asserts relates to the fact that unwrap in Rust is functionally an assert.
>>
>>107376668
>with C you remain close to assembly but with Rust abstraction bloat every single line of code can generate shit-ton of assembly
Both C and Rust can be made to generate more or less identical LLVM IR. There is nothing you can express in C that you can't express in Rust. Your sense of low level is placebo, both Rust and C are high level systems programming language and are practically equal in terms of performance.
>>
>>107375398
>Because bullshit corporate compiler bullshit. Oh wow, we never had this one. How original
That has nothing to do with the fact that Ada has even worse soundness hole and it was never a deal breaker for them.
>>
>>107373785
Wrong, it does depend on how it is modeled, as shown by my example >>107373344 . One can criticize that modeling, of course.
>>
File: rust2.png (296 KB, 1080x1080)
296 KB
296 KB PNG
>>107376862
>>
>>107377162
ok?
>>
>>107377144
>>>err() is the function that gives the error value, not unwrap_or_default.
>>Wrong
>pub fn err(self) -> Option<E>
>Converts self into an Option<E>, consuming self, and discarding the success value, if any.
https://doc.rust-lang.org/std/result/enum.Result.html#method.err
>pub fn unwrap_or_default(self) -> T
>where T: Default,
>Consumes the self argument then, if Ok, returns the contained value, otherwise if Err, returns the default value for that type.
https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap_or_default
>>
>>107370496
As someone who used Rust on a real project at work my feeling on Rust is generally positive. There are things about the language I don't like, but every language has its problems. The syntax is pretty ugly, I still don't understand every nuance around certain parts of the language with some of the lifetime bullshit, but honestly once you get past the initial learning curve I thought it was pretty good. Performance was good enough, the compiler, while it can be perceived as "strict" was a net positive in the long run. We just weren't dealing with certain types of problems when it came to testing, so that was nice. Type system is pretty good.

Honestly Rust's biggest problem is the community/cult around it. My coworkers who love it are insufferable, they're exactly the kind of Rust people you see online: always bringing up Rust at any possible chance they can, always making fun of other languages and how it should be re-written in Rust. It's just really fucking annoying. No other language has a community/cult like this. If I separate the community/cult from the language I think it's pretty good, but once you interact with the community/cult it can leave a real sour taste in your mouth.

People making fun of the .unwrap() are just retards who don't know what they're talking about. Rust has its problems, but that's not one of them. Maybe there's a debate around a better name for .unwrap(), but I don't care enough to get involved in that. Once you know what .unwrap() is and how much of a code smell it is, there's really no further discussion required. Move onto something that actually matters.
>>
>>107374070
How does this affect end users?
>>
I don't know why people can't see this. Rust is a high friction language where depending on how you architect your code it's either a) smooth sailing with the compiler or b) painfully going against it at every path.
For people asking why novel things are not invented with rust, it's because Rust is menacing for prototyping. Rewrite it in rust just makes sense from a practical standpoint because it makes existing code faster, particularly for things written in shitlangs like python or javascript.
Rewriting existing C/C++ code in rust is an exercise in itself for which the only benefit is "safety" - the rust defn, specifically.
When you rewrite stuff in shitlang like python or js in rust that means you get 80% of the speedup for free just by the factor of rewriting in Rust. It's much easier than rewriting in C/C++ for sure.
>>
>>107376870
Yeah, the door in front of the parking spot has nothing to do with cars not parking there.
>>
>>107377302
And that is a different type, not the one I mentioned.
>>
>>107370623
anyone that makes this arguments outs themselves as a nodev retard
>>
>>107376862
Copy paste any decently abstract rust code beyond low level libraries into godbolt.org and see for yourself how many line of assembly it outputs.
On top of that I can't insist enough how disingenuous the Rust community is when it comes to benchmarking.
>>
File: proxy-image.gif (607 KB, 551x303)
607 KB
607 KB GIF
>>107378511
>anyones thats makes this arguments outs themselves as a nodevs retards
>>
>>107378511
https://news.ycombinator.com/item?id=45973709
>>
>>107372159
That makes you a cooooompilerfag not a user
>>
>>107372129
>The end user does not engage with the syntax; the end user downloads Mozilla Firefox and browses the web.
You're wrong. Bad syntax causes maintainability issues, which can affect the user in the long term. And unwrap is technical debt.
>>
>>107370496
Not really suitable for modern day: not adaptable/refactorable enough, very unproductive compile time. Faster compiles allow for more testing and debuggings etc per day.
>>
>>107370566
If it was really a cpp replacement it would be trivial to rewrite any cpp codebase in rust, but thats simply not the case. If anything it's c with generics and flimsy interfaces.

If you try to rewrite a cpp codebase which heavily uses multiple inheritance, casting and abstract class hierarchies, your in for a lot of pain.
If your cpp codebase uses flat classes with barely any oop features and lots of templates, less so.
>>
i don't have the time to read 150+ comments of drivel in this post-shabbat thread.
if anything relevant was raised by a non-tard, point me to it, and i will give it a look.
>>
panic is just a dumber version of throwing exceptions
>>
>>107370496
rust is not automatically dogshit but the way zoomer devs use it turns a lot of software into bloated jank, main thing is bloat: rust loves generics and 50 crates for hello world, compiler monomorphizes everything so every little Vec<Whatever> gets its own code, you grab clap + serde + tokio and suddenly your dumb cli that would be a 100k C binary is a 10MB static turd, slow cold start on potato boxes, fat containers, wasted ram, all while cargo enjoyers scream "but muh single binary", then there’s borrow checker cope, instead of understanding lifetimes they just spam .clone() on big structs and wrap everything in Arc<Mutex<T>> so rustc stops crying, that creates a ton of useless allocations, refcounting and locks, user only sees high cpu, high ram, random stalls and bad battery because some github warrior didn’t want to think, compiles are slow too so no one wants to refactor or iterate on ux, they hit "works kinda" and freeze the design, result is apps that feel 80% done forever, desktop stuff is extra scuffed because gui libs are all baby tier (egui iced druid etc) or unsafe wrappers over crusty C, so you get weird fonts, broken ime, bad themes, random platform bugs, and async rust is a latency landmine because one blocking call in the wrong place can freeze the whole executor, so you get random lag in "modern" rust apps that’s a pain to debug, on top of that rust is hard enough that half the ecosystem is one dude’s weekend project that never gets maintained, so yeah rust can give you fast stable stuff if the devs actually know what they’re doing, but the way it’s usually used - cargo kitchen sink, clone/Arc spam, async soup, meme guis - absolutely makes things worse for the end user compared to a simple C/go/whatever version
>>
>>107372129
Human beings have to work on the code. If it is illegible therebwill be bugs absolutely everywhere.
>>
>>107379923
You're going to need a better computer. Complaining a binary is 10MB, you aren't actually living in 2025.

Iteration speed is unacceptable though.
>>
>>107375028
I wasn't mentioning no std, you can change panic behavior or remove it altogether.
>>
>>107379938
>>107379923
Compilation is pretty fast actually, most time is spent linking and you can change that by just using mold as a linker.
Add a few tweaks and you can compile in less than half a second.
If you separate your project into crates it can get even faster.

We also now have stuff like subsecond that allows to compile only the changes and binary hotpatch them.

Also you don't need to compile each time, most often cargo check is just enough.
>>
>>107379923
>>107379938
>>107380023
Ah and regarding binary size, the default takes spaces but there are good reasons for it to be the default, however you can absolutely build small binaries / as small as c if you want to.
>>
>>107379930
skill issue, software that can only be read by white men will be better than software that can be read by jeets.

Imo rust is very readable anyway.
It's a language that does take more time than others to learn and master but it is that much more productive once you do.
>>
>>107379938
>rust is slow and bloated because...
>You're going to need a better computer
kek
rustroon mindset in a nutshell
"Just get a better computer because I couldn't be bothered to write code properly"
>>
>>107379938
>Complaining a binary is 10MB, you aren't actually living in 2025.
Yeah dude. Bloat is awesome.
>>
>>107380050
You don't need a better computer, you can compile rust on pm anything.
Most time it's spent on linking anyway, just use a better linker and incremental builds will be near instant, if you use subsecond they will take milliseconds.
>>
>>107380070
Nta but you can make tiny binaries, it's just not the default for good reasons.
But if you want you can make a 300 bytes hello world, even beating c.
>>
>>107378433
Result::unwrap is the one unwrap that everyone is talking about.

>>107379243
>Copy paste any decently abstract rust code beyond low level libraries into godbolt.org and see for yourself how many line of assembly it outputs.
That's literally what I said: >>107373266
>>
>>107379923
>there’s borrow checker cope, instead of understanding lifetimes they just spam .clone() on big structs and wrap everything in Arc<Mutex<T>> so rustc stops crying, that creates a ton of useless allocations,
Cloning big structure behind an Arc does neither allocation nor big clone

Sounds like you need to git gud. All the problems you bring up come from poor understanding of Rust.
>>
>>107380919
I explicitly mentioned Option in >>107373344 .
>>
>>107381102
That is correct, you did mentioned Option. That still doesn't change the fact that unwrap returns the wrapped type, unwrap_or_default returns the wrapped type or its default value by ignoring the error value(or lack of wrapped value in case of Option) and err() is the function that returns the error value.
>>
>>107381134
And I already adressed that in >>107373344 . Do you not comprehend what I wrote?
>>
>>107381235
I comprehend what you wrote. However your attempt to reinvent Result is neither idiomatic nor makes any sense. And no matter what semantic meaning you attach to the values held in Option or variants of Result, doesn't change the reality of the situation. If you have a value that can be error or can be some success value, and in case of an error you choose to still return some default success state and silently ignore error then your program will end up with bugs that are very hard to debug. Errors are meant to be acknowledged, not silenced. That's why, most of the time, unwrap is preferable to unwrap_or_default. Silencing errors leads to hard to very hard to debug bugs.
>>
>>107381308
>leads to hard to very hard to debug bugs.
*leads to bugs that are very hard to debug
>>
>>107379938
>Complaining a binary is 10MB
remind me the size of a L1 cache?
>>
>>107381484
NTA, static vs dynamic linking doesn't change much in context of L1 cache.
>>
>>107380919
>That's literally what I said
he was implying bloat so literally the opposite what of you said, midwit
>>
>>107381542
you sound like one of these twitter retards who throw random words about topic they know jack shit about
>>
>>107370804
>I admit Rust isn't actually more safe than anything it's being used to try to replace, I just like using the language
At least you admit it instead of being a dilusional retard.
>>
>>107381580
>he was implying bloat
Yup, and I said that if you struggle with writing performant code in any compiled language you have to start analyzing asm output(eg by using godbolt) to figure out what you are doing wrong. I also said that Rust can be made to generate pretty much identical IR to C and that there is nothing you can express in C that you can't express in Rust, which means that both these languages can be roughly equal in terms of performance.
If you believe this to be wrong, feel free to post an example C code that uses something that can't be expressed in performing way in Rust, along with your preferred compiler and flags. I will post equivalent code in Rust and we can resolve this with a simple benchmark.

>>107381608
Just because I happen to use a term you are not familiar with does not mean it was random.
The anon who replied to OP claimed that a simple C program grew from 100k to 10MB when rewritten in Rust. This sounds like he has forgotten to take linking strategy into an account. By default C uses dynamic linking and Rust uses static linking, and it's a very common for new Rust programmers to forgot about it when comparing resulting binaries. Similarly, if you are considering cache, especially L1, it is important to remember about dynamically linked code. It does not come for free in this context.
>>
>>107382089
The safety features not being the reason i use it doesn't mean they are not there.
Yes rust is safer than c regarding memory safety, there is no arguing that.
>>
>>107382221
>except it has failed to be memory safe multiple times now, in production
If your logic is that it's the programmer, not the language, then the same logic obviously applies to c or any other langauge you try to replace.
You conflict with yourself, while making the exact same logical arguement people against rust replacing other existing software make. Batshit retarded.
>>
>>107382370
Who are you quoting?
>>
>>107370623
>>107371554
Every language has crash-on-failure features. The nice thing about rust's is you can grep for it. Try grepping for unchecked pointer dereferences in C or uncaught exceptions in C++
>>
>>107381308
So you didn't comprehend my posts, and even reformulate and misrepresent them as well. Please do better, zero-IQ nitwit.
And no, Result is not the only possibility. Apart from Option, one could easily imagine a different and in some ways more complex custom type, like MyEnum with MyEnumSuccess, MyEnumPartialSuccess and MyEnumError. The middle case would have useful values, but would also have warnings or error data, and later users would be forced to handle the different cases.
>>
>>107382895
>The nice thing about rust's is you can grep for it.
That isn't even true, for instance, numeric overflow can panic, and it is not easy to grep for. Rust users do have options there, some hacky work-arounds that disables panics for a crate or something, that enables detection, which is neat in some ways, but has limitations.
>>
File: zero-cost.png (281 KB, 900x966)
281 KB
281 KB PNG
>>107370496
>I've still not seen a convincing argument for why Rust makes software worse for the end user
Ignoring the fact that Rust just so happens to attracts delusional and subpar programmers, in principle it makes software worse for the end user by making programming worse for the programmer.
>>
How can people complain about Rust when C and C++ are infinitely worse?

C++ code is literally unreadable (e.g., templates). Rust code is easy to read and takes maybe a month at most to understand ownership and lifetimes.
>>
>>107384448
>Apart from Option, one could easily imagine a different and in some ways more complex custom type, like MyEnum with MyEnumSuccess, MyEnumPartialSuccess and MyEnumError.
That's not idiomatic. Also, reinventing error handling does not change the fact that unwrap_or_result on Result will silently ignore and error and that's why unwrap is generally preferred. It also does not solve the main issue that errors should have been acknowledged and not silenced.
>>
>>107384474
>Rust users do have options there, some hacky work-arounds that disables panics for a crate or something, that enables detection, which is neat in some ways, but has limitations.
--release is not hacky by meany means and it does not disable panics in general.
>>
>>107384511
From my experience Rust makes programming much better for the programmer.
>>
everything should always be statically linked. I don’t want your binary putting its dirty fingers on my system binaries
>>
>>107385485
>From my experience
Your subjective anecdotes don't matter.
>>
>>107382370
You do not understand what memory safety is nor can point to a single case where it has fail to do so in production, no, unwrap in cloudflare case was not a memory safety issue and if you think it was you are a peak retard.

Also you use a black and white fallacy, i never said it was perfect, but it was much safer.
I could argue that it eliminates 99.99% of memory safety related bugs and you would argue "but muh 0.01% of edge cases, it's not memory safe hurr durr".
I've yet to see a single case of memory safety issue with rust that affected code in production, please show one I'm curious.

But my expectations is that you won't be able to because you do not even understand what memory safety means fucking retard.
>>
>>107385601
> What do you think of rust?
> i think rust is comfy
> muh anecdote
Go back to r3ddit faggot.
>>
Now seriously, I really don't think Rust is a bad language; in fact, I think it's hundreds of times better than Crap++. Obviously, my "for fun" side makes me like C more, but if I had to choose a language to start a more critical project today, I would choose Rust without a second thought, or maybe Ada. The language's design itself makes you program better, but that's for those who are already hurt by years of experience with horrible C++ codebases.
Despite all this, I still like to make fun of religious Rust zealots, they are extremely funny and make the language their entire identity as a person, it's almost cartoonish.
So I 100% support any form of hostility against Rustfags, they deserve it. But to answer objectively, no, Rust is not a bad language, I would even say it's one of the few decent options if you're working at the systems level. Anything outside of that is furry religious craziness. Rust wasn't made to run on the front-end, just as Javascript wasn't made to run on the back-end. People need to stop being fans of language and start looking at things with a more analytical eye. This applies to both sepples and rustrannies.
>>
>>107385601
Let's see some statistics on developer satisfaction then.
https://survey.stackoverflow.co/2024/technology#2-programming-scripting-and-markup-languages
1# most loved language according to GitHub users. Just like it was year ago and year before that and so on. Hmm...
>>
>>107374898
Fucking retarded jeet, you don't even know how a fucking compiler works and still want to spread your poop here. Learn about dynamic and static link, brown jeet nocoder.
>>
>>107379243
>see for yourself how many line of assembly it outputs
Use case for reading raw assembly code? Are you really a developer or just a nocoder repeating the same bullshit you saw on xitter? If you're not working on a very strict environment that literally makes no difference at all.
You're just looking for an excuse to say Rust is ~le bad, literally a cherry-picking that 99.9% of programmers will never have to deal with.
>>
File: file.png (11 KB, 469x189)
11 KB
11 KB PNG
>>107379923
>rust loves generics and 50 crates for hello world
Not everyone is like that, habibi. I created a fucking generic VM that runs almost all Lisps in universe (at least the most popular ones) and I only have picrel as crates.
rand = because Rust sucks
chrono = because Rust sucks
rayon = this one because of my low IQ and because I'm lazy
libloading and libffi = I need to make the Lisp code to interface with C libraries

That's enough to run most Lisps out there, with more performance than Racket, for example. The runtime overhead is almost zero. The only Lisp that currently beats me is Chez, all the other ones are running faster on my VM.
>>
File: OH NO NO NO.png (6 KB, 225x90)
6 KB
6 KB PNG
>>107385843
>muh static link
>>
>>107379809
So rust is cpp without any of the bad stuff. Got it.
>>
>>107386762
Why did you crop out the rest of the screen, /g/igger?
ldd the two statically linked binaries and let's compare them. Just give me the code you used for both if you're that lazy, I will compile them here and show how big of a negro you are. But you won't do that because you're a fucking nocoder nigger.
My suggestion for you: kill yourself.
>>
>>107370496
I've never used Rust, but the Rust community is insufferable, so I make use of my freedom of association, and I don't associate with them.
>>
>>107386869
fn main(){print!("hi\n");}
void puts(char*);int main(){puts("hi");}
Here you go, lazy faggot
>>
>>107384474
No it doesn't. Why do ((you)) people lie on the internet so much? Have you ever even used rust?
>>
File: file.png (102 KB, 1213x1003)
102 KB
102 KB PNG
>>107386916
>>107386762
>>107386869
I don't get it. What's the problem?
It looks the same shit here. What the fuck are you discussing?
>>
>>107386996
Russian plot to keep people using memory unsafe languages. All they do is lie about things that would prevent you from writing vulnerabilities
>>
>>107382198
>feel free to post an example C code that uses something that can't be expressed in performing way in Rust, along with your preferred compiler and flags. I will post equivalent code in Rust and we can resolve this with a simple benchmark.
Write an equivalent to try_dangerous_func in Rust. Your function has to return false if a SIGSEGV happened in the parameter func. Catching the signal and then exiting the program doesn't count.
#include <setjmp.h>
#include <stdio.h>
#include <signal.h>

static sigjmp_buf jmpbuf;

static void
handler(int unused) {
siglongjmp(jmpbuf, 1);
}

static bool
try_dangerous_func(void (*func)(void)) {
if (sigsetjmp(jmpbuf, true)) {
return false;
}
func();
return true;
}

static void
dangerous_func() {
volatile char *vptr = NULL;
char unused = *vptr;
}

int
main() {
struct sigaction act = {
.sa_handler = handler,
};
sigaction(SIGSEGV, &act, NULL);

if (!try_dangerous_func(dangerous_func)) {
printf("caught segfault\n");
} else {
printf("function ran successfully\n");
}

printf("continuing execution\n");
return 0;
}
>>
>>107387152
nta but here, i haven't compiled to test this though

use setjmp::*;
use nix::sys::signal::*;

static mut jmpbuf: sigjmp_buf = unsafe { core::mem::zeroed() };

extern "C" fn handler(_unused: i32) {
unsafe { siglongjmp(&mut jmpbuf as *mut _, 1) };
}

fn try_dangerous_func(func: fn()) -> bool {
if unsafe { sigsetjmp(&mut jmpbuf as *mut _ } != 0 {
false
} else {
func();
true
}
}

fn dangerous_func() [
let vptr = core::ptr::null();
unsafe { vptr.read_volatile() };
}

fn main() {
unsafe { signal(Signal::SIGSEGV, SigHandler::Handler(handler)) }.unwrap();

if try_dangerous_func(dangerous_func) {
println!("function ran successfully");
} else {
println!("caught segfault"):
}

println!("continuing execution");
}

}
>>
>>107387309
>i haven't compiled to test this though
then what are you waiting for?
or do you expect its faulty?
>>
>>107387309
No, you really didn't. Not only does it blow up with a ton of compiler errors, your code also only catches a single segfault since you used signal(2) and not sigaction(2).
Oh btw, setjmp/longjmp are completely undefined behavior in Rust, but perfectly fine in C.
>https://github.com/rust-lang/unsafe-code-guidelines/issues/404
>https://github.com/rust-lang/rfcs/issues/2625
>https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.runtime
Want to try again?
>>
>>107387600
what a faggot
i expected something of the sort
>>107387553

theyre like fucking squid
they let go a cloud of ink to cover their escape
despite being crabs
>>
>>107387600
>Oh btw, setjmp/longjmp are completely undefined behavior in Rust, but perfectly fine in C.
Nah, longjmp is never fine. Occasionally it's the only option, but it sure isn't fine.
>>
>>107387725
>Occasionally it's the only option
This is one of those times.
>but it sure isn't fine.
Still not automatically UB though, unlike Rust.
>>
>>107387600
>Oh btw, setjmp/longjmp are completely undefined behavior in Rust, but perfectly fine in C.

Ohhhh nooooo rust bros. Well now this just makes me believe all the tranny lore
>>
File: 911.jpg (38 KB, 720x720)
38 KB
38 KB JPG
>>107370496
It attracts all kinds of frauds who never learned to code, while it repels competent people who doesn't need toddler wheels.
>>
>>107385473
>>107384448
>>
>>107385482
And I was not referring to -release, but to hacky-yet-somewhat-interesting solutions like https://docs.rs/no-panic/latest/no_panic/ .
>If the function does panic (or the compiler fails to prove that the function cannot panic), the program fails to compile with a linker error that identifies the function name. Let’s trigger that by passing a string that cannot be sliced at the first byte:
>>
>>107386996
>>107387091
You are describing yourself, zero-IQ, mentally ill rustling troll. Off yourself. >>107388545
https://old.reddit.com/r/rust/comments/1d16zys/fix_overflow_panics_without_wrapping_add/l5smpiu/
>huh, interesting. according to the reference, this depends on the configuration option debug_asserions - when on, implementations must panic on overflow, when off, may panic or may wrap (2s compliment).
>This choice was deliberate, so that if in the future, checks were considered cheap enough, they could be turned on universally by default.
>>
>>107388143
Pattern matching isn't bad, though.
>>
>>107388591
Release default config does not panic on over or underflow, even though it should. Such cases are almost always a bug or a security event in the making. Rust provides appropriately named functions for correctly wrapping when needed.
>>
>>107370496
>end user
i don't care about non-programmers
>>
>>107388591
https://doc.rust-lang.org/stable/std/?search=strict
>>
>>107388591
But my rust program has tons of overflows and underflows and it doesn't panic with any hacky work-arounds so I guess you are just lying.
>>
>>107388635
>>107388676
>>107388688

>>107388591
>>
>>107387152
>Derefs null pointer
This is invalid C. Your use case is undefined behavior and wrong by default.
>>
File: oops.png (17 KB, 628x197)
17 KB
17 KB PNG
>>107388688
The liar here is you.
>>
>>107388730
Replace that with anything non-UB that causes a SIGSEGV, SIGBUS, or SIGILL (ie executing an AVX instruction on an unsupported CPU) and my point is unchanged. You still can't catch and recover from those signals in Rust without undefined behavior.
>>
>>107388739
NTA, you have a good point, though there are some details. In release mode, it might not panic, though it isn't guaranteed to not panic >>107388591 . When wrapping is desired, there are wrapping method variants, though they are a bit verbose, like wrapping_add(). There are also some wrapping types, like std::num::Wrapping.
>>
>>107388766
You can't in C either. Everything you listed is UB.
>>
>>107388721

>>107388676
>>
>>107388830
>>107388591
>>
>>107387152
#![feature(thread_local)]
use std::ptr;
use cee_scape::{siglongjmp, SigJmpBufFields};
use nix::sys::signal::{sigaction, SaFlags, SigAction, SigHandler, SigSet, Signal};

enum FuncResult {
Success(u8),
SegFault,
}

unsafe fn try_dangerous_func(func: unsafe fn() -> u8) -> FuncResult {
#[thread_local]
static mut JUMP_BUF: *const SigJmpBufFields = ptr::null_mut();

extern "C" fn handler(_: libc::c_int) { unsafe {
println!("In handler!");

if let Some(env) = JUMP_BUF.as_ref() {
JUMP_BUF = ptr::null();
siglongjmp(env, -1)
}
}}

let result = cee_scape::call_with_sigsetjmp(true, |env| unsafe {
JUMP_BUF = env;
sigaction(Signal::SIGSEGV, &SigAction::new(SigHandler::Handler(handler), SaFlags::empty(), SigSet::empty())).unwrap();
let result = func();
JUMP_BUF = ptr::null();
result as _
});

if result < 0 {
FuncResult::SegFault
} else {
FuncResult::Success(result as u8)
}
}

fn ok_func() -> u8 {
1 + 2
}

unsafe fn segfault_func() -> u8 {
unsafe { ptr::null_mut::<u8>().read() }
}

fn main() { unsafe {
match try_dangerous_func(ok_func) {
FuncResult::Success(result) => println!("function ran successfully: {result}"),
FuncResult::SegFault => println!("caught segfault"),
}
match try_dangerous_func(segfault_func) {
FuncResult::Success(result) => println!("function ran successfully: {result}"),
FuncResult::SegFault => println!("caught segfault"),
}
}}


But what's the point of this exercise if there is no way to reliably measure its performance? Wasn't your point all about Rust being slow? Because now it looks like you are trying to find the most esoteric usecase imaginable instead of doing anything performance critical.
>>
>>107388739
How am I lying?
>>
>>107388842
Not an argument
>>
File: laughing_caprio_jesus.png (266 KB, 400x400)
266 KB
266 KB PNG
>>107388869
(nta)
>extern c
>>
>>107388962
>interfacing with Linux's C API requires C ABI
What a surprise.
>>
>>107388976
it has nothing to do with linux
its a posix interface
its os agnostic
>>
>>107388822
Where's it say this is UB? (SIGILL)
https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=_mm512_xor&ig_expand=7093&techs=AVX_512
Or how about accessing a hardware register and the hardware returns an error (SIGBUS)?
Or calling into an assembly function where accessing address 0 is not UB? (SIGSEGV)

Neither of those are defined in the C standard as being undefined behavior, but they both raise those signals and are useful to recover from.
>>107388869
Using siglongjmp is undefined behavior in Rust. Are you even trying?
Also, printing from a signal handler is bad bad bad.
>But what's the point of this exercise if there is no way to reliably measure its performance? Wasn't your point all about Rust being slow?
I'm not the anon who cared about performance, but you said in >>107382198
>there is nothing you can express in C that you can't express in Rust
and that is wrong. Performance is irrelevant anyway since Rust cannot do this at all without UB.
>>
>>107388936
Is a description of your posts and not my posts, dimwitted, delusional, rustling troll. Off yourself. >>107388591
>>
>>107370496
Long Compilation Times
>>
>>107388976
>>107389012
in case i wasnt explicit enough
its not an os feature, its a language feature
one that doesnt have an equivalent in rust
>>
>>107389016
>Y-you cant express it in rust!
>Poster literally shows you can
Why do you lie? Either way, your use cases are still not C, nor Rust. Executing invalid code (AVX on a CPU without AVX) is literally so UB I don't even know what to tell you.
>>
>>107389012
>it has nothing to do with linux
>its a posix interface
>its os agnostic
It's a C library. So called: libc
>>
>>107389040
>executing UB in Rust is totally okay
>it's only a problem when those evil cniles do it
His code is so literally UB I don't even know what to tell you.
>Executing invalid code (AVX on a CPU without AVX) is literally so UB I don't even know what to tell you.
There's big difference between hardware "undefined" behavior (well defined to run the appropriate kernel code that raises SIGILL) and C undefined behavior (anything can happen).
>>
>>107389059
yes, thats what it is.
what did you mean?
>>
>>107389078
It's irrelevant is the point. Both Rust and C are high level languages which cannot define the behaviors you're even talking about. It's irrelevant. Just because it works in both, doesn't mean anything.

Why are you so retarded?
>>
>>107389016
>Using siglongjmp is undefined behavior in Rust. Are you even trying?
So is dereferencing a null pointer. So?

>Also, printing from a signal handler is bad bad bad.
Only if another signal gets invoked during print.

>>there is nothing you can express in C that you can't express in Rust
>and that is wrong.
I have shown you how you can express this in Rust.

>I'm not the anon who cared about performance
Then your posts are irrelevant. Come back when you have something that can actually be benchmarked.
>>
>>107389092
>what did you mean?
In order to call a function from libc you need to follow c abi.
>>
>>107389116
>I have shown you how you can express this in Rust.
youre not expressing that in rust
youre invoking that in c because you cant express that in rust

god, you crabs are annoying people
(nta btw)
>>
>>107389125
yeah
but the libc is not only a collection of code, its a collection of interfaces to abstract procedures
the jmp procedure is a feature of the language, not that of the os
that feature has no equivalent in rust.
deal with it
>>
>>107389128
>youre not expressing that in rust
My post contains exclusively Rust code which does the same thing as the C code.

>youre invoking that in c
My code doesn't have any C code in it.
>>
>>107389153
oh, and what does "extern c" mean then?
kek
olympic tier of mental gymnastics
>>
>>107389139
I don't use C ABI to execute longjmp. I use C ABI to register a signal handler. Learn to read.
Also longjmp is not expressible in C. It is implemented in assembly and I am calling it from Rust in the same way you call it from C.
>>
>>107389162
I have already explained to you what does extern "C" means.
>>
>>107389116
>Only if another signal gets invoked during print.
Or if the signal was raised in a printing function, which you cannot prevent if this is a library.
>I have shown you how you can express this in Rust.
You haven't. The code you posted is UB that happens to work in your toy example, but will break if you give it a rust function that relies on RAII code running for safety.
>>107389153
>using crates with inline assembly is "exclusively Rust"
kek, who knew that's what "pure Rust" meant
>>
>>107389166
>Also longjmp is not expressible in C.
das where youre wrong kiddo.
because the libc is not only a collection of code
but also a collection of interfaces.

in c you express longjmp by calling longjmp
do you start to understand or do i have to explain it to you in yet another way?
>>
>>107389182
>>Also longjmp is not expressible in C.
>das where youre wrong kiddo.
Post pure-C implementation of longjmp/siglongjmp
>>
>>107389173
youre calling a c interface defined in the standard
thats quite literally using an interface present only in c bc its not present in rust
that you call it "extern c" doesnt change a iota to that
>>
>>107389177
>Or if the signal was raised in a printing function, which you cannot prevent if this is a library.
That signal does not get raised by this print call.

>The code you posted is UB that happens to work in your toy example
Your code invokes UB as well.

>>using crates with inline assembly is "exclusively Rust"
>kek, who knew that's what "pure Rust" meant
libc you called also used inline assembly.
>>
>>107389182
It's not that simple. The c standard puts a very specific list of conditions where you can call those functions and frankly they only exist because of POOSIX brain damage and signal handler specific behaviors. The result is the same either way, rust or otherwise.
>>
>>107389189
That's not what extern "C" means.
>>
>>107389186
longmp();
siglongjmp();

its as fundamental as = or ; or any other symbol.
how the libc deals with it internally is beyond the scope of the standard
the libc could have been implemented in brainfuck as far as the standard cares

sorry for your moving goalposts but theyre dilating off field
>>
>>107389210
This is not a pure-C implementation of longjmp/siglongjmp
>>
>>107389219
???
and the compiler is written in c++, who the fuck cares?
>>
>>107389237
I no longer care. No one cares.
If you have any code that can be benchmarked then post it. Otherwise, this is my last response to you.
>>
>>107370496
>why Rust makes software worse for the end user
Oh that's easy. Cargo is annoying compared to most build systems and the compilation times are long. The language itself is fine though.
>>
>>107389194
>Your code invokes UB as well.
You're entering the "accusal" stage of grief now.
try_dangerous_func doesn't invoke UB, and I had to test it somehow. It'd be no different if I used inline asm which has perfectly defined behavior.
>libc you called also used inline assembly.
Doesn't matter because as >>107389210 is saying, it's a fundamental part of the C language. It's not part of Rust.
>>
File: soulless-pepe-round.jpg (73 KB, 962x962)
73 KB
73 KB JPG
>>107389255
nice digression. im not letting you off the hook that easily though.

this discussion started with rust code that doesnt even compile
revised rust code that does compile but calls to c interfaces
then purity spiraling about the libc
and now benchmarking code?

you know what
lets go back to purity
write an implementation of the original c code in pure rust
using asm or a c interface invalidates your code following YOUR OWN STANDARDS
>>
>>107389016
>Where's it say this is UB? (SIGILL)
>Or how about accessing a hardware register and the hardware returns an error (SIGBUS)?
>Or calling into an assembly function where accessing address 0 is not UB? (SIGSEGV)
Signals are a C/Unix concept that have nothing to do with the hardware or Rust. Windows uses SEH instead, and other operating systems do different things.
>>
>>107389328
its not a c/unix concept its a posix interface
its a model for inter process communication that is something separate from c or unix
even if c is a posix compliant language, and unix was used as blueprint for the posix standard (dont quote me on that)
>>
>>107389210
The irony is compcert c literally says they don't treat them special which can cause you a world of hurt. They really aren't as C as you make them out to be. They're contorted hacks to fit a specific pain point of UNIX. Sadly shitty C programs abuse them and thus rust users can use other means of wrapping or ask to handle those specific use cases.

https://compcert.org/man/manual005.html

See non-local jumps.
>>
>>107389328
Even worse, c defines "signals" but I don't think anyone (sane) uses them, much like how no one uses c threads instead of pthreads or some pthread wrapper over Windows'.

C really is a shit show.
>>
>>107389352
use case for literally who compilers that apparently don't implement the full standard?
>>107389328
Signals and SEH exceptions are the interface given to you by the kernel. Are you saying Rust can't make full use of the operating systems it runs on, but C can?
>>107389350
You're close, but signals already existed in C and Unix when POSIX standardized them.
>>107389366
C threads are really not that bad, anon.
>>
>>107389366
>I don't think anyone (sane) uses them
no, bc its so much better to have a hot loop running, hogging a core for no valid reason at all and checking a value in a shared memory buffer, right?
>>107389352
>i suck therefore you do too
thats literally a (you) problem

never in my life did i need to write a program that needs to catch sigsegv
but someday i might
and rust doesnt have adequate interfaces for that, apparently...
>>
>>107389210
>its as fundamental as = or ; or any other symbol.
Only sizeof and _Generic and a few other things are like that in C. longjmp and siglongjmp are functions (or macros) in C, not fundamental. They have to be written in assembly or some other language outside of C, because you can't do those things in C.
>>
>>107389401
>because you can't do those things in C.
I can though. setjmp() and longjmp()
>>
>>107389401
its an interface defined in the standard.
its as fundamental as anything else.

youre misunderstanding what the c language is
the property of libc interfaces being an integral part of c language's proper is what makes it portable

you cannot have portable code without a degree of abstraction
the libc is that abstraction.
the libc, and more precisely, its interfaces, is an integral part of the c language.
without the libc c loses its portability.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.