is this jeetPT slop?

Rust is a vegan language.

ADA did it right.

>>103207017
The goal of Rust is to create a modern, safe systems programming language, not to replace any specific code or language.

>>103207017
#define nigger unsafe

run it through cpp. fixed.

>>103207017
Rust isn't for what you're talking about. They just say that to build up hype. It's for:
1. Programs that doesn't need the optimizations it prevents you from doing
2. Teams that shouldn't be doing these optimizations because they're constantly fucking up and writing in vulns
Companies like fortinet and pulse SHOULD throw out their code base and replace it with Rust because their pajeets write in so many vulns that they will eventually go bankrupt. Plus there are probably lots of areas where they don't need a blanket unsafe block and a lot of those areas are where they get exploited.

>Surely it would be unsafe to map this datatype to any address other than the one specified in the reference manual, right?
The compiler does not have your reference manual. The compiler does not have a model of what memory on your specific device should look like. The compiler will NEVER have this information, because it is completely impractical to include this for every possible device that will ever be targeted towards the language. So in other words, since it can't verify with its own knowledge that your dereferencing of a raw pointer can in no possible way cause undefined behavior, it has to defer to YOUR knowledge.

The meaning of "unsafe" is "trust me". You are telling the compiler explicitly that you are doing something that it doesn't know is safe. Because what the compiler is trying to do is prove that your program can't corrupt memory. And as it turns out, there's certain things that can't be proven. That is why the unsafe keyword is needed. If the compilation of a program is proof of its correctness, then unsafe code are axioms to that proof. Do you remember taking proofs classes in your undergraduate computer science curriculum? Axioms were the elements of proofs that you assumed to be true in order to make the proof work at all. Similarly, code in unsafe blocks is something that compiler assumes to be safe in order to compile your program.

>>103207017
>Why are users forced to call their driver code unsafe when it interacts with raw memory addresses?
Because writing to random addresses is inherently unsafe. Rustc doesn't know anything about what that address is supposed to mean or if it's mapped correctly. It doesn't know if you're writing to a DMA controller that could stomp all over the rest of the program's memory, or an MMU that could unmap everything, or a power controller that shuts down the system 5 seconds after writing. Your HAL is supposed to provide that information.

>Even worse, why do the read/write_volatile (core library functions, mind you) force the programmer to wrap them in unsafe blocks?
Anything that reads or writes to a raw pointer is considered unsafe, Rust can't verify the pointer is pointing to a valid address as previously mentioned.

>Do I need to check the assembly output?
As good practice you should be doing this anyway to understand your compiler. A read/write of an integer or pointer will compile down to a single instruction as it does in C.

>What does Rust's extra crap actually provide me in this particular case? I could just as easily mess up and map the wrong peripheral model to the wrong address - there's no way for Rust to catch an error like that.
If all the code that actually reads and writes the pointer is confined to unsafe blocks then you can know for certain the bug is somewhere in one of those unsafe blocks. Rust can't solve all safety issues with the hardware, it simply makes it a lot easier to isolate and fix them.

Using the correct primitives here will also allow you to take advantage of Rust's data race safety, preventing threading issues from accessing the peripheral from multiple threads at the same time.

>Frankly, it's patronizing, and cargo new generating a "Hello World" by default is patronizing, too.
Now you're just nitpicking, get over it.

>>103207650
If the compiler has to defer to my knowledge, why am do I have to remind it to "trust me", as you say? I know the design of my firmware and where I'm accessing peripherals from.

I'm not worried about these sort of issues cropping up at compiler time either. If the issue arises from a race condition as >>103207834
touched on, you can just mutex the bus or whatever resource is being demanded. This also makes the code more explicit and adheres to the conventions of whatever RTOS you're using as well. I understand the motivation for unsafe re. formalizing your program, but it's honestly justs wankery. If you know what you're doing, you shouldn't need to call unsafe on anything. dedicated static/ runtime analysis tools will do a better job than any compiler at identifying the sorts of problems "unsafe" is trying to solve anyways.

>>103207637
Rust programmers will disagree with #1.
As for #2, having bad teams change languages is hardly a solution.

