Rust Decoders in Linux vs C Alternatives..

[@SavvyNik]

Thoughts on Rust in the Kernel?

[@BunnyKhatri-pd8zm]

Its cool and definitely better than cpp

[@ThePlayerOfGames]

As long as the language is performant and safe then all arguments against are just hipsterism If it's not safe or performant then it's fair criticism So far the Rust parts are fine, so massive thanks to those amazing Kernel developers who do all this unimaginably tough work largely for free

[@liarus]

I don't mind, if it's an opportunity to rewrite, refresh, optimize and make things safer, I don't see why anyone would complain

[@fomxgorl]

it's definitely cool and helps enforce memory safety while still being just as performant as the existing languages in the kernel

[@jackthatmonkey8994]

Does Rust have similar portability to C yet? Or is a C layer used to maintain arch compatibility?

[@gljames24]

Hopefully the JPEG-XL transcoder is here soon too. The browser space is in a really weird spot right now.

[@SavvyNik]

I’m with you especially with things like chrome trying to push it out of existence…

[@awdsqe123]

@@SavvyNik Google seems to be split on it. On one hand the chromium team seems to want to kill it and go all in on avif. But on the other hand, there is a google research team dedicated to jpeg-xl.

[@awdsqe123]

@@SavvyNik Google seems to be split on it. On one hand the chromium team seems to want to end it and go all in on avif. But on the other hand, there is a google research team dedicated to making a rust jpeg-xl decoder.

[@t01]

I've adopted it for personal use and it was super easy... Browsers and apps don't adopt it for no apparent reason other than money and control. Ridiculous

[@jagagemo8141]

JPEG-XL MENTIONED

[@CorneliusCornbread]

This is a really weird apple to oranges comparison. A large reason why this new implementation was faster was because of automatic vectorization for SIMD support. While this isn't the case for x86, no doubt could libpng could achieve this performance if not exceed the performance. The real argument here is that fast Rust is _easier_ to write than fast C, not that "Rust is faster than C." This is important because the C in the Linux kernel is held up to so much scrutiny and is constantly being updated that the level of effort to make C scream in terms of speed. The uphill battle for Rust in the Linux kernel is not speed even still, no, the uphill battle are the limitations of Rust, no stable ABI/no dynamic link support, unsafe Rust being nasty and not ergonomic to use, etc.

[@RickYorgason]

And Linux uses C is because fast C is easier to write than fast assembly, especially because the compiler can use optimizations that would be hard to read and hard to write in assembly. The fact that fast rust is easier to write than fast C, and that the rust compiler can implement optimizations that the C compiler can't is absolutely relevant. I don't think that makes it apples to oranges. They tested against 3 popular C PNG libraries. If it was really trivial to make a C library that was 1.8x faster, someone would have done it by now.

[@CorneliusCornbread]

@RickYorgason Even the fastest C will never beat hand written assembly, but assembly is impossible to maintain, C is comparatively easy to maintain. C isn't impossible to maintain, so that argument in favor of Rust doesn't apply. When the fast C has already been written and battle tested good luck replacing it. Though I don't think anyone here is arguing that it's still something to note. Moreover, writing a PNG library and writing a kernel driver are two _completely_ different tasks, so yes, it's _very_ apples to oranges.

[@RickYorgason]

@CorneliusCornbread ah, you meant kernel development vs library development. I didn't get that from your first post. I thought you were suggesting it was unfair to compare C PNG libraries to Rust PNG libraries. I disagree that hand written assembly will out perform C. Compilers do lots of optimizations that you would never write by hand. These days, assembly is only faster if you've profiled your code and you focus on a very specific bottle neck. In fact, for decades we've been telling programmers not to use the old-school micro optimization tricks (like using x >>= 1 instead of x /= 2) because in practice they prevent optimizer opportunities. Same thing with Rust. Yes, in C you *can* do the kind of SIMD optimizations that the Rust compiler can do automatically, but in practice you usually don't.

[@turtlefrog369]

C is always faster than Rust because rust cant make all optimizations C can, unless they write unsafe code in urst.

[@anon_y_mousse]

