Rust Infrastructure Pull Request Submitted For Linux 6.1!

[Weasel]

Nouveau. Although I wouldn't be surprised if Weasel knows that already. He frequently gets into these types of arguments and always insists anyone who disagrees with him is an idiot. I don't think it matters what kind of experience the other person involved has.

What do you mean with disagree, I legit said how simple it is to not use the standard library, because it's just a fucking API and you can use any other library just as well. How is this calling him an idiot or trolling?!?

He used the standard library as an argument against C, when in C you can even use a C++ library if you know how to. And if he can't, that's his problem, skill issue.

It literally reminds me of the C++ tards who can't code without boost and think the world revolves around them, and so if you don't use boost you are automatically "inferior". And that's their argument, because they don't have a better one. Like fuck off.

[CommunityMember]

It's kinda ironic that this is exciting news mostly thanks to Apple M1 work being done by Lina.

You have the order sort of wrong. Rust was proposed a long time ago for the Linux kernel, and has gone through a long process to finally get pulled in. The Apple M1 DRM driver was written in rust only after it was clear that rust support was going to be merged RSN (otherwise it would have had to be written in C).

One of the goals of accepting rust into the kernel was to lower the overheads of writing and reviewing code, and few would disagree that the DRM subsystem is one where reducing overheads will help going forward.

[uxmkt]

the 0-terminated representation not only makes strlen O(n) as noted previously, but it also means that taking a substring often means performing a heap allocation and copying the contents if you want to be able to use it as a bona fide string (with a final 0), while in Rust you would simply take a slice.

It's ultimately a tradeoff. While the NUL terminator makes strlen O(n), you can pass certain substrings (namely `s.substr(somePos, strlen(s)-somePos)`) with just the 8-byte pointer itself (in comparison to the 16 bytes required for the representation of a typical slice). Simple iteration requires just one register/variable rather than two. Maybe was a concern on low-register architectures like x86-32.

[smitty3268]

What do you mean with disagree, I legit said how simple it is to not use the standard library, because it's just a fucking API and you can use any other library just as well. How is this calling him an idiot or trolling?!?

I didn't make any kind of judgement on the arguments in any of the comments here. I simply made my opinion known that I doubted you would care who you were talking to and would consider their experience pointless, because you tend to always highly value your own take on things and assume everyone else is wrong unless they agree with you.

Am I wrong about that? Now that you for sure know who Karol Herbst is, does that change anything? Judging from one of the replies above, it seems not.

[Weasel]

I didn't make any kind of judgement on the arguments in any of the comments here. I simply made my opinion known that I doubted you would care who you were talking to and would consider their experience pointless, because you tend to always highly value your own take on things and assume everyone else is wrong unless they agree with you.

Am I wrong about that? Now that you for sure know who Karol Herbst is, does that change anything? Judging from one of the replies above, it seems not.

You're mostly right. Although I don't tend to consider people wrong unless it's a fact-based argument. If it's just about opinions, I just state my (differing) viewpoint. For example oiaohm is almost always wrong, and I make no qualms about telling it.

In this case it's a mix. It's definitely true that C doesn't enforce NUL terminated strings, so that's where he was completely wrong. You can even compile C code without the standard library (-nostdlib) and it works perfectly fine. You can still use the standard library if you treat it as just another normal library/API, too. So here he was wrong. Not every standard library is statically linked like Rust's.

But his dependence on standard libraries is just dumb to me. I will never understand such people unless they literally want to write portable code only, but portable code will always perform worse than target-specific code, which is another fact I outlined about standard libraries. Another one he got mad at and pulled a logical fallacy.

Note that target-specific code only needs to be target-specific in a few areas, so it's not like you need to rewrite the entire huge project. For example Firefox has target-specific code in many areas (imagine if it used GTK on Windows, yuck!), but it doesn't mean they rewrote the entire browser for it.

[skierpage]

notice pattern of Rust programmers to rewrite stuff that's already working good?

Yes, and it's generally excellent. They're rethinking utilities like grep, du, find, using rust's excellent CLI support crates for consistent option handling, readline, progress indicators,.etc. The good replacements are generally fast and a joy to use; ripgrep is fantastic. My problem is the old tools are baked into my muscle memory.

You're free to continue on with the same crummy commands we've had for 20 years.

[mdedetrich]

Yes, and it's generally excellent. They're rethinking utilities like grep, du, find, using rust's excellent CLI support crates for consistent option handling, readline, progress indicators,.etc. The good replacements are generally fast and a joy to use; ripgrep is fantastic. My problem is the old tools are baked into my muscle memory.

You're free to continue on with the same crummy commands we've had for 20 years.

Some of the rewrites also end up being faster because they are rewritten with parallelism in mind, which either originally wasn't done or it was done sparingly due to how easy it is to shoot yourself in the foot with it in C.