Gonna have to disagree. Every time there's news of yet another buffer overflow vulnerability, being written in Rust (or some other memory-safe language) is a feature that that program is lacking. Same for prototype pollution, type confusion, and so on.
@calbaker No.
It has static and run-time checks for memory safety, which is not the same as being memory safe. Just like Go, Java, Python and what not have measures for memory safety but instead of borrow checker they use a garbage collector.
Rust is less safe than any of those languages because the result is an ELF binary, which is roughly a twist of what C++ source generates with fancy checks. Same attack techniques, like ROP (return-oriented programming) gadgets still apply as for any possible ELF binary ever compiled.
@jarkko
Compared to Python, Rust can totally give a performance improvement. It would have to be a pretty big app for the difference to show when compared to, say, Java, though. And it's memory safe, which is more than C & C++ can say. Also, there's no garbage collector, unlike Go, which is why Discord moved critical infrastructure to Rust.
@jarkko As a user I care if works on my computer/browser/phone.
As a developer I am interested with what ingredients the program is build so I might brew something similar.
> There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new UWB stack, DNS-over-HTTP3, AVF, and various other components and their open source dependencies.
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> Historical vulnerability density is greater than 1/kLOC in many of Android’s C/C++ components
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
@jarkko @calbaker that being said, some aspects which people often forget is that its not all about memory safety. Theres other relevant language design decision which have a major impact on bugs, crashes, etc. such as Rusts lack of null.
This is all not to say that i expect all Rust programs to be perfect, far from it, but i generally expect lower error rates and less likelyhood of crashes.
@jarkko I mean, if a program were written entirely in Brainf**k, despite the fact that the cpu uses the same instructions to execute that program as any other, I still would consider that a strong _anti_ feature, so language can matter.
If nothing else, being written in rust tells me the program is:
1. Capable of being fast - unlike python
2. Capable of starting fast - unlike a jvm startup
3. Written in a language I know - unlike Algol
All of which I consider as features
@jarkko @calbaker by that logic then nothing is memory safe because at the end of the day it was implemented in C or C++. Ar some point there is a cutoff beyond which things can be called memory safe.
Rust also has thread safety as an emergent property of its type system. Python, Java or Go cannot claim this.
@jarkko i do care because languages are bound to different runtimes but also communities and different communities have different skills and interests. I know a Java program will need more memory and that a PHP program is likely to be of poor quality.
@jarkko @calbaker you said that you "zero care what programming language is used". also that "show me a Rust projects with 0 bugs"
i argued against both. you yourself just elaborated why the second is a stupid question beyond the scope of "none yet". even the article i linked clearly said they dont expect the number to stay 0 forever.
using Rust is not a perfect guarantee of everything. Bug it does show a few things: the project is newer, the project likely has less issues. this is a feature.
@jarkko @calbaker who said 0 bugs? thats ridiculous. i say that i'm fine with statistically less bugs. thats a feature to me, for which language matters a lot. do i use Calibre, a big application written in python? yes. do i expect there to be lots of bugs and issues? yes. and even just my sparse usage has proven this, it has a bunch of bugs. would i expect less bugs in a Rust project like this? yes. due to language, but also due to the mindset taught by the language and materials.
@jarkko @calbaker i would not want someone to "agree to disagree" without stating their reason, so i tend to either provide at least some arguments (tho i feel like i need to find a instance with a higher character limit) or not engage at all
so i only really go with "agree to disagree" if the other person is repeating themselves.
besides: you did a almost callout style post, mentioning tags etc. surely you expected someone would respond who disagreed.
@laund @jarkko @calbaker People coming from C typically forget the ecosystem and the composability - that a lone is a productivity factor. Vast majority of programs are just tying in existing libraries and core skill in Rust is implicit collaboration vs a single monolithic mainline around either single big lib or ... kernel
@jarkko @calbaker @laund It's not helpful to conflate the pros and cons of tools. Rust needs a different approach from developing C which is more monolithing plain and simple. I use both. What is the percentage of people who need to touch kernel ? I bet the answer is less than a percent if less than 0.1% :)
I get that for sure but…
This is the thinking that apply 100% also to any piece of user space code that I might do. I figure out the best possible solution that I can think of with my limited skills and then pick the tool that I try to nail it sometimes succeeding and sometimes failing. So yeah, my world is as plain and simple as that :-) Engineering problem at hand is the first priority, and obviously to pick the right tool I need to exactly compare pros and cons of them for that particular problem.
A recent example is an authentication module prototype that I’m developing for Ethereum ecosystem (and presenting possibly at ethprague). For that I’m most likely using Rust, and ended up to that outcome by comparing pros and cons of possible alternatives.
@jarkko @calbaker @laund Yes I think we are in agreement - pros/cons are usable at contextual but often people compare them as apples and oranges where the core of the problem lies leading to marketing hype. Only feature (vs factor) which has tradeoffs as every feature have is the borrowchecker really and it itself needs to be contextually evaluated like we do. Borrowchk is just proof assistant from MIR just like formal proofs e.g. what Hax does https://hacspec.org/
@jarkko @calbaker @laund For the record I see the same feature conflation in film industry and other industries - people compare cameras like they ultimately chiefly make your movie without evaluating contextually e.g. how it fits in the story - noobs in the storytelling never think story but just the tools - and once they gain some experience they talk less about tools - or how some tool helped them contextually.
@jarkko @calbaker @laund For Rust/C probably the biggest parallel stigma is around Unsafe use in Rust which I've been on receiving end trying to educate - there was a thread in reddit not long time ago which burntsushi had excellent read https://www.reddit.com/r/rust/comments/y1u068/the_stigma_around_unsafe/
@jarkko @calbaker @laund Yeah I have plenty of Perl still in the production that wasn't supposed to end up there - then people think Perl is bad but ... people need to stop trashing programming / scripting languages as it prevents people to share the cool things and problems they solved given the environment and the then-day tooling etc. real-world constraints newcomers don't always have experience on and not know to appreciate that way.
@jarkko @calbaker @laund That is true - https://crates.io/crates/cve-rs | https://crates.io/crates/plutonium etc. I keep having to educate on this as there is a lot of misleading marketing for sure.
@jarkko @calbaker @laund yeah it's a balance between toxic positive and negativity - hard to free people from agendas, monetary influences, biases and everything else that is going on that drives the ship forward that has multiple captains ready to hijack the ultimate control / consensus direction - poplarity is a factor when something gains popularity quick at least initially and then it normalises e.g. in established mailing lists where things have settled
@jarkko @calbaker @laund also fwiw - for a lot of people it is a surprise they actually use a lot of C if they use Rust :D openssl probably the most famous https://medium.com/rustaceans-security/that-vendored-openssl-most-of-us-rely-on-probably-needs-a-patch-aae8fea5160f or this bit about aws-lc-rs which has proof verification at object level w/ hol light https://www.youtube.com/watch?v=2e5wFNqpbvY&list=PLeeS-3Ml-rprAsk-5xAAPHB_3mhBb42jV&index=12 that is default in rustls 0.23 over ring which has a lot of asm for obvious reasons
@jarkko@social.kernel.org I've always thought it's like 'contains peanuts' for allergics.
hey, i'm actually good friends with the author of cve-rs. wanna know something? i'm damn sure he'd disagree with the "rust is not a feature" idea as well.
The fact that you can make bad code (or exploit known and being-worked-on compiler bugs) is inevitable in any programming language, and i REALLY hope you DO NOT interpret me saying "i consider Rust a feature due to (see prior discussion and points others have made)" as "Rust is 100% perfect and flawless".
@jarkko @calbaker @pinkforest of course someone with your view on Rust would be fine with crypto bullshit.
seriously, thanks for making it obvious you are not worth talking to (also ignoring every opposing argument, which in hindsight is the same thing cryptobros do...)
@pinkforest thanks for great comments!
talking about asm, one feature i’m waiting for to become stable is naked functions, which is fortunately in unstable.
one api that was outdated even when rust first came out is File API. it models POSIX golden days of the tape drive part ;-) i.e. it is pretty much in the 70s idiomatically. or what was the latest thing back then.
with modern storage and 64-bit address space only thing that you ever want to use fd for is with sendmsg(SCM_RIGHTS)
when you share it betwen multiple processes.
rest is better to be done simply by mapping the whole thing to address space and let page cache take care of you. initially reserved set size is ofc zero bytes with invalidated page table entries.
it is great way to also deal with large sparse arrays for the obvious reasons.
not a huge issue. i’m pretty happy with https://github.com/rust-vmm/vm-memory but hopefully stdlib will have equivalent functionality some day. despite the name this can be used outside KVM context.
@laund @jarkko @calbaker I don't think personally attacking people is helpful to prove each owns intepretation and win internet arguments over b.s. divisions over marketing and how each own inteprets it. People have different cultures, intereptations, skill levels based on their unique experiences and alienating doesn't necessarily help the cause. Same goes with deradicalization on equal power dynamics.
@jarkko @calbaker @laund TIL I didn't even k now rust-vmm existed thanks for the pointer - I've been focusing on userspace e.g. io_uring and eBPF but I guess you're more at page level - been doing some experiments with to make secure memory idiomatic incl. w/ permissioned-pages & memory_pages crates
@jarkko@social.kernel.org @tulpenkiste@lea.pet gotta disagree chief, I'm not a rust fan girl ( I use python and looking into zig )
But promoting a software based on what language is written in has always been a way of advertisement.
Rust is a pretty modern compiled language and people are most likely to contribute to the project if it's used as an alternative to older languages, like C.
It has better tooling and overall a better developer experience.
Other than the guarantee that code will be at least a bit more secure.
Yeah, everything at the end gets compiled down to whatever the CPU runs, that's true, but It doesn't mean that the language doesn't make a difference, as if that was true, we wouldn't have evolved past Fortran.
I mean, it's pretty obvious to think that, if there are two projects, one written in rust and one written in C, C++, the one written in rust will usually have more active contributors over the C, C++ ones.
* I don't mean to crap on those languages, as I really do like C ( I do dislike C++ though )
@jarkko@social.kernel.org I totally see new, interesting projects that use Fortran all the time!
In my dreams.
@jarkko@social.kernel.org I'm not trying to be judgemental, but I do think that programming languages are tools, and I'd like to use software that was made with shiny tools that help the user