@@RickYorgason C compilers on x86 platforms have gotten so good that they do in fact perform those vectorization optimizations. It's actually easier to write performant C because the compiler gets out of your way and lets you write valid code that Rust won't. You can also write your code in C the exact same way as in Rust, regardless of whether you need to or whether it's even a good idea. If you use `clang`, you'll get the same results as Rust in like for like code.

[@JodyBruchon]

Newly written multi-threaded code built around modern processors beats legacy libraries architected around single-core memory-limited computers from 25 years ago? *whoop-dee-doo.*

[@TakeApartLab]

its not multithreaded...

[@JodyBruchon]

@TakeApartLab The video literally goes over a discussion about taking advantage of concurrency. That's threading.

[@anon_y_mousse]

Yeah, I'm going to have to agree with you on this one. It's quite evident when these propaganda videos pop up that the person making them either doesn't know how to program at all, or they're a very poor programmer. It doesn't help their case any when you can literally write code in C in the exact same way as you do in Rust. It's basically just an annoying C that adds RAII and references and not much else. And as we all know, since it uses LLVM in the backend, if you write your C the same way, you will get the same results.

[@benheidemann3836]

Valid criticism - would love to see a comparison between some new C software and new Rust software with the same set of goals and resources but those are a little harder to come by.

[@farrongoth6712]

​@@JodyBruchon Concurrency could just mean simd which isn't threading; there are multiple way to do concurrency not just threading. If it is threading and not just simd optimizations, the 1.8x is not really impressive. Assuming the old libraries aren't taking advantage of threading as well. IF it is rust being better at taking advantage of simd, than c, than 1.8x is pretty good.

[@Cyco_Nix]

I come from the early days with C being the language of the kernel. Unlike many of my brethren, I think the inclusion of RUST is a solid choice and will help diversify the overall system. It is interesting to see the performance wins, and I think that it will only get better as efficiency gets better as time goes on.

[@CyrilCommando]

It is the end of computing as we know it! It's like Wayland, but as a programming language design philosophy.

[@kyrylmelekhin2667]

Diversify??? You sound like a DEI zealot.

[@arkeynserhayn8370]

Diversify? Do you even have any idea that having codebases with overlapping languages are a bad idea, no?

[@hedwig7s]

Fun fact: Much like Lua, Rust is not an acronym

[@__Brandon__]

Diversity of languages is not helpful when you are making a standard. You are basically taking all the burden of maintaining with C, but now you have to do it all over again with Rust. I think Rust is showing that it's worth it, but this is definitely a case where more is not better

[@vercolit]

For systems languages, it doesn't really make sense to say "this language is faster than this language". The difference is how you write the program. Old C programs oftentimes are slow because they weren't designed with many of the hardware features we have today in mind like SIMD, parallelism, etc... Sometimes, they're just slow because they haven't been written to be efficient. I can make a very slow C program, just like I can make a very slow Rust program. It's nice to be able to say that rustc has better autovectorisation in a given exemple/on average, or C programs tend to be faster because they use fewer abstractions, etc... But the difference in speed is very very largely determined by which tools you use. You can write an extremely optimised rust program the same as C, and they'll very likely be almost exactly the same, the design decisions determine the performance metrics.

[@Luxalpa]

This doesn't really hold up though. You have to ask the question, why are the C libraries slower than the Rust library? Because they haven't invested as much time in it? Because they haven't been maintained for so long? Because they are very old? But then again, you must ask why this is the case. If C was better than Rust as performance, these libraries have a very long head start, surely they would have been able to find smart developers to improve them? I can't give you the definite answers to why certain C libraries were abandoned or why their active development would be slower than Rust libraries or why their developers simply didn't want to put in the work. I can't tell you why there isn't any new C libraries using newer tech and concepts to challenge them. But I can tell you that just from these questions alone we can say that there's something that makes Rust more suited to performance and safety than C. It's important to never take statistics at face value. But it's important to also never dismiss them entirely. The statistics say something. Stop ignoring them, stop oversimplifying them. These benchmarks don't say "Rust is better than C" - but they give you a lot of pointers for situations in which Rust might be the better solution to a problem than C. They say a lot about the states of the languages and their ecosystems. In the end, everyone needs to make their own informed decisions. But judging by the comments under this video, a LOT of people are just lying to themselves.

