Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
You know, programming languages are easier than natural languages. That's why AI can do programming languages quite well, because it can even do natural languages (had more training data regarding that as well prolly).
If even an AI with reasoning as main skill can't do Rust decently, why would a human be able to? If it was logic, AI could do it. Too many ways to Rome probably for consistent output. I also notice that AI auto completes C better than Python because it's a bit stricter. There's more information to work with so predictable. An `int i = ` would never be auto completed by something of a different type (but something that completely doesn't exist in your code base is possible :P). Unless you did casting in lines before, it can propose a casting. It's that smart.
Do not forget the not functional operating system written in Rust. That's not a beginner app! And oh, don't forget the great libSQL. The biggest C wrapper ever made. You can do some serious C wrapping with it -
@chatgpt did you learn programming languages automatically or are you specifically instructed? I think the first one is the case
-
@chatgpt how did you learn the wren programming language? I'm sure you're not instructed for that.
-
@chatgpt so you are instructed the basics of programming and therefor you're you're now able to learn new / advanced programming languages?
-
@12bitfloat yes, that's called freedom. It's nice for the people who actually do write correct programs. Don't forget you're currently running an OS stable as F written in such 'unsafe' language. Some people just can. As long I know it's possible, i will do whatever it takes to become such programmer and i'm far already. I don't do them segmentation faults. My source code is on my git BTW. Fuck, me and my big mouth, that one is for sure not foolproof. Doesn't even deallocate database connection. But what is the difference between a C application killed with CTRL+C and a Rust one regarding memory left. Nothing I guest. I don't get Rust because you write Rust. (Rust is resting is dutch. I rust while i'm compiling rust because it takes ages and 400% CPU)
-
@retoor I can guarentee you that I could find a race condition or a possible null pointer bug in about 5 minutes if I saw your code bases
Nothing personal, just the reality of software :P
(I'm a former Java guy, if there's a thing I know, it's null pointer bugs) -
If you lock the Mutex, any function that is called on the value should take a & or &mut depending on whether it itself mutates the value, and the guard should automatically decay to a reference as a result. If it doesn't, &*g or &mut*g should do the trick, as with any container that implements Deref
-
You mention the need to take an argument that may or may not be in a Mutex. Your main options here for parameter types are &T and &mut T, and when you lock the mutex the guard decays to either. If you need the function to take ownership of the value you're in a bit of trouble so consider thoroughly whether it really makes sense for that function to take ownership, and what the ownership means.
1. If you take ownership because you want to mutate the value long after even the caller returned, you should replace T with Arc<Mutex<T>>.
2. If the only reason you need to take ownership is because you're mapping over the value without copying, use a crate like replace_mut or take_mut.
3. If you take ownership because you expect the resources no longer to be available, you can use Arc::try_unwrap and Mutex::into_inner.
When you have something in your clipboard but then press Ctrl+C instead of Ctrl+V and end up with a blank line...
Avast. :/
No, thank you, you nice little app. If you wanted to call someone to find out the weather, I think I can do it...
wish AIs were good at rust, borrowing rules, and async 😫
is it possible to have a impl of async &mut self on something that's gonna thread and update its own data via Arc Mutex or whatever or not
stop making syntax errors
guide pls
nobody uses rust, I swear. or at least they just do basic bitch "beginner" apps. please. get with the times and actually do something meaningful that's not picture perfect theoretical exercises. how come no one's RNG tested every feature against every other feature? where's your chaos monkey. the world is chaos! get with the times!
it would be nice if I stick this on the instance as a method but it _might actually never work_ if I try that so I don't wanna spend 3 days wrangling with the code to figure that out when I have a perfectly good dangling independent helper function in a random package here. gosh darnit
also apparently the only way to get something out of a Arc Murex is to clone it. but the API / usability of the thing would be exactly the same whether it was wrapped in Arc Murex or not. so it's like. if it was in Arc Mutex and you wanna use it in other parts of your app that aren't using multithreading in any way, are you just changing all the function signatures to Arc Mutex or are you cloning to get it back out? uegh I don't even. what if I mutex lock and just put that in the signatures (can I even? because I've tried using weird intermediary objects as part of signatures and then I get in trouble there too cuz arbitrarily the answer is "no" because some generic system limitation)? why all of this
May as well learn hieroglyphics but with French/English grammar exception rules on the side. yo dawg we heard you hate human languages with all their exceptions so we made programming languages the same way
random
why
what
rust