More Rust Code Readied For Linux 6.3 - Closer To Having Rust Drivers Upstreamed

[darkonix]

Yes ! Better tools are for losers ! Linters and sanitizers make us weak ! If you can't find all the bugs just by reading the code you're fired ! Programming languages only went downhill after COBOL !

Yes!! Programmers that need their compiler to tell them when they make a mistake are useless. Real programmers don't make mistakes at all. Why is people using this newfangled ANSI-C style when there is perfectly good K&R way of programming C? Why grown ups need training wheels? It isn't like thousands could loose their money or their lives if there was an easy way to catch bug at development time, right?

(Note: this was sarcasm, for people that is impaired on that)

[cj.wijtmans]

There is also a problem here as you coding modern C++ you start being slower than rust for the same safety level and worse longer code to debug than rust.

This is pure unsubstantiated nonsense.

Bloatware what are you talking about. One of the problems with C++ is as you start using it in safe ways it very bloated. Yes rust generated code is larger than unsafe C or C++ using raw pointers but smaller than C++ using std::unique_ptr and the like so call modern C++ mandates. Then with C++ you start having to bring classes and other messy thing in to make it safe.

You dont have to use unique_ptr, you can write your own to fit your needs as stated several times. Cant do that with rust.

C++ ownership system based around classes is problem end up making code more complex and more places for compiler errors and human coding errors.

Imagine being trigged because someone calls you an idiot when you cant use a language properly but then proceeds to call classes complicated.

The historic arguments against C++ in the Linux kernel and freebsd kernels have been the same things. Bloat is one of those things. Yes different freebsd developers and openbsd developers are looking at rust as well.

This has been discussed and addressed before. Also it is hilarious smol pp linus calls something bloatware when linux is the epitome of bloatware.

Yes two forms of bloat has been against C++ getting into either OS.
1) increasing number of lines developers need to audit.
2) increasing size of generated machine code to get the same results.

The increase of size usually has to do with poor implementations or poor use of the STL, stdclib etc. The language itself is zero overhead. When you would implement C++ for a kernel you would implement an STL that is efficient for the kernel. This has been addressed before.

cj.wijtmans there may be a simple problem. C++ may just have too much legacy baggage. Rust has auto smart pointers and other feature auto done so programmer does not have to do all these things.

Exactlly, rust holds your hands, which is why i will never trust any rust programmer in the same way i will never trust anyone else in any industry that needs their hands held. The power of C++ is exactly that, if STL is too generic and bloated you can avoid it and write anything to fit your needs. Impossible with rust. Point me to this legacy garbage?

Rust is very much heading down the path that what people call modern C++ when coding in rust happens basically automatically without developer having to code anything special. Coding something special is to do the unsafe stuff.

Yes rust steals a lot of C++ because C++ does a lot of things correct.

C and C++ the shortest code version of a program will the be highly unsafe one. Short version of a rust program by design is to safer.

This is pure gibberish. C++ is much shorter than many languages unless you do something very specific. is C++ perfect? No it still needs much work in the standard. But all of you writings are pure misunderstandings of C++ or deliberate snake oil to promote a communist product like rust.

[cj.wijtmans]

Yes ! Better tools are for losers ! Linters and sanitizers make us weak ! If you can't find all the bugs just by reading the code you're fired ! Programming languages only went downhill after COBOL !

More lies? You think C++ has no sanitizers or linters? Another idiot with snakeoil lies.

[moltonel]

This is pure unsubstantiated nonsense.

It's just defensive programming, things like "Will this code ever be used in a threaded context ? Better use an atomic to be sure." Tiny inefficiencies that can add up. To be weighed against things like needless bounds checking of course, so YMMV.

You dont have to use unique_ptr, you can write your own to fit your needs as stated several times. Cant do that with rust.

There are plenty of Rust crates for special-purposes smart pointers. But std APIs matter, for any language.

Exactlly, rust holds your hands, which is why i will never trust any rust programmer in the same way i will never trust anyone else in any industry that needs their hands held.

(...)

More lies? You think C++ has no sanitizers or linters? Another idiot with snakeoil lies.

You straight-up misunderstand the argument. The point is that sanitizers/linters (which both C++ and Rust have) are just another way to "hold your hand" which, by your argument, would make any programmer using them untrustworthy, and the language a a whole to be rejected. You're basically using the "good drivers don't need seat belts argument". Being able to use the more dangerous tool doesn't mean that you should. Good programmers use all the tools at their disposal to make better software.