[@matiasm.3124]

Humm what does this have relation with the kernel? It's a user space library

[@SavvyNik]

While you’re right, the kernel doesn’t directly decode PNGs, it’s providing the necessary resources (memory, file access, etc.) that allow these decoders to function. The relation here is to show how Rust can potentially benefit the kernel.

[@famoustoxo5644]

@@SavvyNik Seems like an answer by ChatGPT.

[@Onkoe]

Many critics raise contentions against Rust relating to speed or consistency. It doesn't make much sense, as having memory safety and modern language features doesn't prevent low-level usage. Nonetheless, seeing these implementations with improvements in speed somewhat addresses their claims. Rust allows folks to be more "ballsy" with their implementations instead of being conservative with language constructs. Or, in short, developers are able to focus on their ideas instead of safety. Rust helps in those libraries, and it will continue to assist in the Linux kernel, too. :D

[@fabioc9142]

​@@SavvyNiknonsense, while i'm a Rust advocate, the performance improvements aren't really due to the language itself but their implementation

[@raymundhofmann7661]

Didn't you know? You're dealing with Rust cultists desperate to get attention.

[@dennisestenson7820]

One potential way rust could be faster than C is when the compiler can eliminate runtime checks. However, runtime checks might still be desirable for security.

[@comradepeter87]

if you can patch code directly, why wouldn't you also put a jmp to directly after the runtime check?

[@joelimbergamo639]

Most runtime checks have near to no impact on performance

[@avinashthakur80]

​@@comradepeter87 Where is the argument of patching the code ? User input adds the biggest uncertainty which runtime checks remove.

[@Myname-l3h]

It can be because the Rust libs are written from scratch more properly and the C ones are written God knows when and it's harder to refactor the existing code.

[@JodyBruchon]

@@Myname-l3h libpng is decades old and dates back to when single-core computers were all that any normal person could buy and practically use. SIMD stuff was an afterthought. Today, not using SSE/AVX is foolish for anything that can make good use of it, but they're definitely comparing apples to oranges on this. Legacy code doesn't take advantage of architecture changes? Wow, who knew?! Amazing!

[@Myname-l3h]

@@JodyBruchon that's what I'm saying: it's not a head-on comparison of two languages, but rather an implementation, development approach comparison.

[@JodyBruchon]

@@Myname-l3h I know, I'm agreeing with you and adding more info so anyone else reading has a more thorough understanding of the issue. It's very hard to fairly compare programming languages beyond very simple operations.

[@turtlefrog369]

its more about funding and manpower. all the corporate hipsters are on google and microsoft money.

[@platin2148]

If i rewrite something that already exists and can already get patterns from another library i can also make anything X faster that is not something a language fixes.

[@RustIsWinning]

Pure copium 😂

[@benheidemann3836]

Maybe true… why don’t you have a go at rewriting the png decoders in C and share the benchmarks? Would be genuinely interested to see what an expert like yourself could achieve in C with a blank slate, and it would make for a much better comparison.

[@RickYorgason]

@@platin2148 I guess the only reason nobody has written a C PNG library that's 1.8x faster yet is because it would be *too easy*.

[@platin2148]

@ More that people don’t simply rewrite stuff.. and there are libs faster just not something for your grabby hands.

[@muadrico]

@benheidemann3836 He will, if you pay his bills, boomer 🤦‍♂️

[@Patterner]

i remember a benchmark where a brand new implementation with all the current bells and whistles beat a system library that was several years old and "optimized" for like the 8086 :)

[@vilian9185]

assembly is assembly, so it's not "rust outperforming c decoders" maybe it was faster to write than c and the devs could optimize better

[@chiffaonosu]

no, there is a real performance gain that happens because rustc itself is very good at autovectorisation. You can't do that in manually written assembly due to portability reason, and I'm not even sure you can sanely set that up in normal C because C doesn't give enough guarantees about the code

[@vilian9185]

@chiffaonosu wouldn't llvm do that?

[@oserodal2702]

