When promoting apps, it is good to remember that #Rust is not a #feature :-) I zero care what language is used. Programming language is only a recipe. A CPU has only one single language that it runs baked from that recipe.

Or actually I do care in the sense that it is a huge turn back. It is misguided advertisement by definition because a competing app might not have this artificial feature. Some casual users might even think that an app is somehow better because it has the imaginary performance improvement thanks to Rust.

#rustlang

@jarkko

Any app written in #RustLang would be more likely to be memory safe, wouldn't it?

@jarkko

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.

@argv_minus_one Such language that would be memory safe does not exist.

@calbaker That said obviously those checks that exist given the validation make the injection harder but I would not hold my breath seeing a Rust program used in volumes with zero CVE's in its life-cycle. That has never happened in history of security vulnerabilities so far.

@argv_minus_one Also, you are essentially now disagreeing on that Rust is not feature. I.e. you are agreeing on that Rust is a feature 🤷

@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.

@jarkko @calbaker

> 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 nit that go has undefined behavior in the presence of data races, unlike all other mentioned languages except c++ (and rust, but data races are statically checked without unsafe)

@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.

@Dr_Emann @jarkko

+ Confidence of concurrency correctness
+ Confidence of exhaustive value handing (match) and exhaustive error handling

@matzipan @calbaker We could not know that because now you are talking about the famous halting problem in computer science or at least something that can be mapped into it as bijection between the sets.

@jarkko @calbaker we can know. The number of memory issues found in rust code is measurably lower in any code base where it is deployed. We don't need mathematical perfection to decide this. A little pragmatism helps.

@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 it's not a validation, it's a proof (made by the Rust compiler)

@laund @jarkko

Rust's lack of null seemed weird at first but now I love needing to explicitly use Option!

@calbaker @laund Yeah, Rust is great and for any non-legacy fresh new project that I had previously written in C or C++ I would pick it any day.

It just that I consider it harmful thinking that problems are solved by tools. Rust can bring the edge but it needs to be supported understanding its shortcomings, limits, CPU architecture, binary formats (ELF, COFF/PE) and various other domain assets. Rust alone is not a problem solver. So it is important to raise attention on this issue.

@calbaker @laund It is pretty weird to see comments that fight against lemmas that have been proved by computer science decades ago. As if Rust was yet another computational model, e.g. in same level as turing machines and quantum computation.

@calbaker @laund E.g. it is proved that the problem of "zero bugs" cannot be proved except when you have some well defined constraints which is basis of formal verification. In generic case, i.e. Rust app ecosystem we are talking numerically infinite set of programs with no constraints except those that computational model of Turing machine sets.

@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.

@laund @calbaker ok cool, i'm fine with being stupid beyond the scope of "none yet" ;-) no reason to get upset tbh.

@jarkko @laund

Who made you the arbiter of when another person is allowed to get upset?

@jarkko @calbaker you called something i have good reason to consider a feature "a artificial feature". i just argued against this. it doesnt mean i'm upset.

@laund @calbaker so you could then use the best phrase ever in English language: agree to disagree ;-)

@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

@pinkforest @laund @calbaker The core skill in engineering is to solve a problem and call it day in my books :-)

C and Rust are just tools that you might want to apply, and picking the right one based on a careful analysis of the problem at hand is the core skill, at least of an engineer.

There's as much confrontation between C and Rust as there is between a screwdriver and a chainsaw. I don't know what having a core skill in language even is other than understanding its syntax and semantics.

I'm not part of any weird "cult of C" so cannot really say that I would be part of this "C. vs Rust" confrontation. I just do stuff plain and simple. Whatever works, works. I.e. I don't have "a tool based identity".

Calling Rust as a feature is like calling cooking recipe as a spice or ingredient in a dish, which has no logic.

@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% :)

@pinkforest @calbaker @laund

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/

@pinkforest @calbaker @laund Yeah, I've seen in my work that trying to be as "case by case" as possible is an asset in software industry. Even your favorite tools is best tool look with critical eye from time to time :-)

@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.

@pinkforest @calbaker @laund I tend to agree with this. I mean if you add a dep to Cargo.toml to get rid of unsafe block that is actually needed there is still unsafe block somewhere. It is just not visible in your own crate :-)

Rust 1.78 makes especially putting some trivial unsafe blocks easier and more plausible with its assertion features: https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html

@pinkforest @calbaker @laund Nothing wrong in Perl tbh. Any language, even Rust does not prevent you from making trainwreck code tbh :-)

@jarkko @calbaker @laund There was also not long ago a new lint that catches all undocumented unsafe which is the critical bit - been thinking of integrating it into cargo-geiger . Also unsound advisories in RustSec that track all unsoundness in the ecosystem plus safety dance for motivation

@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.

@pinkforest @calbaker @laund Also, of course Rust helps to do that authentication module properly but part of it is also me making legit choice how I use Rust to achieve my goals. Not disregarding the merits just calling for more critical thinking :-)

@jarkko @calbaker @laund fair. I think it's lack of education and new paradigm brings growing pains like this where eventually the critical mass self-enforces the facts - eventual consistency if one will. I've been recently working on ETL'ing all microarch assembly into inline asm in Rust btw

@pinkforest @calbaker @laund Not pointing fingers to any particular community, project or even language but here's something I observe in modern days of open source.

There has been and probably is still today some toxic behavior for sure in open source projects but there is also some toxic positivity, which means that when you take more critical angle it is interpreted as toxic behavior.

@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.

@pinkforest @jarkko @calbaker

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 @calbaker @laund

@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.

@pinkforest @calbaker @laund overally after this discussion i'm more eager rather than less eager to use rust, and more confident to use unsafe blocks based with common sense applied :-)

i was thinking more or less along the lines what you wrote to reddit but since rust is not my main beef i was not super confident on my views on that. when it comes to pros and cons i for most part agree that for fresh project using C++ in 2024 is not at least what i would do (but neither would slander anyone who thinks otherwise, there's usually not just one correct answer).

@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

@pinkforest @calbaker @laund it has been sort of shadowed from me too given "vmm" but couple days ago i peaked into its tests and saw it mapping /dev/zero there :-) i've known that it exists but thought that ok this is only for VMM's.

@pinkforest @calbaker @laund when i have the bandwidth i'm planning to give it a shot by rewriting some of the memory management code in https://github.com/enarx/enarx/issues/2580.

on memory management side i think some of google's work is pretty cool too, such as zerocopy.

@laund @calbaker @pinkforest actually i don't own any ethereum. randomly met some people from ethereum foundation and when people meet sometimes there's ideas what to do together and such and so forth. i might get flight tickets to prague that's all.

i'm neither actually that interested on blockchains but it is good to sometimes do stuff outside your comfort zone just to get a better perspective. it is good to get. know all sorts of people and best way to do it is to do something together.

agree to disagree means exactly that when you don't agree with something it is sometimes totally fine to come into conclusion that ok we have some disagreement but that does not mean that you have to hate people because of that.

in corporate world there's also "disagree and commit" but that afaik does not apply here. i'm not limiting what you want to do or how you want to do it but i have right to say how i see the matters.

so, all cool i guess...

@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 )

@cake @tulpenkiste Fortran is still used probably for good reasons too.

@cake @tulpenkiste fact check: https://www.tiobe.com/tiobe-index/

@jarkko@social.kernel.org I totally see new, interesting projects that use Fortran all the time!

In my dreams.

@jarkko@social.kernel.org or nightmares, yeah nightmares

@cake you can only understand something if you are involved with it. no need to be judgemental.

@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