>>103207017
Rust's design follows the leftist philosophy of banning things first and figuring everything out later.

>>103208010
>If the compiler has to defer to my knowledge, why am do I have to remind it to "trust me", as you say?
Because once you convert a pointer into a reference then it's considered safe and the compiler can verify all subsequent uses. You're required to provide the first step (ensuring the pointer is valid and doesn't violate aliasing rules) before converting it to a reference, then the compiler can do the rest.

This is unlike C++ where any reference could be hiding a dangling pointer or null dereference and the compiler will always allow it.

>If you know what you're doing, you shouldn't need to call unsafe on anything. dedicated static/ runtime analysis tools will do a better job than any compiler at identifying the sorts of problems "unsafe" is trying to solve anyways.
That's... not really an argument against Rust? Unsafe blocks an annotations are just formalizing some of those static analysis checks into the language itself.

File: Screenshot_20241115_162051.png (44 KB, 758x539)

44 KB PNG

>>103207017

>>103208046
C's design follows the rightist philosophy of gaslighting everyone into accepting its terribleness by labeling all potential alternatives as nefarious leftist conspiracies.

>>103208161
non sequitur, C is simple and works

>>103208210
But it's actually neither. I'll give you a shot though, name all causes of UB listed in the current C23 standard. No cheating by looking it up.

>>103207017
To filter brainlets.

>>103208236
Name all existing C programs that use C23 standard first.

>>103208365
That's unknowable. I'm not asking for years of research into language usage I'm merely asking anon to cite the official language standard since it's so simple according to them. I'll go easy on you, you can also cite any standards versions back to C89 if you remember those better.

>>103208398
I'm asking you to list programs affected by this hypothetical.

>>103208403
There wasn't any hypothetical. I'm simply asking to quote what the actual language standard says. Pick your favorite C program then explain to me what C standard it uses and what that standard says about UB.

>>103208433
Okay so you cannot list any programs, here's my answer then for which parts of C23 can cause UB in existing relevant programs:

>>103208444
So... your argument is C is so bad nobody uses it and thus the standard is irrelevant?

>>103208487
My argument is that you're a retarded nocoder who probably didn't even finish highschool if you think programmers have time to waste on irrelevant trivia like knowing about features they don't use, they can always read about it when they need to since they can read, unlike you.

>>103208593
UB isn't a feature. It's part of the language, you need to know at all times what causes UB in order to write correct code in C. You're seething posting insults and acting like I'm giving you a trick question but I'm not. This is what you need to know to call yourself a C programmer. It's very revealing that you can't do it.
>I can just look it up
I thought the language was simple? Now you need to look up trivia whenever you use it?

>>103208593
True. >>103208433 UB is mostly irrelevant and not a bug, UB means implementation defined, there is only 1 case when it's relevant: memory alignment, signed integer underflow is not important becase all modern processors are using 2's complements and it's now standardized in c23.

>>103208703
>UB means implementation defined
Ah yes, this "simple" language with lots of little pedantic differences depending on what compiler you use.
>signed integer underflow is not important
Aaand this is wrong. UB here means the compiler is allowed to assume the integers won't overflow or underflow. I've seen this cause bad compilations in many, many C codebases.

There's actually lots of other sources of UB, but, as I have been implying, most C programmers can't name them.

>>103207017
See, that's how i know you've never actually used rust, unsafe isn't actually unsafe, most the checks are still there, it only allows you to do two things that you cannot do outside of unsafe.
The reason it is called unsafe is that those two things mean you can do memory corruption if you want.
Thing is over 99% of code doesn't need unsafe and it allows you to focus on the parts that do use it.

>>103208010
>why am do I have to remind it to "trust me", as you say?
You don't have to remind it. You are supposed to build a safe abstraction over it. Look up how other HALs in Rust are made, how they handle peripherial ownership etc. I've been doing esp32 in Rust and didn't had to use any unsafe in my code.

>>103208756
>UB here means the compiler is allowed to assume the integers won't overflow or underflow.
Huh? No.
C23 standardizes twos complement. That means there's no more UB, everything is cleanly defined. And yet addition and subtraction behave exactly as they always have on every real-life platform, and they still overflow just as they always have, and the compiler doesn't do or assume anything extra.
If you want to attack something here, it's not the UB, UB is a strawman, as in most cases.

>>103208756
>UB here means the compiler is allowed to assume the integers won't overflow or underflow. I've seen this cause bad compilations in many, many C codebases.
Yeah, it's irrelevant. C23 mandates the use of 2's complement integers, so it's not UB anymore.

>>103209104
>>103209109
Some anon in this thread said no programs are using C23. So that doesn't matter. It's still UB. If you disagree with that, take it up with that other anon.

>>103209184
No, the point is that signed integer underflow or overflow is very well defined on all the modern platforms even if it's not defined by standard for historical reasons (VAX)-

>>103208210
>C is simple
Lol, lmao even. C is only simple when you don't understand it.

>>103209184
The point is that switching to C23 doesn't make any difference. Before it was UB, in C23 it's not UB, and yet nothing has actually changed in the real world and everything behaves exactly as it had before. UB is not an issue.

>>103208161
>no u

>>103208703
>UB means implementation defined,
Actually they are different things. "Unspecified" is also a different thing in C.
>there is only 1 case when it's relevant: memory alignment, signed integer underflow is not important becase all modern processors are using 2's complements and it's now standardized in c23.
This is mandatory Worse is Better, which is the opposite of how you should design programming languages. C is permanently prevented from ever being able to run on any better hardware designs.

>>103207074
Goud marning, saar.
I got nothing to do with this shit bait, saar.

>>103209516
>better hardware designs
Little endian is the best design. Everyone has converged on it, it's simply better and has no downsides.
Alignment doesn't matter anymore. Both x86 and ARM are slowly transitioning to a status where they suffer NO performance penalty for most unaligned scalar access. (Vector access still sometimes requires alignment.)
Aligned data should be something you should explicitly specify rather than being the default. Imagine wasting 3 bytes per int for "Alignment" lmao

>>103209596
>Little endian is the best design. Everyone has converged on it, it's simply better and has no downsides.
Why do C programmers lack creativity? You want your "committee" to mandate everything just so smart people can't design something better.

>>103209631
Why should everyone bother programming their shit specially to handle your special snowflake bullshit "Big Indian" CPU that hasn't been manufactured since 1995?
Little endian is better because you can just access a Int32 pointer as a Int8 pointer or a Int16 pointer and automatically get a truncated version of the integer. This is very convenient in some situations.
With big indian you lose this ability and you gain nothing except for a very minor human convenience in reading memory dumps because oh wow the bytes are in the "right" order!!!

File: Screenshot_2024-11-17_at_(...).png (56 KB, 1552x369)

56 KB PNG

>>103209104
>>103209217
>C23 standardizes twos complement. That means there's no more UB, everything is cleanly defined.
It is UB Please learn your language.

>>103209217
>>103209253
No, you don't understand how compilers work. UB means the compiler can do whatever it wants. It does not matter one bit what the hardware does. Practically what this means is, the compiler is allowed to delete any dependent statements after it detects signed overflow; because UB means the compiler is allowed to assume this will never happen. There are several compilers that will do this, I personally have had to fix many bugs due to this behavior.

This is just one of the many instances of UB that you'll likely run into day to day writing C and it's sad how posters claiming to be C programmers here still don't understand it. C is just awful.

>>103210138
Yes, this exactly.

File: IMG_3471.png (140 KB, 825x3574)

140 KB PNG

>>103208161
>by labeling all potential alternatives as nefarious leftist conspiracies
yes ,because they are

>>103207323
how

>>103207017
>why are they making it so hard to adopt?
skill issue
Rust is incredibly easy to learn and use. Cargo is miles beyond anything C/C++ has. The entire ecosystem is way more fleshed out despite being so immature still. The language itself is not hard to grasp if you have two braincells.

>>103210420
That's the stupidest thing I've ever read.

>>103210196
>I personally have had to fix many bugs due to this behavior
at mcdonalds?

>>103208067
>This is unlike C++ where any reference could be hiding a dangling pointer or null dereference and the compiler will always allow it.
Rust is eternal training wheel for babies

>>103211660
I've had my fun in my profligate youth pwning systems built almost entirely in C and riddled with overflows and the like. I've long given up the lifestyle, but the steady barrage of similar exploits getting catalogued against major software to this day hints that the programming world could use a lot more training wheels.
Secure by default, or some shit.

>>103211660
>Rust is eternal training wheel for babies
Exactly why it's being pushed so heavily. Why hire one professional who knows what he's doing when you can hire some indians or junior and limit the damage they can do while being productive for a fraction of the cost.

>>103211697
no, it hints that we could use a lot less jeets.

>>103211722
Don't let your prejudices dull your senses.
You don't have to self identity as a disgruntled coder unwilling to embrace incontrovertible advances in programming languages that make it easier to write safe code and removed numerous land mines in the process.
Do not walk down the path to obsolescence.
Well.. COBOL coders get paid super well, so what do I know.

File: Thinking_Face_Emoji-Emoji(...).png (111 KB, 640x640)

111 KB PNG

>>103211660
If the training wheel comes with little to no runtime cost, what exactly is wrong with it?

>>103211914
Aren't Rust's compile times ridiculous whilst also suffering from bloated binaries?
-Jackson

>>103211700
>Why hire one professional who knows what he's doing when you can hire some indians or junior and limit the damage they can do while being productive for a fraction of the cost.
That's actually the whole point of C except C doesn't limit the damage, it just lowers the bar so people think bad software is all that's possible.

>>103211722
>no, it hints that we could use a lot less jeets.
Dennis Ritchie is a jeet by your definition.

File: dc7005ccaaa888bee72527fda(...).png (120 KB, 520x600)

120 KB PNG

>>>103211722
>Don't let your prejudices dull your senses.
>You don't have to self identity as a disgruntled coder unwilling to embrace incontrovertible advances in programming languages that make it easier to write safe code and removed numerous land mines in the process.
>Do not walk down the path to obsolescence.
>Well.. COBOL coders get paid super well, so what do I know.

>>103211943
Hello, Jackson.
Thankfully storage is really cheap these days and any decent workstation compiles Rust just fine.

>>103211966
Also, there's' plenty of ways to reduce binary size. Stripping debug symbols and using link time optimization goes a long way.

>>103208647
I have manpages on my screen, I don't need to know anything, I can literally read about uncommonly used functions I call whenever I need them, you're a retarded nocoder.

>>103211962
I'll take your consolation prize, thank you.

>>103209243
And you somehow managed to find it complex despite not understanding it.

>>103209596
All of my network code assumes little endian machine because I'm not going to waste cycles swapping bytes for imaginary unicorn hardware lol.
Guess how many emails I got from users for whom it didn't work.

>>103212032
6 emails?

>>103212049
None at all, which is odd in corporate setting, surely SOMEONE has a big indian machine?

File: Yet another Rust thread.webm (2.61 MB, 853x480)

2.61 MB WEBM

>>103207017
Problems solved programmically 50 years ago need to be refactored to keep the gravy train running.

>>103212360
They were solved 50 years ago, but then C came along and unsolved the problems.

>>103212375
>First appeared 1972; 52 years ago[2]
Jesus you trannies can't even count.

>>103207017
>hello world is patronizing
Seek mental help

>>103211700
There was multiple C programmers claiming that signed overflow is a well defined behavior in C just few posts above you. If anyone needs training wheels it is C programmers, not the Rust programmers who know C better than them.

>>103211994
You do have to know what is UB or you will encounter miscompilation like shown here >>103210138
UB is not a feature you choose to use or not. And now knowing your language's UB will make you look like a fool in front of anyone who actually understands how compilation works.

>>103207650
should've named it unrestricted or something then

>>103214011
Why come up with different term when other languages like Java or C# already use unsafe for the same thing? It also would be misnomer since unsafe doesn't remove all restrictions, just allows you to call other unsafe functions and do raw pointer read/write.

>>103212389
The problems were solved more than 50 years ago, more than 60 years ago. C gradually took over and made software worse. As C took over, software became worse and a lot of problems and bugs that did not exist before suddenly appeared out of nowhere. The question is why do Russkies want everyone to use C so much? Is C made in Russia? No, so why? Because C is the backdoor.

>>103207017
Don't trust what people here have to say about Rust. According to the Rust experts here, the whole tranny thing is a myth.
https://www.youtube.com/watch?v=uCN_LRcswts

File: 24-Underrepresented_shared.png (50 KB, 1049x377)

50 KB PNG

>>103214702

>>103207365
Swift may have better compatability with existing C/C++ code.

>>103214899
Rust has seamless interop with C. It is possible that Shift has better C++ interop, but that was never the goal. If compatibility is what you are looking for, then Carbon is probably the thing to look for.

>>103212032
That's cope for not having adequate support built into your langauge's std lib

>>103215235
>adequate support
come again when this is fixed, tranny
https://github.com/rust-lang/rust/issues/55614

>>103215266
That isssue is marked as fixed

>>103214743
Why would a trans person in Rust consider themselves underrepresented?

>>103215888
Because trans people like to play victims.

>>103215930
No only white males do that

>>103215963
probably why 99.99999999999998% trannies are white men

File: 1924415663.jpg (64 KB, 1000x750)

64 KB JPG

>>103207017
>the goal of Rust's core developers..
is to troon out.

>>103216111
>Polshitters insist white males are based
>White males actually are all transgender women
>Therefore trans women are based
Finally the truth comes out

>>103216151
Cute selfie, queen

File: blackies.png (296 KB, 792x416)

296 KB PNG

>>103216111
>white men
Anon I...

>>103216174
Is that you and your gf? You gals look nice

>>103216174
thank you for showing us the remaining 0.000000000000002%

File: 81857831-2832068340.jpg (225 KB, 750x600)

225 KB JPG

>>103216227

>>103216205
Uh huh. Tanks, sweet cheeks.
BTW, I'm the one on the right.

>Safety
>In a programming language that doesn't run anywhere but X86_64 and ARM
>two CPUs with multiple known backdoors and full blown UNIX-like OS running Ring -1 beyond the end user's control
>A compiler so bloated and shitty even Gentoo was forced to ship the -bin by default
>A compiler that pulls random code from all over the internet and build time
>A compiler that doesn't even do what it claims to do
>A compiler that builds applications intended to mostly run on a shitty UNIX clone that now has an overly bloated PID1 by default with thousands of "WONTFIX" known exploits
>muh encryption sponsored by the NSA
>A language promoted by retards that can't even figure out if they have a penis or vagina
>A daily thread on a board everyone competent abandoned years ago because moderation became insufferable
>Those people aren't allowed to have one website, forum, mailing list or imageboard ANYWHERE anymore because the hoards of retards that post here now follow them everyone and cry about free speech
>Either agree with me or I'll spam CP all over your board and report you to the glow niggers (just kidding! I'm actually a glow nigger)
>or I'll just drown out all discourse with my army of bots
>your non-backdoor'd hardware doesn't matter
>we must make every machine produced before 2018 obsolete for safety!
>we must include the backdoor for safety! Those crafty terrorists might use these to plot terror!