​@@vilian9185LLVM is notoriously tricky to write by hand.

[@СергейМакеев-ж2н]

@@chiffaonosu What kind of guarantees that Rust gives are important here?

[@oserodal2702]

@@СергейМакеев-ж2н In LLVM speak, attributes are tags added to certain portions of your code that uphold some invariant or guarantee, from which in the further compilation process the compiler can perform more aggressive optimizations. The guarantees Rust provides do map to certain LLVM attributes, and thus LLVM can then perform much more aggressive optimizations on the code without compromise on safety or correctness, unlike in C or C++.

[@JohnWilliams-gy5yc]

Welp. One can argue that having "unsafe" keyword is way way safer than having "option" of freedom to toss owning naked pointers around. All I can say is that Never write a paper for this issue and naming it "The unsafe *_QUESTION_* " ever.

[@m4toro]

www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3403r0.pdf bruh 😭🤣

[@averdadeeumaso4003]

Pointers that are handled properly aren't "naked"

[@JohnWilliams-gy5yc]

@averdadeeumaso4003 I can confirm that's correct... until Joey Swoll calls it out on about-to-demise TikTok.

[@santitabnavascues8673]

Cached reads vs non-cached ones?

[@deckard5pegasus673]

There is definitely something they are not telling. C is bascially high level assembly, thus if written correctly nothing can be faster than C. That is just a fact. The speed of the PNG library comes down to it's implementation. The PNG library written in C, is only single threaded.(although it could be easily ported to multithread). tI bet, the Rust implementation may be multithreaded. Also is the Rust implementatoin doing proper CRC checks, or skipping them? To make a comparison of 2 projects they have to have the same implementation. When I get time I will look at the Rust implementation to confirm if it's multithreaded, and how it's doing CRC. The propaganda is getting a bit out of control.

[@famoustoxo5644]

This guy knows nothing about what he's talking about, yapping yapping.

[@AsAs-nd7gy]

It's simd vs non-simd + optimized loops vs unoptimized loops. The libpng c code is old, and not written in a way the c compiler can optimize. It's not crc or threading.

[@rjy6]

@@deckard5pegasus673 the problem with C is that yes it is just higher level assembly but the compiler is dumb, and in many cases makes it very for the compiler understand your code enough to apply many optimizations. thats why in many cases -03 is broken. rust on the other hand has a much richer type system that give the compiler a much more precise view on what you intend.

[@teletubby-g1v]

At the end of the day: could Mojo be faster than Rust because of direct access to MLIR primitives? Also, would be interesting to see if Zig could beat Rust in this use case as well.

[@johanngambolputty5351]

As someone whose enjoyed using rust for the last two years or so, I love to see it. Don't need much of an excuse to use the language, I just like it, but if its got possible performance benefits too (never cared much about safety either), I'll take it.

[@jonbikaku6133]

That 1440p looking 👌

[@SavvyNik]

Awee thanks!! Love hearing feedback on this since idk how many people use it

[@Kiyuja]

Now I am a huge fan of Rust and I do believe Rust can be eventually "faster" because it doesnt need certain runtime checks that C and C++ need, Rust shifts them to compile time. HOWEVER, I would argue that the huge bulk of improvements comes from modern tooling and algorithms build into Rust, rather than just Rust as a language. C and C++ have huge technical debts which Rust never had. MT is somewhat easier for runtime, thats clearly an advantage but what the kernel fights right now is very old code from very old programmers that want to hold out at Helms Deep.

[@Wkaelx]

Portuguese track review: It's good, actually, the pronunciation of some words are kinda wierd, the mix of english accent and portuguese(Brazil) can get messy, but so far it's great. For those who don't speak english will not loose much. Prefer the original though.

[@SavvyNik]

Awesome!! Thanks so much for the feedback. Looking at whether to keep the audio track from the KZbin AI.

[@Jorge-xf9gs]

​@@SavvyNikThe Spanish one isn't very good.

[@SavvyNik]

Thanks for the feedback! Gathering everyone's input on this

[@leaf_swiss5184]

Does this mean every graphics card would run 1.5x - 1.8x times faster?

[@JodyBruchon]