One power of Rust is that it has great integrated sanitizers, that the language enables some sanitizer checks that can't be as good in C++ (despite Google engineer's best attempts), and that you have some guarantee that even third-party Rust code passes those sanitizers.

The power of C++ is exactly that, if STL is too generic and bloated you can avoid it and write anything to fit your needs. Impossible with rust.

Again, this is just as possible with Rust as with C++.

[cj.wijtmans]

It's just defensive programming, things like "Will this code ever be used in a threaded context ? Better use an atomic to be sure." Tiny inefficiencies that can add up. To be weighed against things like needless bounds checking of course, so YMMV.

So you assume everyone to be as stupid as you are?

There are plenty of Rust crates for special-purposes smart pointers. But std APIs matter, for any language.

centralized "crates" dsitrubution is exactly why rust should be avoided. But cool if rust is that flexible. Its a non-argument on either side.

You straight-up misunderstand the argument.

Are you sure you are not the one misunderstanding?

The point is that sanitizers/linters (which both C++ and Rust have) are just another way to "hold your hand" which, by your argument, would make any programmer using them untrustworthy, and the language a a whole to be rejected. You're basically using the "good drivers don't need seat belts argument". Being able to use the more dangerous tool doesn't mean that you should. Good programmers use all the tools at their disposal to make better software.

I expected someone would make this argument.

One power of Rust is that it has great integrated sanitizers, that the language enables some sanitizer checks that can't be as good in C++ (despite Google engineer's best attempts), and that you have some guarantee that even third-party Rust code passes those sanitizers.

Exactly why rust should be avoided.
You know what the funny thing is? I never needed a sanitizer despite writing an entire game engine in C++, no bugs, no memory leaks, no crashes. no nothing.

Again, this is just as possible with Rust as with C++.

So you get the point. You people dont have an argument.

[moltonel]

So you assume everyone to be as stupid as you are?
(...)
You people dont have an argument.

It's hard to tell how much you are fighting cognitive dissonance vs intentionally trolling. This back and forth is going nowhere. Good luck in your macho programming endeavors.

[cj.wijtmans]

It's hard to tell how much you are fighting cognitive dissonance vs intentionally trolling. This back and forth is going nowhere. Good luck in your macho programming endeavors.

Dont make it sound cool now. Also The trolling has mostly come from rusties gaslighting people about "C/C++". Perhaps if you stuck around though i would have given you some pointers about where you can criticize C++.

[Nth_man]

[...] decided to enter rust bloatware. [...].

Some data that is easy to see:
https://archlinux.org/packages/core/x86_64/coreutils/ Installed Size: 15.3 MB
https://archlinux.org/packages/commu...ils-coreutils/ Installed Size: 32.3 MB

Thanks to jarekZ (https://www.phoronix.com/forums/foru...51#post1371851)

[cj.wijtmans]

Some data that is easy to see:
https://archlinux.org/packages/core/x86_64/coreutils/ Installed Size: 15.3 MB
https://archlinux.org/packages/commu...ils-coreutils/ Installed Size: 32.3 MB

Thanks to jarekZ (https://www.phoronix.com/forums/foru...51#post1371851)

What is the package compiled by? Becaus even GCC binaries are known to be a bit bloated. If its not linked by something like llvm or gold linker it could even shrink down to ~11MB most likely. Meaning the rust binaries seem to be about 3 times as large. No idea if that affects CPU cache or not since i dont care to look into rust at all. Linus calling C++ bloated and then implementing rust is just double hilarious. I am pretty sure he is being pressured by linux foundation sponsors like google and microsoft.

[NobodyXu]

What is the package compiled by? Becaus even GCC binaries are known to be a bit bloated. If its not linked by something like llvm or gold linker it could even shrink down to ~11MB most likely. Meaning the rust binaries seem to be about 3 times as large. No idea if that affects CPU cache or not since i dont care to look into rust at all. Linus calling C++ bloated and then implementing rust is just double hilarious. I am pretty sure he is being pressured by linux foundation sponsors like google and microsoft.

Rust is just a toolchain, the binary size depends on how you use it.

It by default links in libstd statically so that's part of the reason it's large, but with build-std, lto, setting abort on panic, strip all symbols, the result binary can be much smaller.
It all depends on the settings and what feature they support.