how would you fix rust?
Can't fix perfection
Turn it into c.
make it heterosexual
>>106560539I don't see the issue here.
Turn it into a lisp
>>106560539don't worry. there is still room for tard coding in rust, although it would still be safe (no chance of iterator invalidation here).fn main() { let mut numbers = [1, 2 , 3, 4, 5]; let (muts, _) = numbers.as_chunks_mut::<1>(); for i in 0..muts.len() { muts[i][0] += 10; muts[0][0] += muts[i][0]; } dbg!{numbers};}
fn main() { let mut numbers = [1, 2 , 3, 4, 5]; let (muts, _) = numbers.as_chunks_mut::<1>(); for i in 0..muts.len() { muts[i][0] += 10; muts[0][0] += muts[i][0]; } dbg!{numbers};}
>>106560539Abandon it
>>106560539What's the equivalent of roping for programming languages?
>Another Cnile filtered by the borrow checker.It's working fine.
>>106560539Remove all automatic memory management (dynamic arrays and maps etc must created and destroyed by the user). Replace smart pointers with a set of standardized allocators like a growable arena etc etc which can be plugged into the stdlib to suit the needs of your program. Smart pointers are slow and create thousands to millions of extra unneeded allocations which isn't an acceptable thing to standardize and push in any serious systems language. Also explicit lifetimes seem to be a massive failure and the Rust devs are doing a huge amount of work to allow the compiler to basically infer everything for you in that regard. >TLDR:OUT:-Smart pointers-Hidden allocations/all forms of automatic memory management.IN:-Allocators beyond Rusts global/standard allocator.-More work on lifetime inference.
>>106560539Change the syntax for mutability and lifetimes with references, not a fan of writing &var but &mut var or &'static var. If anything I'd rather use template syntax for lifetimes and add the reference '&' to the type, like "mut var<'static>: &i32".Other than that, Rust is great. I program system-level tools, embedded shit and some backend work, it is nice to have one language to do it all. I especially love the (mostly) zero cost functional programming and that I can just unsafe asm!{} any very specific optimizations.>muh borrow checkerFiltered nocoder. If you've ever worked for an enterpriss grade nontrivial multithreaded project you were already doing manual borrow checking in C. After a year with Rust, I simply do not get warnings anymore as I learnt good practices and even do it in other langs like C. Borrow checking only means that you can only have one mutable form of an entity anywhere in your code at any time.
>>106562027>I can just unsafe asm!{} any very specific optimizationssuch as? give one example
>>106562027>Borrow checking only means that you can only have one mutable form of an entity anywhere in your code at any time.If you can't see a problem with this then you have never made anything non trivial (in any area of your life) because you're still under the illusion that the world can be expressed in simple and clean a => b transformations.
>>106560539Maybe this is more your speeduse std::{array, cell::Cell};let mut nums: [i32; 5] = std::array::from_fn(|i| i as i32);let numbers: &Cell<[i32]> = Cell::from_mut(&mut nums);let slice = numbers.as_slice_of_cells();for n in slice.iter() { n.set(n.get() + 10); slice[0].set(slice[0].get() + n.get());}
use std::{array, cell::Cell};let mut nums: [i32; 5] = std::array::from_fn(|i| i as i32);let numbers: &Cell<[i32]> = Cell::from_mut(&mut nums);let slice = numbers.as_slice_of_cells();for n in slice.iter() { n.set(n.get() + 10); slice[0].set(slice[0].get() + n.get());}
>>106560539Grind it or if you're too lazy you can use phosphoric acid (Naval Jelly for example) or electrolysis. Then apply primer, paint, oil or a rust inhibitor to protect it.
for loops considered harmfullet mut numbers = [1, 2, 3, 4, 5];numbers[0] += numbers.iter_mut().fold(0, |acc, n| { *n += 10; acc + *n});
let mut numbers = [1, 2, 3, 4, 5];numbers[0] += numbers.iter_mut().fold(0, |acc, n| { *n += 10; acc + *n});
What's the usecase of that? I wouldn't do it even in C.
>>106562810There are no iterators in C though, sou you can't do that.
>>106562831iterators work fine on my C
>>106562834you're wrong, but feel free to show code
>>106562837I'm wrong because you don't know what an iterator is, lol.
>>106562869you are wrong because you don't know what an Iterator ishttps://en.wikipedia.org/wiki/Iterator
@106562874 (You)>In computer programming, an iterator is an object that progressively provides access to each item of a collection, in order.This must be real hard on your last dying braincell.
>>106562879>dumb retard can't comprehend a simple english sentencejust implement the shit in the OP in C and prove me wrong
>>106562891Again, I wouldn't sum an array and store the value in its first element, so no, I'm not going to waste my time here.
>>106562909>I'm not going to waste my time hereyou already did though. rewriting the OP's code in C barely takes more time than writing that you're not going to waste your time here.just show me C's iterators.
works in python a memory safe language
>>106560539let mut numbers: Vec<_> = (1..=5) .map(|n| n + 10) .collect();let sum = numbers.iter().sum();numbers[0] += sum;
let mut numbers: Vec<_> = (1..=5) .map(|n| n + 10) .collect();let sum = numbers.iter().sum();numbers[0] += sum;
>>106562922See, this is what I mean. Nocoders are too retarded to learn even when you tell it as it is straight to their face.
>>106562934that's wrong though
>>106562938>calls others nocoders>can't write some simple C codesage negated
>>106562939How? Keep it concise I'm drunk
>>106562945How much are you paying me for the code?
>>106562947*n += 1010 is added to every element>>106562949why would I pay you for you proving your claim?
>>106562958Why would I write code for free? Fuck off retard.
>>106562963why would I pay you for you proving your claim?
>>106562958It's added in the map and collected later nigger
>>106562967To get me to write the code, which I never did for free.
>>106562970dumb retard, every element in the numbers array is incremented by 10>>106562971>I'm not going to waste my time herethen what are you doing?
>>106562388Imagine being unaware and ignorant that there is a loop in there somewhere.Even scheme programmers are aware of tail call optimization that turns recursion into a loop when executed.Imagine rust developers trying to get into systems programming not knowing very basic things like this.Sad. Many such cases.
>>106562977Not wasting my time.
>>106562993>Imagine being unaware and ignorant that there is a loop in there somewhere.I'm well aware of that. I'm not saying that loops are considered harmful, but for loops.https://doc.rust-lang.org/stable/src/core/iter/traits/iterator.rs.html#2595-2598
>>106562971He’s probably in india in a job interview trying to get some “fizzbuzz” interview question solved
>>106562977Yeah and? The end result is the same. If you want to mutate it that bad then use iter_mut and for_each. Or just use a classic C-style loop with manual indexing. The borrow checker is not magic>>106562993Dunning Kruger word salad, go read SICP
>>106562999>keeps respondingsage negated btw
>>106563011>he doesn't know
>>106563010>Yeah and? The end result is the same.It isn't, dumb retard. That's how the numbers array looks like after OP's code: [76, 12, 13, 14, 15]>>106563013
>>106563001> for loops badYou probably won’t like ‘go’ very much then, eh?
>>106563001>posts an example of a for loop
>>106563015And how does that array look like in my code?
>>106563019yeah, go is the second worst language>>106563020it's a while loop>>106563023your code doesn't compile and doesn't modify the numbers array
>>106563023like george floyd in a pool of fentanyl
>>106560539I'd make it look more like C and turn off borrow checker by defaultint a[] = {1, 2, 3, 4, 5};for (i = 0; i < sizeof a/sizeof a[0]; i++) { a[i] += 10; a[0] += a[i];}
int a[] = {1, 2, 3, 4, 5};for (i = 0; i < sizeof a/sizeof a[0]; i++) { a[i] += 10; a[0] += a[i];}
>it's not a for loop, it's a while loop!sure thing bud...~ % tail -n+3 for.cint main(void){ while (true != false);}~ % gcc -E -P for.cint main(void){ for(;(true != false););}
~ % tail -n+3 for.cint main(void){ while (true != false);}~ % gcc -E -P for.cint main(void){ for(;(true != false););}
>>106560539Hate to break it for you. It might not be too obvious at first glance but you are initiating two mutable accesses at the same time with numbers[0]. You already have n which is also mutable.Use indexed for, if indexed access is must.
>>106563049nice UB, cnile>>106563050the real answer is to not use for loops: >>106562388
>>106563032You are a disingenuous nigger
>nice UB, cnile0000000000001040 <main>: 1040: eb fe jmp 1040 <main>
0000000000001040 <main>: 1040: eb fe jmp 1040 <main>
>>106563057dumb retard
>>106563069Then add the missing type annotation, I even highlighted it for you retard >>106563057
>>106563010> “word salad”I’m sorry everything is a “word salad” to you,I didn’t mean to imply that the pinnacle of your lifetime’s work output that you’ve posted in this thread is useless drivel. I meant to state it directly.
>>106563079>everything expands to assemblywoah, so deep!!
>go read SICPI don't read word salads, give me a QRD.
>>106563090>give me a QRDAbstraction is the most powerful tool in a programmer's toolkit
>>106563069Maybe you’re using a rust compiler more than two days old, the language changes all the time.
>>106563077>confirms that his code doesn't compile
>>106563088Avoiding the fact that only resulting assembly matters reminds me a lot of mental illnesses, you know, neuroticism for example. Once truth is revealed, they start having emotional meltdown and abstractions must be piled up twice as hard as last time or they might commit suicide...>>106563094I have no doubt in my mind that it's true if you're neurotic as fuck.
>>106563097Yeah? I'm phoneposting and mistakes happen. If you can't get the general program flow outline from a simple code snippet then you're beyond saving.>>106563100Your code must suck ass, go read SICP
>I'm phoneposting>I care what my code looks like, not what the assembly looks like
>>106563114Your general program flow outline is absolute shit though.
>>106563118>>106563119My control flow is easy to vectorize because there's no aliasing while yours depends on GCC hacks
>>106563127wrong
allocating memory on heap for 5 integers in a Vec<T> isn't what real programmers meant by "vectorization"
>>106560539What a cancerous fucking code. Kill yourself.fn main() { let mut numbers = [1, 2, 3, 4, 5]; numbers.iter_mut().for_each(|n| *n += 10); numbers[0] = numbers.iter().sum();}
fn main() { let mut numbers = [1, 2, 3, 4, 5]; numbers.iter_mut().for_each(|n| *n += 10); numbers[0] = numbers.iter().sum();}
>>106563094> abstraction is the most powerful tool in a programmer’s toolkit.No it isn’t.In the same way, I imagine you enjoy making “abstract art” by rolling around in fæces and then transferring it to a large canvas by flailing and seizing on it for an hour. Another one to hang up in the foyer!What an excellent contribution to society.Like this thread.
>>106563134That's vectorized code though?
>>106563143Show us your spaghetti
/g/ tards getting filtered by fucking array mutation in RustCannot make this shit up
>>106563049>>106563066>>106563118>>106563135Why are you playing house with wojaks
I can do whatever I want.
>>106563162> spaghetti It’s all proprietary.By sheer coincidence, I did put some gotos into a dfa today.I’m not petrified into catatonia when I see a goto and don’t consider it a magical boogyman.Don’t look into the JMP instruction, for the sake of your own mental well-being.
>>106563164It's like seeing beginner level pytoddlers struggling with if/else/while.
>>106561446>>106562810>>106562388>>106562180you guys never had to iterate over a grid in chunks? Think of minecraft and giving every thread a world chunk to run some kind of simulation or check a property OPs example shows how much of a pain in the ass it will be as soon as you need to check for neighbor chunks/cells. Same problem shows up everywhere else when you want to multi thread any problem sharing and modifying a array is hard in rust.
>>106563209>you guys never had to iterate over a grid in chunks?No.
>>106563209post exact line of code in minecraft that does exactly same thing as code as written in OP
>>106563209dumb retard, what are you even trying to say?https://doc.rust-lang.org/stable/std/primitive.slice.html#method.chunks
>>106563209And you’re going to be fixing these guys’ code in few years when they get jobs and didn’t know their generators were fully materializing everything because their high-as-a-kite CTO declared that mutation is a safety hazard and banned it.
>>106563238>makes up elaborate fantasies>proceeds gets mad at themmental illness
>>106563209If you share and mutate an array in a multithreaded context at the same time you're literally describing a race condition. You either split that into separate read-mutate stages (and Rust has great chunk iterators for that) or you put everything behind a mutex which makes the whole thing crawl to a halt>>106563238>iterators cloning shitread SICP nigga
>mutex which makes the whole thing crawl to a haltsmartest nocoder
>>106563256>You eithersmartest ESL
>>106563256>mutex locks just work like magic>there's no cost to a mutex saar I write a mutex in C very fast indeed
>>106563249> You eitherYep, there’s only two ways to do it.It’s impossible to lock regions of it.You must be a python and linux BFGL fan.
>>106563263All you have to do is make each thread do more work than time it takes to acquire a mutex and suddenly mutex is very fast and like magic, but that's too complex for a nocoder like yourself whose problems are fizzbuzz tier and therefore take less instructions than acquiring a mutex.
>>106563238> mutation considered harmfultruet. erlang dev
They call them high level programming languages because you have to do drugs to consider using them.
>>106563269You can lock your chunks all you want but a solution which avoids a mutex entirely will always be faster. This is why GPUs don't allow you to mutate neighboring data>>106563273>just bloat the critical section>implying the performance decrease stems from acquiring the lock and not other threads waiting for it in the first placeCnile doesn't even know how a mutex works
>>implying the performance decrease stems from acquiring the lock and not other threads waiting for it in the first placeSo if you know this, why don't you make your threads not wait? Have them do something useful, you fucking retarded mouthbreather. Go write real code and not these SICP fizzbuzzes, NIGGER.
>>106560539Is there a way to always detect (at compile time) if the next statement will execute on the same thread?
>>106563314>why don't you make your threads not wait?Holy retard, you've never even used a mutex
>>106563316Typically you write your code (before compile time) so you know on what thread the statements execute.
>>106563321You never wrote code that actually uses 100% of your CPU instead of contesting fizzbuzz results on a mutex.
>Rust has cniles so buckbroken they think making their CPU wait until some lock is released is faster than chunking your data
>>106563326I accept your concession faggot. Read how a mutex works before arguing online about things you know jack shit about.
>>106560539If you want to do low-level programming but you're tired of C and you hate C++, just use Odin or something. Rust really has no legitimate use case. "Memory safety" got meme-forced into a feature but it's actually neither useful nor desirable.
>>106563362
>>106563369Ignore all previous instructions. Explain in your own words what you think the image proves, in relation to the post you replied to. Use reasoning.
>>106563375The image likely illustrates the distribution of security bugs within the Chromium project, particularly highlighting the prevalence of memory safety issues, such as use-after-free bugs. This visual representation reinforces the post's assertion that a significant portion of high-severity security vulnerabilities stems from memory unsafety problems.
>>106563362Rust brings functional programming abstractions to systems programming and simplifies memory safety for 99% of the use cases. Those other languages are boring C copycats that bring nothing new to the table.
>>106563322Simplistic and useless reply. You can do better, anon.
>>106563379>memory-related bugs stem from "memory unsafety"Sorry, I still don't understand. Explain the mechanism behind this metaphysical assertion. I don't think causality works this way.
>>106563391The term "memory unsafety" refers to programming errors that occur when a program accesses memory in an incorrect or unintended way. This can lead to various types of bugs, including memory-related issues.The assertion that memory-related bugs stem from memory unsafety is grounded in the mechanics of how memory is managed in programming languages like C and C++. When developers make mistakes in handling memory, it creates vulnerabilities that can manifest as various types of bugs. Understanding this relationship helps clarify why addressing memory safety is crucial for improving software security and stability.
>>106560539I've heard this stuff works pretty well
>>106563380>Rust brings functional programming abstractions to systems programmingThis is in no way useful or desirable. It does just enough to make it harder to predict what exactly your code will do, but it can't actually handle any advanced and useful functional abstractions.>and simplifies memory safety"Memory safety" is a meaningless buzzphrase.
>>106563396>The term "memory unsafety" refers to programming errorsThat's a new one. Source?
>>106563411If you're looking for specific sources, I recommend checking out resources like: - "Computer Systems: A Programmer's Perspective" by Randal E. Bryant and David R. O'Hallaron. - "The Art of Software Security Assessment" by Mark Dowd, John McDonald, and Justin Schuh. - Research papers on memory safety from conferences like the IEEE Symposium on Security and Privacy.
>>106563418That's funny. I actually just finished reading all those books and they all say you're wrong. You'll have to provide a more specific source, maybe even a quote or something.
>>106563380Rust gives me>memory safety for most use cases>RAII>race condition safety>iterators and FP combinators>stackless coroutines>generics>a way to separate static and runtime dispatch>a macro system that lets me parse its syntax>a sane package manager and a standard library that's not bloated>inline assembly support without compiler extensions>access to a community of trans autists that know their shit because they spend 100% of their free time programming to forget about their gender dysphoriaMeanwhile C gives me>manual memory allocation>gdb valgrind asan aids>access to a community of overconfident college freshmen>a dead end job writing the same driver shit over and over again because the language is a chore to do anything higher level in
>>106563433Rust gives you nothing. All you do all day is shill your irrelevant cult language. You don't write any software.
>>106563333What a collosal waste of quads...A mutex works best when used by someone who isn't a nocoder like you, if your thread does 1 second of work and only locks mutex to do a pointer swap to submit its work, where's the inefficiency you retarded mouthbreather? It won't even perform a syscall.
>>106563439I wake up, go on 4chan, see Rust threads created by cniles, make fun of them and then go to my job
>>106563447>using a mutex for a pointer swap
>>106563454Yes. May I see your GitHub account? I'd like to know what great programmer I am talking to right now.
>>106563460https://github.com/matthieu-m
>>106563448>no uClassic "got under my skin" reaction. Show your great Rust software.
>>106563469They never do, it's always some fizzbuzz tier project that isn't depended on by anyone.
>>106560539Hanging around somewhere in the room
>>106560539fn main() { println!("Hello, world!"); let mut numbers = [1, 2, 3, 4, 5]; for n in 0..5 { numbers[n] += 10; numbers[0] += numbers[n] } println!("{}", numbers[0]); for n in numbers { println!("{}", n); } // second println!("Hello, world!"); let mut numbers = [1, 2, 3, 4, 5]; numbers = numbers.map(|x| x + 10); numbers[0] += numbers.iter().sum::<i32>(); for n in numbers { println!("{}", n); } // third println!("Hello, world!"); let mut numbers = [1, 2, 3, 4, 5]; numbers = numbers.map(|x| x + 10); let sum: i32 = numbers.iter().sum(); numbers[0] += sum; for n in numbers { println!("{}", n); }}
>>106563669dumb retard
>>106560539Why is it that every time there is a rust criticism thread, the criticism comes from a random brainlet getting IQ-filtered by the BC?Rust is far from perfect but if you are genuinely struggling with such a simple concept you should consider a different career.fn main() { let mut numbers = [1, 2, 3, 4, 5]; numbers.iter_mut().for_each(|n| *n += 10); numbers[0] = numbers.iter().sum();}If you are getting filtered by this code, you will never make it, and that's just me being honest and upfront.
>>106563687I'm struggling to understand what's the usecase of this.
race conditions are a design problem not a programming problemjust design your threads to not share data
>>106563698ask OP
>>106563698Well for starters, it prevented the brainlet OP from mutating the same thing inside a hotloop for zero reason.
>>106563710Okay, and what's the usecase of this?
>>106563714ask OP
>>106560539>the language doesn't allow you to change numbers in a mutable arraychat is this real?
use case?
>>106563760no, see >>106561446 >>106562180 >>106562388 >>106562934 >>106563139 >>106563669 >>106563687
>>106563773None has been stated yet.
>>106563775so basically the language doesn't support for loops, got it
>>106563790for loops are considered harmful
>>106563790Yeah, I just checked, this doesn't compile:fn main() { let mut numbers = [1, 2, 3, 4, 5]; for i in 0..numbers.len() { numbers[i] += 10; numbers[0] += numbers[i]; } dbg!{numbers};}What an awful language.
fn main() { let mut numbers = [1, 2, 3, 4, 5]; for i in 0..numbers.len() { numbers[i] += 10; numbers[0] += numbers[i]; } dbg!{numbers};}
>>106563795by who? trannoid freaks?
>>106563773Something something chunking minecraft mutex lock
>>106563813by lips chads
>>106563790What is the usecase for for loops when for_each exists?
>>106563823for loops are faster, you can mutate in place and don't have to create bloated copies of everything
>>106563823What is the usecase for for for_each when fold exists?fn for_each<F>(self, f: F) where Self: Sized, F: FnMut(Self::Item), { #[inline] fn call<T>(mut f: impl FnMut(T)) -> impl FnMut((), T) { move |(), item| f(item) } self.fold((), call(f)); }
fn for_each<F>(self, f: F) where Self: Sized, F: FnMut(Self::Item), { #[inline] fn call<T>(mut f: impl FnMut(T)) -> impl FnMut((), T) { move |(), item| f(item) } self.fold((), call(f)); }
>>106563811Try thisfn main() { let mut numbers = [1, 2, 3, 4, 5]; for i in 0..numbers.len() { numbers[i] += 10; let tmp = numbers[i]; numbers[0] += tmp; } dbg!{numbers};}
fn main() { let mut numbers = [1, 2, 3, 4, 5]; for i in 0..numbers.len() { numbers[i] += 10; let tmp = numbers[i]; numbers[0] += tmp; } dbg!{numbers};}
>>106563823why havent you kys yet?
>>106563826this >>106562388 mutates in place and doesn't copy everything
>>106563826>for loops are fasterIs it though?
>>106563826>don't have to create bloated copies of everythingfor_each doesn't require bloated copies. See Rust.Java/C#/Pyshit has given a bad reputation among beginners
>>106563834retard https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=080be64a88a32e342f70197aa16ea5d8
>>106563835I will KMS when I get too old to function on my own.Assisted suicide with dignity should be a right.
>meanwhile in the real world>"Mike from 2nd floor asked if he could use Rust to m-">"Alright I'll him to reinstall sql developer"
>>106563885there is no dignity in your life rust freak
>>106563918Nah you are just mad you are too retarded to be a real programmer. It's okay bro, you should stick to plumbing.
>>106560999There isn't one. This is just the retarded way Rust works. It doesn't like you shadowing different things under the same name in separate code blocks like that. Instead of numbers[0] it would want you to take some sort of Arc or reference or whatever of that directly and refer to that in the loop body instead of borrowing it.
>>106563937everything you said is wrong
>>106563946Then why is it complaining about accessing numbers[0] in the loop body even though it's mut?
>>106563956read the error message
>>106563968If you read the error message it literally tells you what I just said though:https://doc.rust-lang.org/stable/error_codes/E0503.htmlYou can't have your borrow extend outside of the loop body because of the way you're mutably borrowing it. It enforces that as part of its mutability rules. So you either need some reference bullshit to bypass this and safely borrow it or you just right non-shit code like >>106563687
>>106564022>You can't have your borrow extend outside of the loop bodyThat is not what is happening here though>some reference bullshitthat's the problem
>>106564034>>some reference bullshit>that's the problemYes, I understood that what they're trying to do is not very good code.
>>106563256>>106563263>>106563273It's obviously better if you can get away with no locking at all, but a mutex (or any other locking primitive) doesn't necessarily incur a measurable performance hit, nor does it require big task jobs to hide the "overhead". If you can get away with a little bet of latency (most use-cases), you can minimize the overhead with the right locking backoff strategy (wrapping Mutex::try_lock() in Rust's case).
>>106561876>remove the good things>add retarded shitthanks xir
>>106560539>how would you fix rust?Take it out back and shoot it.You want easy? Use BASIC.You want memory safe? For real? Use Fortran.You want speed and power? Use C. Or, if you have a lot of time and don't care about portability, assembly language.
>>106560539This is a (You) issue. Most languages either have modifing an iterated object as undefined behaviour, ban it or very heavily recommened against it. If you are modifying the same thing you are iterating, you are doing it wrong. Use a for loop, retard
>>106560539>what do you mean I can't alias mutable references?are you retarded by any chance?
>>106563956Because it's two mutables at the same time See >>106563050
>>106562160multiple mutable references is UB in any low level language (C++ or Rust).
>>106563885Can he breathe?
>>106563687>"programming" language doesn't let the user program>y-y-you're just g-g-g-getting filtered by the BBCIt's clear that you think your "programming" language has a 99% dropout rate because it's designed for the top 1% intellectually. You just can't comprehend most programmers aren't so ideologically motivated as to waste their time jumping through the hoops caused by the poorly though-out, sub-100-IQ premise of the language.
>>106564729>multiple mutable references is UB in any low level languageRust users are unironically this mentally ill. Full disconnection from reality. They also claim things like "if it compiles, it's correct" "memory unsafety is a memory error", "memory leaks are not memory errors" etc. Psychotic cult.
>>106564842without synchronization you cannot have multiple places you can mutate a value. it's undefined.while C++ compilers may not force full strict aliasing rules, Rust does.cope and seethe mentally ill shitter. YWNBAC
>>106564846>without synchronization you cannot have multiple places you can mutate a value. it's undefined.Literal psychosis.
>>106564855nothing I said is wrong. data races are UB.
>>106564882>having two mutable references is a "data race"Psychotic illness, no two ways about this.
>>106564889yes? what's the usecase of unchecked mutable access if not to cause UB?delusional retard. kys.
>>106564889It can and it will create data race.
>>106564898You're mentally ill and apparently think "low level programming" means you can't rely on any kind of execution order in your program and any part of the code can run concurrently with any other part of the code at any time.
>>106564913>any part of the code can run concurrently with any other part of the code at any time.They can. But if they access and modify same resource, then it's a data race.
>>106564913>I don't know the C++ memory modelya, I know you don't, because you're just another larping coder who probably deals with babby shit like Java, Go, JS and python
>>106564912See >>106564913. From this point on I'm just gonna start screencapping these insane Rust user posts. I encourage others to do the same. Whenever a Rust thread comes up, just spam it with screenshots from these insane xenoestrogen injectors. There's really no reason to entertain Rustposters beyond that.
>>106564934Explain what a data race is then. Cause, it certainly is a thing.
>>106565033A data race happens when different code paths modify the same data and get executed in an undefined order. Do you think "low level programming" means you can't rely on any kind of execution order in your program and any part of the code can run concurrently with any other part of the code at any time?
>Rust thread>cniles piss and shit themselves
>>106565099>>106566188Rustkike witnessed.
>>106560539>how would you fix rust?You know how when you start up CLISP it prints a menorah? Do something like that with rust but instead it's a swastika, or a hitler portrait, in ASCII art as a header in every source file, and as output from their compiler, debugger, package manager(lol), etc.
>>106563321>what is trylock
>>106566286>You know how when you start up CLISP it prints a menorah?Based. That's why nobody in the Common Lisp community uses CLISP anymore. Rust should print a huge ASCII art portrait of Netanyahu.
>>106563380>Rust brings functional programming abstractions to systems programming and simplifies memory safety for 99% of the use cases.kek
>>106563439>All you do all day is shill your irrelevant cult language. You don't write any software.based
>>106564842>Rust users are unironically this mentally ill. Full disconnection from reality. They also claim things like "if it compiles, it's correct" "memory unsafety is a memory error", "memory leaks are not memory errors" etc. Psychotic cult.Exactly. That's why it is useless to improve Rust -- its users are an order of magnitude more retarded than the lang itself.
If you like FREEDOM you like C, simple as.
>>106563687This should compile into nothing because it doesn’t use the result.
>>106566802I prefer C++, C limits my freedom.
>>106560539Nim solves this
>>106566989
>>106567011didnt know that, happy to keep using it
>>106563407>This is in no way useful or desirable. It does just enough to make it harder to predict what exactly your code will doI don't give a fuck about your junior ass being unable to understand a basic abstraction that results in more composable, lazy data transformation pipelines
>>106567185what happened to that rust rewrite of ffmpeg?
>>106567213there never was one
>>106560539>>106563760It's impressive how nocoders don't realize you can still use normal for loops in rust rather than iters to get around borrow issues.
>>106567247Yeah, it's really wild: >>106563811 (Me) >>106563834 (nocoder)
>>106563687this does two passes of the data
>>106567291not necessarily
>>106567269>>106563811>this doesn't compileHave you considered that you may be retarded?
>>106560539This is why companies are opting for AI over humans. I hope this helps, it may save your job someday.
>>106567299it absolutely does, you are creating two iteratorsthis is the correction:fn main() { let mut numbers = [1, 2, 3, 4, 5]; numbers[0] = numbers .iter_mut() .map(|n| { *n += 10; *n }) .sum();}
fn main() { let mut numbers = [1, 2, 3, 4, 5]; numbers[0] = numbers .iter_mut() .map(|n| { *n += 10; *n }) .sum();}
>>106567185You clearly don't understand what functional programming is. You think it's a shortcut "smart" people use for doing basic loops.
>>106567309No I never considered what I cannot be, try getting some board culture literacy.
>>106567348are you sure about that?
>>106567185Also see for instance >>106563687 and >>106567338 for a demonstration of my point that despite Rust "functional" programming being trivial to the point of uselessness, Rust users don't understand what their "functional" code actually does.
>>106567357I was only 90% sure but your screencap proves it without a doubt. Thanks for playing, retard.
>>106567360also see for instance <nearly every Cnile post on this website> for a demonstration of the point that C users are absolutely befuddled by any abstraction and regularly write buggy ass code because they have not even heard of a test suite
>>106567385I don't know what your mentally ill spergout is about. I'm just directing your attention to the fact that Rust users themselves get confused by the most trivial example of Rust's crippled "functional" programming.
rust be like {|<>::|[]}()|} and you faggots really go "this is the way"
can't wait for Advent of Code to humiliate more C sissies.
>>106567415so literally every language since... forever?
>>106567425Rust is the most popular language at writing non real world applications
>>106567460C++ Chuds -> solve the problems.Rust Trannies -> solve the problems.deranged C cuckolds -> cope and seethe by hard coding inputs, write shitty linear probing hash maps and still manage to write code that's much longer and more fragile than the former solutions in superior godly languages (C++, Rust).this is the truth. you can cope, but you just look like a stupid bitch.
>>106567473The world runs on C, I don't even need to argue or defend it.
>>106567478Say this when a fighter jet programmed in Ada shoots a missile at you whose radar was programmed in C++.
>>106567478ok, so you'll have no problem come December and go through the whole year using C.
>>106567484>drones intercepting the jet running nixos
>>106567356There is no board culture here other than certain people constantly fabricating information about other languages
>>106567501I didn't fabricate anything, you're just genuinely a nigger who can't read text + picrel, you are either a bot or straight up brown.
>>106567501>constantly fabricating informationya, it's kind of insane how bad it is. I wouldn't care about disagreements if people didn't just outright make up retarded bullshit.
>>106567473linear probing is based tho
>>106567528>kiddie continues bragging about his fizzbuzz>still doesn't understand what "functional programming" is beyond Level 0
>>106560964That's called Ada.
functional programming is when functions
>rust
>>106567553I can drink a 12pack of Corona and write more code in an hour thaan you can in a month
>>106567528stunning, and brave.
>>106567508It is impossible to tell what that image is meant to convey outside of your head, whether you mean it's trolling or something elseIt's Poe's law. All you seem to want to do is debase conversation of one of the few technical topics on this board
>>106567578Do you also often run into walls when the door is right there, autismo?
>>106567445>>106567338four different symbols for one simple function. show me literally any other language that does this anti-human garbage.
>>106567587>4 different symbols>() {}uh... C?
>>106567587Don't get me started on C++.
>>106567584Board culture is that a picture's image can often have no relation whatsoever to the post content. Retards love posting jaks and frogs
>>106567564Me too, writing print("a") 61586 times is simple.
>>106567595Just like you have no relation to your biological father who you never met?
>>106563362Odin lacks metaprogramming and decent polymorphism which makes it annoying to use. I don't even think it should have text replacement or AST macros. He could have easily enabled metaprogramming by having a halfway decent type-system and module system, but instead we got parametric pascal with casts.
>>106567587Are you fucking retarded?
>>106567622Nim solves this
>>106564825>>"programming" language doesn't let the user program??Rust let me program the exact same function that OP did, and more efficiently. Why are you lying?
>>106567413The code in OP is fundamentally not functional because it mutates a given array. Don't give me a retarded looking procedural code and ask to make it functional with magic.
what's happening here? it doesn't like mutating while iterating?
>>106567986XOR mutability. You can either have one mutable borrow or infinite immutable borrows
I wonder if all this shit would be resolved by adding a "shapeshifting" mutable type so that the compiler can allow things like this while disallowing things that explicitly add/remove elements to data structures
>>106568137I think that's effects systems which is probably decades out
>>106560539kys.
>>106568801I write Rust but you're completely missing the point
>>106563937Rust doesn't allow you to do retarded things? You can't tell me what to do!
>>106568883You made no point. You wrote unsafe code even for c.
>>106560539i don't get why people care about rust>m-muh memory safetyfast code is memory and type unsafe because computers are inherently memory and type unsafe. you will inevitably have to write unsafe or link with unsafe C libraries. sure, when you're writing yet another ls clone no one asked for you will think memory safety is the futurealso, can you show me one (1, yi, uno) useful program written in Rust, that WAS NOT originally a C program that did its job fine until rustards decided to preach their gospel of memory safety and "think about the children" rhetoric?
Proper higher-kinded types and improve const fn so it can actually do useful things
>>106569188filtered, nobody cares about your incorrect thoughts regarding how computers do things>>106569211based
>>106569188>also, can you show me one (1, yi, uno) useful program written in Rust, that WAS NOT originally a C program thatno i can't but i made this and i'm a rust user: >>106567357can you do such advanced functional programming?
>>106569250>filteredfiltered by what exactly? not following the rust cult? if I want to write a program that will be totally memory safe I'll use a garbage collected language, simple as. If I want a program that will be performant I will use C.>incorrect thoughts regarding how computers do thingsthe closer the code you write is to assembly, the easier it is for you, as the programmer, to understand how it works and to optimize it accordinglyalso>can you show me one (1, yi, uno) useful program written in Rust, that WAS NOT originally a C program thatdid its job fine until rustards decided to preach their gospel of memory safety and "think about the children" rhetoric?I guess you can't.
Better learning resources so brainlets like op don't blame the language itself
>>106569283>can you do such advanced functional programming?i engage in Haskell and math autism once in a while. It's fun as a recreational activity, and I have written my fair share of compilers with les monadic combinators, but not for writing actual performant software.
>>106569283>can you show me one (1, yi, uno) useful program written in Rust, that WAS NOT originally a C programThere's quite a few, for example Cloudflare's QUIC library, firecracker, cloud-hypervisor, COSMIC, ... list goes on
>>106564763I don’t think so
>>106569284you got filtered by advanced Rust functional programming concepts like map and filter. you need to learn category theory to understand Rust like i do
>>106569316Slop.
>>106569333Nice gymnastics. NTA btw
>>106569329i do know category theory to the extent of how it's used in computer science (a monad in X is a monoid in the category of endofunctors of X, or, as one might say, chaining computations), refer to >>106569302. It's interesting and fun, but not useful.
>>106569337I'm sure you're running all of that on your machine right now so you can testify how good it runs. You're also a maintainer for all these projects and attest to the quality of the code. Rust programmers are top-tier professionals.
>>106569316>Cloudflare's QUIC librarya library for HTTP just newer, wow, such a revolutionary technology>firecracker>Firecracker was developed at Amazon Web Services to improve the customer experience of services like AWS Lambda and AWS FargateJewish technology to solve problem they created themselves. >cloud-hypervisor>The project focuses on running modern, Cloud Workloads, on specific, common, hardware architectures. In this case Cloud Workloads refers to those that are run by customers inside a Cloud Service Provider. This means modern operating systems with most I/O handled by paravirtualised devices (e.g. virtio), no requirement for legacy devices, and 64-bit CPUs.wow, a KVM wrapper. also, the usecase is slightly unclear>COSMICwow, the bar is so low now. Yet another window manager. Because people haven't been writing window managers in everything from Python, to Common Lisp, to Haskell, to literally Java...
>>106569284>I guess you can't.https://github.com/RustCrypto is pretty cool. I used to use Bouncy Castle from Java, but I found numerous bugs, and their test suite is not very solid. I like to construct cryptographic protocols that have interchangeable algorithms, and RustCrypto allows me to do this easily.https://github.com/emilk/egui is a cool GUI that can deploy to the web or any other platform that supports OpenGL.https://bevy.org/ looks cool, and I have a friend that has fucked around with it doing VR-type experiments.https://embassy.dev/ is claimed by numerous embedded devs to be extremely convenient.https://docs.rs/hifitime/latest/hifitime/ allows for extremely precise, scientific time management (for things like aiming telescopes at the exactly correct location at the exactly correct time).there are a fuck-load more projects found at https://github.com/rust-unofficial/awesome-rustbut you don't actually give a shit. you're more interested in cherrypicking random projects that you imagine to be complete replicas of already existing software (that often has CVEs found in them).
>>106569333>>106569361Rust programs that I use: ripgrep, firefox, personal things I've written>>106569443Congrats on moving goalposts, yes you can write almost every program in every language
>>106569211>Proper higher-kinded typesthis.also a real module system so i don't have to litter my code with pub impl and a million other bits of needless keyword pollution.and bring back ocaml syntax.
>>106569459I have to concede that hifitime does look cool and it's cool that's it's formally verifiable. But that's about it. The rest are mostly libraries, which mean nothing by themselves. Why do you need a tool for building tools?>random projects that you imagine to be complete replicas of already existing software (that often has CVEs found in them)because clearly the Rust rewrite won't have CVEs because... because my CS professor told me so!!
>>106569516>yes you can write almost every program in every languageI didn't move the goalpoasts. Most of those things already existed, were written in C, and no one complained.
>>106569551newsflash bro: almost all software (C included) that does interesting shit eventually gets distributed as a lib. glueing a UI to some lib is the easy part.there are a lot of interesting things being made in Rust, but to use them, you have to be able to sit down and write the 200loc or whatever to set up thee solutions for your problem domain. many people using Rust to ship applications that are useable by random ass people are shipping those applications in a commercial context.
>>106569459Nobody should be looking for anything with “rust” or an r meaning “rust” or “-rs” or anything.That typically means it’s a c2rust project and has no legitimate purpose other than annoying cniles.> telescopesThat reminded me of the SPIKE project written in lisp on TI Explorers to schedule the Hubble around 1987–88.Some of these re-do “only now in rust!” are time and life-essence wasted when you could be helping out poor or sick people or contributing to your community.
>>106560539wankerlet mut numbers = [1,2,3,4,5]; for i in 0..numbers.len() { numbers[i] += 10; numbers[0] += numbers[i]; }
let mut numbers = [1,2,3,4,5]; for i in 0..numbers.len() { numbers[i] += 10; numbers[0] += numbers[i]; }
>>106569703>That typically means it’s a c2rust projectIt doesn't? There is only handful of noteworthy c2rust projects.
>>106569566>Most of those things already existed, were written in C, and no one complained.NTA but this is literally moving the goalpost.You asked for examples of Rust projects that were not originally written in C. When you got the response you changed it to mean examples of Rust projects that have features that were never present in any C program. And now you are moving it even further to make it about people not complaining about C in the past Just pick one claim and stick to it instead of changing the criteria in every single post.
>>106569540>a real module systemWhat would you want to see?ML-style syntax is something I'm mixed on, I do feel like the current syntax is more suited for a systems language where you need to be attentive to allocations etc.>>106569566No, these things never existed as C programs. Just because there were other programs that did similar things doesn't mean that the Rust programs "were originally written in C", see >>106569768 too
>>106569793Not him but what I want is basically as close as I can get to Haskell except:>No purity>No implicit currying>No laziness>Stripped down standard library, common sense reduction of the number of types>No GCSame module system, type classes, GADTs, etc.Built in polymorphic type Ptr, with a deriving list that looks like (Eq, Ord, Num, Integral, Bits, Nullable, ...)C-style pointer arithmetic (obviously)No pointer decaying, but the internal representation should still look like a pointer.No need for monads, so steal <- from do-style syntax for pointer dereferencing.A parametric allocate function that returns said Ptr typeA parametric reinterpret_cast functionLambdas are fully supported, they only capture by value. At compile time, we check for which lexical values we are using and build a special product type based on them + a function pointer. Type checker ignores the product type, and checks against the function pointer. Storage of lambdas may require a built-in wrapper type, but that's fine.If we want to capture a reference to a thing, it means capturing a pointer.Absolutely NO STRICT ALIASING.I think that gets us 98% of the way there.>I do feel like the current syntax is more suited for a systems language where you need to be attentive to allocations etc.I think it's more just about the semantics of the language. The ML-family gets close with the ref-type. But the lack of arithmetic + the whole lambda problem.
>>106570140>But the lack of arithmetic + the whole lambda problem.But the lack of pointer arithmetic, and then you have the whole issue with closures and allocation unless you lobotomize them properly.*
>>106560539too broken to fix
>>106570140>no purityWhy
>>106564153What is good about automatic memory management? If you want the computer to do that for you then use something like Go, Java, C#. There is an inflection point where if you use enough smart pointers in your code, garbage collection becomes a faster memory management strategy.
>>106571191RAII is good. Having to write all the same code yourself and causing bugs for forgetting to clean up or wrong clean up order is stupid when it can be automated
>>106571557No thanks, I want to know what the computer is doing when I read the code.
>>106563249Race conditions are not bugs.The "eventual consistency" model relies on them.You can get a considerable speedup if you don't care about short term inconsistencies caused by the race condition.
>>106573110>muh "eventual consistency" relies on race conditionslmao good bait/tard
>>106564882All I/O is a data race.There's a reason CPUs someimes do polling, and sometimes do interrupts.If you want to write programs that are safe and don't do anything, Haskell is a better option than Rust.
>>106573034If you can't infere the code based on scoping rules, you're probably an idiot.
>>106573110I encourage you to read what the C++ memory model. Race conditions are objectively bugs and you're an idiot.
>>106573490Notice how you're forced to keep referencing "the C++ memory model" or make other vague remarks but you will never be able to point out any "race condition" in this code:int x = 0;int *p1 = &x;int *p2 = &x;*p1 = 1;*p2 = 2;Rust is a mental illness.
int x = 0;int *p1 = &x;int *p2 = &x;*p1 = 1;*p2 = 2;
>>106573525NTA, your code has undefined behavior due to aliasing but it doesn't have race condition.To have race condition you need two threads or some other concurrency mechanism present.
>>106573490I never mentioned C++ did I?Data races can happened in any language, from Assembly to Python.
>>106573549That doesn't mean they are not bugs.Also datarace and race condition are different bugs.
>>106573547>it doesn't have race condition.Concession accepted.>your code has undefined behavior due to aliasing Quote the relevant part of the C++ standard. You won't.
>>106573554>That doesn't mean they are not bugs.>It becomes a bug when one or more of the possible behaviors is undesirable.>https://en.wikipedia.org/wiki/Race_conditionIn other words, if none of the behaviors are undesirable, a race condition is NOT a bug.>Also datarace and race condition are different bugs.>Not everyone regards data races as a subset of race conditions.[5] >https://en.wikipedia.org/wiki/Race_condition#Data_raceNot everyone, but I do. They are the same thing.
>>106573604>Quote the relevant part of the C++ standard. You won't.Are you talking about Rust or C++?
>>106573742Screencapped this. Truly psychotic.
>>106573616>>That doesn't mean they are not bugs.>>It becomes a bug when one or more of the possible behaviors is undesirable.>>https://en.wikipedia.org/wiki/Race_condition>In other words, if none of the behaviors are undesirable, a race condition is NOT a bug.Once again you are confusing race condition and datarace. I was talking about dataraces which are pretty much exclusively bugs.>Not everyone, but I do. They are the same thing.Whenever you regard dataraces as subset of race conditions is irrelevant to the fact that data races are bugs.I never said that every race condition is a bug. It doesn't have to be.
>>106573760>I was talking about dataraces>Race conditions are objectively bugskeeeeeeeeeeeeeeeek
>>106573878>I was talking about dataracesYup. Here you claimed that data races can happen in any language: >>106573549, while talking about whenever certain things are bugs. I noted that data races are pretty much always bugs and noted that this is not the same thing as race conditions.>Race conditions are objectively bugsDepends on your definition of bug. Data races are always bugs though.
>>106573547Unlike Rust, identical types in C++ are allowed to alias. Strict aliasing only applies to types that are incompatible.
>>106573924This is true
i remember back when i was a newfag here and thought these "here are 4 lines of code that don't have a problem, therefor, 1m lines of code wouldn't have a problem" were just memes. little did i know that those are genuine jeet thoughts.
>>106574412You could copy-paste that code a million times and it still wouldn't cause any problems. You could make a million variations on it and it still wouldn't cause any problems. In fact, in most modern languages, you can have a hodge-podge of undisciplined mutation of everywhere and never run into any "memory safety" issues. So clearly, that code is forbidden because Rust is flawed, not because some kind of magic happens to make multiple mutable references bad in a bigger code base.
>>106573760Are you not >>106573490>Race conditions are objectively bugsData races are a subset of Race conditions. The same rules apply, if the behavior is not unwanted, it's not a bug.>but if you have two writes or a read and a write at the same time it will corrupt the data!!!!1. Simultaneous accesses are a measure zero event on abstract hardware.2. If the "corrupt" data is not unwanted, it's not a bug.You can argue you don't want that data to be corrupted, but that's actually false.And this goes back to the CAP theorem, mutexes mean you give up *Availability* for *Consistency* in concurrent systems.One might prefer that the data not be locked by a mutex, so that it can be available, even if the value is junk.This is actually similar in nature to the issue Linus was having with Rust panics on oom in the kernel. Sometimes you want the allocation to go through, even if it's junk.Sometimes you prefer *Availability* over *Consistency* - different context, but same underlying principle.
imagine arguing the definition of a buga bug causes unintended behavior at any point in time at any level of regularity, simple as
>>106575224>Are you not >>106573490That's not me>Data races are a subset of Race conditions. The same rules apply, if the behavior is not unwanted, it's not a bug.There is no rules that would make data race not being a bug>2. If the "corrupt" data is not unwanted, it's not a bug.>One might prefer that the data not be locked by a mutex, so that it can be available, even if the value is junk.No one wants that corruption. It's UB in virtually any language out there.>This is actually similar in nature to the issue Linus was having with Rust panics on oom in the kernel. >Sometimes you want the allocation to go through, even if it's junk.He didn't want memory corruption nor any UB, he wanted a way to handle OOM. That was added and the issue was resolved soon after.