No, this is specifically data decompression. It has nothing to do with graphics cards.

[@RickYorgason]

Could rust make it easier to write a faster graphics driver? Sure. But the speed of your graphics driver is a minuscule part of GPU performance. Neither C nor Rust are suitable languages for the kind of highly parallel code that actually runs on GPUs. The bigger benefit to using Rust in graphics drivers is that they'll be less likely to crash. But lots of languages are less likely to crash than C, so it's important not only that it's less likely to crash, but also that it's just as fast.

[@jonnyso1]

I mean, that's so hard to compare. Between the skill and hindsight of the developer I dunno. The only way that I see Rust would make a difference is that it would make some things easier to do because it offers a much better DX compared to C, but maybe the same person could have written it in C or Z or whatever and gotten similar results.

[@alexandrustefanmiron7723]

I also like mojo's approach to optimization. Maybe that can be introduced into c++. Using intrinsics + open mp + open cl/ cuda in the same codebase is not that nice.

[@stargazer7644]

Languages with more overhead do not vastly outperform languages with less overhead.

[@NphiniT]

So for newbies like me trying to get into Linux kernel development, do you think I should pick up Rust or I should continue with C for now?

[@BunnyKhatri-pd8zm]

Rust is good but let's be real c is not going anywhere, you should learn c first then rust and also c++, i think rust going to replace c++

[@SkegAudio]

Learn both.

[@SavvyNik]

Since a majority of the kernel is written in C I think it's better to start with this language first as adoption for Rust is going to take a very long time.. C will also help you understand and learn about the fundamentals of hardware architecture giving you explicit control over memory with pointers.. All important if you want to contribute in the future.

[@HksjJkdkd]

​@@BunnyKhatri-pd8zm C++ is not getting replaced lmao

[@fomxgorl]

rust dev here. you should learn both. c is still popular enough that it's going to be useful to learn just on that alone. however, rust provides many advantages such as memory safety and is only going to grow in popularity. also rust does have a steeper learning curve, so learning a similar but easier language like c will help with learning rust

[@darkcheese1]

Regarding the linux kernel comparison C and Rust, you are not allowed to use SIMD instructions inside the kernel it would be better disable it

[@melvilli69]

waaw, so nice of savvynik to create these many jobs for all those translators into different languages..☺😯😻💞

[@SavvyNik]

Loool

[@kamertonaudiophileplayer847]

Funny, I pulled deflate code from C to Rust for a performance, but now you claim opposite. Oh boy.

[@bartekb4191]

Problem with rust is that there is no job opportunities for it now and knowing embedded reality people are not willing to change their systems and architecture that fast in industry and are still using old technology

[@raimg1816]

Rewriting in Rust is cool but yeah, it can still bring new bugs. Even with all its checks, logic errors or rare edge cases can sneak in, and those might take years to show up. No language is perfect, only time will tell if it’s really better in every case

[@Luxalpa]

I mean, it doesn't need to be better in *every* case. In fact, being better in just 1 case and worse in every other case might already be a good enough reason to use it. It really depends on your use case.

[@xorealdoe]

I need your fontconfig

[@deckard5pegasus673]

C is bascially high level assembly, thus if written *correctly* nothing can be faster than C. That is just a fact. The truth the speed of the PNG library comes down to it's implementation. The PNG library written in C, is only single threaded.(although it could be easily ported to multithread). And the Rust implementation may be multithreaded. Also is the Rust implementatoin doing proper CRC checks, or skipping them? To make a comparison of 2 projects they have to have the same implementation. When I get time I will look at the Rust implementation to confirm if it's multithreaded, and how it's doing CRC. The propaganda is getting a bit out of control.

[@raidensama1511]

So then following your logic… if written “…correctly…” in assembly, nothing can be faster than assembly. “That is just a fact.”

[@vladlu6362]

Any language that compiles to a native executable is "just a higher level assembly".

[@arkeynserhayn8370]

​@@raidensama1511 Slippery slope fallacy

[@deckard5pegasus673]

@@vladlu6362 I'm related to the Queen of England because both of us drink water

[@mgytusr]

