Rust takes Python's 'explicit is better than implicit' to the next level, almost to the extreme!
This is the difference in approaches of the two languages. In C++ if the code is vulnerable, the blame is on the programmer. In Rust if the code is vulnerable, Rust considers it a failure of the language, and takes responsibility to stop even “bad” programmers from writing vulnerable code. I can’t stress enough how awesome it is that I can be a careless fool, and still write perfectly robust highly multi-threaded code that never crashes.
kornel on lobste.rs (again)
I have to raise a little red flag on the above quote least other are led astray with a false sense of security.
When one says software is "vulnerable" that is usually in the context of security. Basically trying to stop bad actors from using systems in bad ways.
Whilst Rust certainly enforces lots of rules to help reduce silly coding errors that introduce memory use and other silly mistakes and whilst that prevents a lot of bugs that could cause security issues it does not ensure ones code does not have security vulnerabilities.
If Rust code contains security vulnerabilities, for example an incorrectly implemented encryption system, the programmar cannot blame the language or compiler for it.
In C everybody’s gangsta until someone dereferences a pointer.
It's okay, Rust doesn't have feelings.
Those are getting added in Rust 1.63.
Rust is a perfect language for a dad like me, who every day puts kids to sleep, and tired after long day of work and chores, can sit down and possibly write some code for the hobby open source project, even when he's already just half awake. And it usually just works, tend to be robust and make the day feel extra productive.
-- /u/dpc_pw as part of a response to the previous QOTW @ https://www.reddit.com/r/rust/comments/uxx7w8/this_week_in_rust_444/ia1cwn6/
Rust's devs came from the functional programming world (To the point that
rustcwas originally written in Ocaml and people have called Rust "an ML with C++ syntax" and joked about it being "an attempt to trick C++ programmers into writing Haskell") and, generally speaking, when they don't have a feature like Higher-Kinded Types, it's not for lack of trying.
Ironically this quote probably won't make it into next week's TWiR because of ssokolow's own submission above
It happened when I least expected it.
Someone, somewhere (above me, presumably) made a decision. "From now on", they declared, "all our new stuff must be written in Rust".
I don't know what they see in it, to be honest. It's like I always say: it's not a data race, it's a data marathon.
At any rate, I now find myself in a beautiful house, with a beautiful wife, and a lot of compile errors.
Jesus that's a lot of compile errors.
fasterthanlime in The curse of strong typing
I wrote a bespoke time-series database in Rust a few years ago, and it has had exactly one issue since I stood it up in production, and that was due to pessimistic filesystem access patterns, rather than the language. This thing is handling hundreds of thousands of inserts per second, and it's even threaded.
--Taywee from the Hacker News network
a wise man once said: give a man tests and he will find bugs for a day, teach a man to fuzz and he will find bugs for the rest of his life
true fact: the rust programming language actually evolved independently 5 times in a process known as 'carcinization'
Because lower-level software has more operational constraints than higher-level software (e.g. it typically cannot tolerate a runtime or memory management via garbage collection), developing a memory safe language suitable for systems software is particularly challenging. The Rust language has met that challenge, however, and is an excellent candidate for replacing C in many systems applications.
We plan to invest in the tools that allow systems engineers to move their software to Rust. This means investing in improving package management, compilers, and Foreign Function Interface (FFI) generators. In many cases this will include providing interfaces compatible with existing widely-used components to enable transition. With these tools, adoption of a memory safe alternative will scale much faster without replication of efforts.
Rwlock vs Mutex? Please, tell me like I'm 5
Mutex: "Mom says it's my turn on the synchronization primitive."
Write lock: "Hey! You all are not allowed to look until I'm done writing!"
Read lock: "Hey! You are not allowed to edit what you wrote until we're done reading it!"
Thanks for an actual 5 year old reply, made me laugh
/u/LyonSyonII and /u/everything-narrative on /r/rust: https://www.reddit.com/r/rust/comments/vcaabk/rwlock_vs_mutex_please_tell_me_like_im_5/
That doesn't look like it's from the White House, though.
Sources providing the origin of the above White House OSS Mobilization Plan whitepaper:
It has white house backing, but was drafted by OpenSSF.
Hmh, would like to rewrite my 20 year old C driver for a industry infrared camera and flash I used for monitoring a chicken coop in Rust.
Just to see what it's like if done in Rust. I didn't dally much in kernel code, but this sounds like something which could be done.
Though, the chicken coop monitor and gate opener/closer long got replaced by more modern stuff by now which run on Linux out of the box.
By the way, we thought it was a fox and wondered how got over/past the fence... It actually was a Hawk going after the Chickens in daylight.
I just really want there to be a quote about a chicken coop in TWiR
Looks like this quote got overlooked!
… [ergonomics] is a downstream symptom, whereas the inclusivity thing is the upstream driver for all of that. So that's where you get ergonomics, right? If you don't care about inclusivity for beginners and whatever, then you're not going to care about that.