Can't wait until javascript is bundled into the kernel to. Idiocracy wasn't supposed to be a documentary.

If any of this crap was worth using they wouldn't have had to murder multiple people to ram it through every last FOSS community.

>>103216394
That's a woman
>>103216406
Stay beautiful queen

>>103216426
All of that and it still BTFOs C/C++. Cope.

>>103216446
>Less than two minutes before the bot responds
Dead board.

>>103216452
Cope, it's not bots. The board just killed itself, much like Cniles do after they see the Rust logo.

>>103216465
>all I can do is parrot forced memes
If you aren't a bot you might as well be because you're brain dead. Exactly the type of person that would shill this nonsense for free.

Never any real discourse. Only attempts to attack the author and derail.

File: 1198482645.jpg (107 KB, 1024x576)

107 KB JPG

>>103216429
>UwU

>>103216477
>redditspace
so cniles are reddit?

>>103216477
Your schizo conspiracy theories aren't discourse. Now rope please.

Is there any point at all to learning Rust if I'm not interested in systems programming?
I'm a web/mobilejeet

>>103216484
Confirmed bot. Doesn't even make scene and just spews garbage. The user isn't falling for our propaganda tactics? Just shit the place up then!

Want to talk about any of the points I made here: >>103216426 ?

How is your language "safe" when it runs on a backdoor CPU, pulls random unverified code from all over the internet at build time, uses NSA "encryption", relies on mountains of "unsafe" C code with thousands of known exploits, runs on a kernel written in C, only runs on two platforms (one of which isn't even "tier-1"), and is pushed by an organization directly tied to big tech (aka GLOW NIGGERS).

Of course I do not expect real discourse here. I am only stating these facts again because:
>general boredom
>someone with half a brain might actually read and investigate further instead of falling for your BS
>to piss you off
Seems to be working because you fags get very angry every time I do it. Come to my house again without a warrant "just to talk" please. I like an excuse to waste the Government's time.

Look the bot has already alerted the DoD pod and a real human was forced to respond. My tax money at work.

Fuck you and fuck this cloudflair powered honeypot. Fuck the nip pretending to run the place to. Also fuck the 900 second cool down timer. Never buying a pass. Why would I fund the enemy?

Violence is coming. Useful idiots are the first on the chopping block.

>>103216527
>Retard screeching
>Facts
No, sorry.
There's one way you can escape permanently, it involves a rope.

>>103216527
that's a lot of redditspacing

>>103216426
>>103216527
Least insane cinile.

>>103216527
le mad cnile is le mad

>>103216547
Still waiting for any real discourse

>>103216553
You don't know what reddit spacing is

>>103216556
So now I'm a leftist? Huh. You must be a mind reader. Just how many faggots are monitoring this thread now? It's almost like someone went for blackup.

You fags really hate any mention of those DoD pods don't you? For anyone lurking. Google: "Department of Defense Interactive Internet Activities". You'll find one pdf file from 2007 that describes the program and nothing else. You won't find anything else because they've murdered everyone that has exposed it and documented it.

>>103216580
I'll give you discourse when you rope. This is a bargain for you.

>>103216587
Less than a minute this time. Someone is mad.

DEPARTMENT OF DEFENSE INTERACTIVE INTERNET ACTIVITIES. All the information you need to know why everything on the internet went to shit in 2007.

>>103216527
>How is your language "safe" when it runs on a backdoor CPU, pulls random unverified code from all over the internet at build time, uses NSA "encryption", relies on mountains of "unsafe" C code with thousands of known exploits, runs on a kernel written in C, only runs on two platforms (one of which isn't even "tier-1"), and is pushed by an organization directly tied to big tech (aka GLOW NIGGERS).
Thank (You) for admitting that Rust is better than C.

>>103216595
>He doesn't know about the auto update button
You really have to rope, it's the only escape from being as mentally fucked as you are.

I'm sure Rust devs run Arch but I hope they realize that there's also a real need for stable LTS distros. Important shit on a server should work for years, without downtime, with the distro maintainers providing security updates when necessary. Then a new stable release comes out and you switch to it and everything keeps working.

Suppose Rust displaces the entire C ecosystem and the average Linux distro becomes 90% Rust. Every program is a soup of hundreds of dependencies, each program specifying different versions. This is how Rust works today, it's embedded in the culture, it's not likely to change.

Imagine the work of stable distro maintainers. How are they supposed to deal with this? Let's say a vulnerability is found in a common library. Do you have to go through every package on the system and separately verify that the package uses a version where the vulnerability is fixed? It becomes an intractable problem that Rust is not prepared to deal with.

The webshit culture of rapidly moving deeply nested dependencies works great for hobby projects. But it's fundamentally incompatible with system software. This is why Debian maintainers threw out bcachefs, and it will keep happening to other Rust packages. Rust devs don't even see the issue, because hobby projects are all they know. They think Cargo.lock is a blessing and everyone should be happy with exactly specified dependencies, even if it comes at a cost of an overall unmaintainable system.

>>103216606
>>103216610
DoD pods shitting up every last discussion platform on the internet; https://sgp.fas.org/othergov/dod/dod060807.pdf

>>103216633
>Suppose Rust displaces the entire C ecosystem and the average Linux distro becomes 90% Rust. Every program is a soup of hundreds of dependencies, each program specifying different versions. This is how Rust works today, it's embedded in the culture, it's not likely to change.
That's how Linux already is.

>Imagine the work of stable distro maintainers. How are they supposed to deal with this? Let's say a vulnerability is found in a common library. Do you have to go through every package on the system and separately verify that the package uses a version where the vulnerability is fixed? It becomes an intractable problem that Rust is not prepared to deal with.
Do you know how Linux package managers work? You're describing the same way Linux works now.

>>103216649
I will read that when you rope. Snap snap anon, time to hold up your end of the deal. Live stream it on faceboook so we can watch.

>>103216672
Is liveleak still a thing?

>>103216669
No, it's not how stable Linux distros work. The maintainers actively try to keep the number of library versions to the minimum, sometimes even by editing the packages to make sure they work with those versions. They try to do this in Rust too but it's a losing battle.

>>103216633
>Rust is bad because it has packages and dependencies
Cniles really stretching again to come up with any argument

>>103216700
sounds like they just suck at rust, git gud scrub

>>103216709
>>103216718
As I said, hobby projects are all you guys know so you even fail to see the problem. But it's a real problem that will prevent Rust adoption.

https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools

>>103216745
>Moronix
Opinion disregarded

>>103216762
>resorts to ad hominem because he has no real argument
I'm sorry, webshitter package management will never work in systems programming that's supposed to be stable for years at a time. If Rust wants to be taken seriously as a systems language they need to write their software without a billion dependencies. If you're writing a library it shouldn't have a million different dependencies that all have a million different dependencies that all have a million different dependencies.

>>103216835
>If Rust wants to be taken seriously as a systems language they need to write their software without a billion dependencies. If you're writing a library it shouldn't have a million different dependencies that all have a million different dependencies that all have a million different dependencies.
Why is it good when C does it?

>>103216835
I'm sorry but you're a deeply unserious person. Reminder the Cnile "solution" to that problem is copying 1000 header-only libraries into your project so you can claim it has "no dependencies" but this is literally just the same thing as rust but worse and shitty distros like debian just accept it

>>103216852
C code doesn't do it. Go to your /usr/lib and see how many versions of libraries you have. If you're on Debian/Ubuntu, it will likely be around one per library.

>>103216922
The alternate versions are hidden. See >>103216878

File: 07d4d711a5072f299fc80cd86(...).jpg (46 KB, 677x680)

46 KB JPG

>>103216506
Low latency servers

>>103217915
go solved that problem

File: Screenshot 2024-11-08 at (...).png (151 KB, 1280x1368)

151 KB PNG

>>103217976
No it hasn't.

>>103218068
Those dotnet scores are embarrassing. How can it be slower than Python?

>>103218068
>Go avg duration: 1.77ms
>python: 3.31ms
>C++: 3.90ms
>rust: 4.96ms
Rust/C++ bros??

>>103218248
>avg duration

>>103216852
>>103216878
Using libraries itself isn't bad. It's bad when the libraries also use a million different dependencies. With an npm or cargo style system you get lazy or retarded devs using libraries for the most mundane shit. It even encourages that. isOdd/isEven/leftpad kinda shit. And then some dev that gets their panties twisted decides to nuke their package that is like 5 loc and it destroys the build process for everyone because it's a dependency through some way in literally everything.

>>103219279
C and C++ did it first with header only libraries and shit like boost

>>103219306
No one would ever use leftpad in C.
But they absolutely will in Rust. The culture encourages it.

>>103220103
>C
No one uses this.
As for C++ it's even worse that Rust, I've seen people bring in giant boost libraries for 2 macros

>>103220120
unironically this, people complain about rust projects pulling in 100s of microdependencies. But boost asio unironically pulls the whole boost library collection.

File: Left-pad_0.0.3_contents.png (61 KB, 578x700)

61 KB PNG

>>103220120
The problem is not bringing in a library for 2 macros, the problem is the existence of things like leftpad. Leftpad was a npm package with just one function that pads a string to a given length, picrel is its entire contents. Such a package would never exist in C++, but in npm it was used by every major tech company along with hundreds of similar packages. And the same will happen in Rust, people will create packages for every tiny thing. A giant library has a maintainer, leftpad is just something someone coded in an afternoon and forgot about, but people use it, other people use stuff that uses it, and so on until it becomes inextricably integrated into the ecosystem. Just think a few years ahead if you still don't see a problem with this approach being used for system software instead of webshit.

>>103220178
Boost has existed for 25 years and has 164 libraries. Don't act like it's the same thing. Crates.io has 162,488.

Average crates.io package: https://crates.io/crates/app-cli
>1,117 downloads

I like my code to match my intel processor and my underwear

>>103221495
why am I supposed to be outraged by this?

>>103220103
True and real.
>>103220120
Get the fuck out of here and never come back.

>>103221495
>Sonu Kumar
good morning saars

>>103216426
>Can't wait until javascript is bundled into the kernel to. Idiocracy wasn't supposed to be a documentary.
No, the documentary you're thinking of is "The Birth and Death of Javascript".

>>103219279
Or worse still, a malicious actor takes control of the repo and puts vulnerabilities into the package which is then distributed to millions of builds. This isn't unprecedented.

Typescript is a better language than Rust. Change my mind.

No matter how long its been since i last visit /g/ nocoders making language hate threads will always be there.

>>103220120
>No one uses this.
more companies use C than Rust

>>103220286
The other half of the leftpad story, and a perfect object lesson as to why this is all a terrible idea, is of course that its developer decided to delete all his published packages from npm after npm unilaterally took away another one of his package names to give it to some random company to sidestep potential trademark legal issues.
Granted, the basic anti-pattern was compounded by just several bad policies on the repository side, but still.
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code

Rust sucks. I use C and C++ exclusively for speed.

>>103222170
exactly, that will happen in rust

>>103216878
>>103216939
that never happened

>>103222238
You can't delete crates from crates.io without getting reviewed by the cargo team

>>103223450
How are they going to prevent someone adding malicious code to a popular package?

>>103223536
they would delete that

>>103222198
I use Python for speed and Ruby when speed isn't needed.

>>103221862
Typescript is not a language, it’s a linter.

>>103216426
Based and redpilled

>>103214011
why?
if you can't understand words having different meaning in different contexts you're too stupid for programming anyway

>>103216426
>safety
>starts ranting about security
another brainlet with not enough grey matter to hold the meaning for more than one word starting with s

>>103223603
When are they going to delete it? And what are they going to replace it with without breaking the package and all other packages that rely on that dependency?

Also who is going to notice it before it's out there in a lot of builds? It's very easy to hide malicious code into your packages with a microdependency model. You wouldn't do it into the package you want to inject it into itself but some other package that is then used through some dependency in your package. Even if someone goes through your package they won't notice it. They'd only notice it if they went through the entire dependency tree and figured out it's malicious code. And there isn't a single person who is going to audit the entire dependency tree of their software.

You also add it to be part of some functionality you really need. So they can't just remove the malicious package without also breaking your target package and every piece of software that depends on your target package.

>>103224128
read their policies or ask them yourself. not wasting my time with your retarded concern trolling

>>103216633
Even arch RIGHT NOW can't keep up updating their shit and went from bleeding edge to just regular rolling release
One fucking dude went MIA and they couldn't update libc/gcc for almost an entire year
Believe or not, having the OS itself vet every single fucking program or library users want is unsustainable, no matter the language
Imagine if microsoft did this for every program. It sounds ridiculous, it's not fucking possible, you instinctively know there's MILLIONS of decade+ old programs and there isn't a group of people on earth with enough manpower to upkeep all of it. Shit just needs to continue working. You don't think the same way when it comes to linux because old programs breaking is a guarantee, unless they've been blessed by the distro jannies and put in the official repos
This is why there won't be a year of the linux desktop, not with the current distro model, it lacks stability and requires unsustainable amount of work just to maintain itself. Imagine if all that package janny churn was replaced with actually improving shit

>>103216669
yea, but but millions of manhours wasted in MY language > millions of manhours wasted in YOUR language

https://repology.org/repositories/statistics
arch - 19% outdated