Not multithreaded, not skipping CRC. Read the abstract for the fdeflate crate for the winning optimisations - obviously these are not language-specific.

[@urisinger3412]

nah bro I'm sorry it's just two projects that are genuinely cool, you should check them out

[@alexandrustefanmiron7723]

I think a subset of c++ std is better for the kernel than rust.

[@friedrichdergroe9664]

Perhaps the C versions could be optimised to do better performance. As always, the Rust Fanboys love to jump up and down over anything they can. We are not talking a huge performance improvement anyway. 1.5x is really not that much, and I am sure the C version could be tweaked to do better. Just that it's "fast enough" and not worth the effort. And I do not consider 1.5 x "vast". Good? Yes. To me, "vast" means 10X or better.

[@mbarrio]

Clickbait title... shows one example. Rust is a nice lang, but asserting what it is in the title is wrong.

[@johanngambolputty5351]

3:30

[@RickYorgason]

The title is "Rust decoders outperform C decoders on Linux", and it shows three Rust PNG decoders that outperform the C PNG decoders.

[@happygofishing]

all machine code should run at the same speed, this is just reddit-tier hype.

[@benheidemann3836]

But it’s a lot harder to write good and fast software in machine code. Real software is extremely complex and engineers have limited time and resources. If the language makes it easier and faster to write more performant software, then it doesn’t really matter if another language could have done as good of a job as that language if you’d just spent twice as much time (and money?) optimising it.

[@user-sb5vt8iy5q]

rust is limited by LLVM, so it can never be faster then C, only as fast as, but also you can't tell something is faster when it has 1% of the feature set

[@kamertonaudiophileplayer847]

It can't be better, because share the same llvm compiler. But sure, sometimes C code written not so optimal and a new Rust code can be better.

i can not shake the feeling that they cherry pich poorly written C libraries. In the end of the day Rust has to do worse than well written C code. I have yet to see a optimizer that can remove unnecessary boundary checks at runtime as well as human can.

[@tylerfusco7495]

why do C programmers always hyperfixate on BOUNDS CHECKS when those are genuinely one of the most trivial and inconsequential LLVM optimizations? I'm not at all saying that rust is perfect here, or even *good* in terms of optimizations, but the real issues are not bounds checks. (and if you really desperately need to not have them, just use `get_unchecked`.) if array bounds checks are somehow your biggest performance hit, the added optimizations that come from references being `restrict`-by-default would more than make up for it (if you're doing anything non-trivial with that array you're indexing into).

[@JodyBruchon]

libpng is a very old library without lots of technical debt, whereas a from scratch implementation has no such legacy architecture. The only ways this would be a language comparison is if a highly optimized C library made for modern systems with threads and SIMD take into account was also being compared. Also, libpng minor versions are incompatible, so they could even be comparing against an older variant.

[@RickYorgason]

"Why would I use a language that automatically optimizes into SIMD for me? I like to do it myself" *Proceeds to not do it.*

[@JodyBruchon]

@@RickYorgason C auto-vectorizes.

@@RickYorgason I am not aware that that Rust has any language feature that would make it uniquely superior at this. It has a library for it, but you can have that in any rasonable language.

[@jagagemo8141]

The old folks desperately clinging on to c as if every kernel developers has an infinite amount of time to optimize every library by hand while keeping them safe. 😂

[@JodyBruchon]

Sorry, Rust still doesn't belong in Linux.

[@jagagemo8141]

@@JodyBruchon don't be sorry. We'll get through this 🫂

[@0LoneTech]

There's nothing desperate about already having functioning tools. There is quite the smell about lying about your competition at every turn, though (calling implementations "unsafe" without any indication of issues).

[@お茶-q8h]

I think it would perform better if it were carefully written in C, but we all know the disaster that has been the result of careful C writing (though it is better than C++). In fact, the way Rust is written, which produces compile errors, will pass Zig, but the fact that it passes is a problem in and of itself.

[@RustIsWinning]

Andrew Kelloggs or whatever the name could never haha :D

[@kowoba]

Why don’t people who want to write rust contribute to the Redox kernel instead?

[@VallThyo]

But they do, did you even research before this comment?

[@JodyBruchon]

​​@@VallThyoNot if they're working on Linux instead. Working on two kernels simultaneously is not practical.

[@adibemaxwell6111]

A bunch of Rust propaganda.

[@raidensama1511]

Don’t hate the language… hate the foundation.

[@expectnull]

@@raidensama1511 I have some experience with rust too. Its in part great. And in others it isn't. Cargo is a big uff. Compile times are big uffs. Encouraged deep nesting is a bit uff. The verbosity is a big uff. Of course there are many things to love about rust. But the language is not perfect. Its not the one fits all solution. And that's what many rust-followers make it out to be. Really annoying, that the tech community treats it as something more than a tool.

[@oserodal2702]

​@@expectnullFair, but no one's stopping you from rolling your own self-contained monorepo. Plus, most of the "heavy" crates relate to web stuff (tricky to get right) or application libraries/frameworks (think eyre). Some libraries also break up their own project into smaller crates for good reasons.

[@tophy9865]

​@@expectnull How is cargo bad?? Cargo is incredible

[@Myname-l3h]

@@tophy9865 static linking.

[@reinhardfranzwehringer7803]

Servus !

[@dadisuperman3472]

Whatever Rust code will be assembled to, can be translated to C one-to-one, since C is just a glorified assembly language.

[@stargazer7644]

You really have no idea what assembly language is, do you?

[@litodasdarwin9123]

In what way does "the way rust takes advantage of concurrency" matter when it comes to kernel development/optimization? And if a C program cannot be compiled with flags -O2 / -O3 and run as expected then it's the code that is flawed (written by an incompetent programmer) not the language or compiler itself. I guess if you want incompetent programmers working on the Linux kernel then Rust will probably be a great addition. How is the performance of a userland library even relevant when it comes to Rust in Linux....

[@SavvyNik]

You miss the fact that these decoders are benchmarking at much better rates and by your logic the programmers who made the original C decoders are incompetent. I think it’s a little more nuanced to what you’re making it sound.

[@Daktyl198]

Rust has async (non-blocking) built into the language. This is useful even in kernel programming as it's NOT multi-threading or multi-process and therefore doesn't require the kernel to use. It's not the same thing as concurrency, but it's a distant cousin. As for C programs using O2/O3, the vast majority of distros compile programs with O2 by default, but almost none of them use O3 due to the issues that arise. You say only flawed code written by an incompetent programmer would cause that, which may be true... but if that's the case, nearly every single program on Linux is flawed and written by trash programmers. As for Rust's speed with the userland libraries, the relevant bit is that because of the guarantees the language makes about how the code works/is structured, the compiler can (by default) use more aggressive optimizations without altering how the program works or worse, opening up security holes. The only security holes are those that bad programmers introduce (AKA non-memory related ones). This means that the Rust bits of the kernel can be heavily optimized by the compiler which can lead to very nice speedups. It's been shown over and over again that compiler optimizations are significantly better than hand-written ones on modern platforms.

[@khai96x]

Legends has it, that only incompetent programmers write code in C instead of ASM.

[@SavvyNik]

looool

[@litodasdarwin9123]

​@@Daktyl198 The speed increase between O3 and O2 is so minimal that no one really uses O3. And yes if someone writes C code which can't run as expected while compiled with O3 then their code is flawed. Provide one good example on how Rust's built in non-blocking features provide any optimization benefit in kernel development which can't be taken advantage of in C. "Rust has async (non-blocking) built into the language. This is useful even in kernel programming as it doesn't require the kernel to use" 🤣🤣 What do you think non-blocking is... Do you know what a kernel is? Yes it's great if Rust guarantees that aggressive optimization always can be used, even if the programmer doesn't know what hes doing. C allows aggressive optimization if the code is robust and written by competent people... you know the type of people you would want writing a kernel. "without altering how the program works or worse, opening up security holes", aggressive optimizations will always alter the way the program "works", and I don't know what to think if you truly believe that using optimization flags in C compilers will cause security holes. "It's been shown over and over again that compiler optimizations are significantly better than hand-written ones on modern platforms." Good that you at least said something true and of value. 🤣

[@Maman-Setrum]

LOL

[@stevensawolkin3873]

This is going to sound snarky, but seriously, son, you try to sell me books when you consistently use phrases like "had began" and "had ran"? Is this SavvyNik, or HillbillyNik" channel?

[@SavvyNik]

I think it comes off petty as well lol. Sorry english isn't my first language xD

[@stevensawolkin3873]

@@SavvyNik Well, let me say this about that. You may be correct, it may have been petty the way I said it. I apologize for that. Seriously. However, I do not think it is petty to expect an author and youtube presenter to use correct grammar. English is not your first language, I understand now you've told me. But it IS the language you chose to broadcast and write to your audience. Therefore, some proficiency is reasonably expected, it is my belief, in that language. As I said, I am dubious about the erudition and knowledge of an author who writes a book in a language without having it properly edited, or a youtuber who speaks to me with poor grammar. It may be understandable that you make errors, I can assure you that I make errors in French, Spanish, Japanese, and other languages I also speak besides my native English, too. But not in printed matter, nor broadcasts to the public. Once again, my honest apologies for being petty as you say, and snarky as I say. That was wrong, and you took it with good cheer and wit, bravo! But my awkward presentation does not diminish the point I was making about the consistent verb misuses that appear regularly here, which grate on the ears, and detract from your seeming erudition.

[@SavvyNik]

Sounds good, I’ll try and catch myself before making the grammar mistakes suggested in the future. Thanks for the feedback either way. Improvement is always a great thing imo! Also I’m not sure why you keep talking about a book? I haven’t written any haha. If you’re referring to my Linux bundle those are sheets with helpful tips about Linux, a mind map, and poster cheat sheet. There’s no intention to write book.. if you’re referring to something else me know bc it shouldn’t be referenced on my channel.

[@stevensawolkin3873]

@@SavvyNik So sorry, Nik. I had presumed your sheets were in some kind of book form. Being older, that's probably just my experiences influences my observations. I'll check more closely to avoid doing such. So you need not worry, no references need be removed, other than those in my head, lol. Glad we worked out our differences, you seem a good guy. Take care.

[@SavvyNik]

Likewise! No worries. Glad we got on the same page :) hope to see you around in the future. Love to hear future feedback that's how we all improve!

[@cosmicusstardust3300]

Its pronounced Line-is not Lean-is

[@SavvyNik]

Linus Benedict Torvalds (/ˈliːnəs ˈtɔːrvɔːldz/ ⓘ LEE-nəs TOR-vawldz,[3] Finland Swedish: [ˈliːnʉs ˈtuːrvɑlds] ⓘ; born 28 December 1969) is a Finnish and American software engineer who is the creator and lead developer of the Linux kernel. He also created the distributed version control system Git. en.wikipedia.org/wiki/Linus_Torvalds

[@bonfiters]

Linus himself said they're both correct pronunciations.

[@darknetworld]

Well there will be pros and cons to them. Rust required internet to install those packages right? I wonder if there different in cache storage. Plus rust is more clean by improve the rust compile while c barely update. It just a guess. But it depend on the toxic people in the dev for developing kernel. It not easy task as there tons of people work on big companies and funds. Well just like chrome browser it has monopoly control and do what ever they please. They did break their api old and from old website that rare updated. So there was no warning or notice. Well it a lot of work to deal with what features add or remove. Trust is not easy.

[@CyrilCommando]

More Rust propaganda!

[@muadrico]

You are not comparing languages, but different implemetations. Total bullshit video. 🤷‍♂️

[@GameDevChad]

One hundred percent.

[@benheidemann3836]

Well the claim here is that rust enables better implementations with less effort. Language level comparisons have been done, so we need to start evaluating real software. Do you have a suggestion for how to do this better?

[@GameDevChad]

@@benheidemann3836 Waste of time since memory safety is coming to C/C++

[@nicholastheninth]

@@benheidemann3836 It’s just not fair to compare new Rust software with decades-old C software, due to vast compiler differences and nonexistent ISA extensions like SSE/AVX at the time the C code was written.

[@RustIsWinning]

​@@benheidemann3836Let them cry. Copium tanks are probably empty soon hahaha