[mustache_kimono]

> That all said, Rust is not a smoking gun for incorrect application logic. It could still happily incorrectly execute stuff with the wrong permissions or blow something up badly.

This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?

> I think it's also a bad idea to offer it as a drop-in replacement when clearly features are still missing since a long time [1].

Your example is the Github issue page?

Look -- I agree that, say, uutils/coreutils missing locales may frustrate some users (although I almost never use them). But "close enough" is more the Unix way than we may care to realize. But especially in this instance, because sudo is not POSIX (unlike locales which are). A distro is free to choose any number of alternatives.

Ubuntu wants to lay claim to "the Rust distribution" and it's hard to blame them when Linux wants to lay claim to "the Rust kernel".

[b112]

Linux wants to lay claim to "the Rust kernel"

Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.

[mustache_kimono]

> Entirely untrue. It may happen, but there is zero consensus to port Linux to rust. Not even the tiniest bit.

... But I did not say there was a consensus to port Linux to Rust? I'm sorry you misunderstood.

Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust? I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else.

>> Ubuntu wants to lay claim to "the Rust distribution"

Notice, Ubuntu is doing a similar thing. Canonical isn't porting all of Ubuntu to Rust. It is picking and choosing bits which they can, and would like, to move to Rust. Why? Probably for similar reasons. They want to seen as friendly to the Rust mindshare.

[b112]

Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust?

This isn't a thing. Linux isn't laying claim to any such assertion.

If you want to know Linus's reasons, then read the LKML. He's quite open in all of his thoughts in this regard, and it has nothing to do with labeling Linux 'the Rust kernel'.

I don't know if this is some weird sort of advocacy, or you're just listening to a lot of over the top rust people, but nothing you're saying here is real.

[mustache_kimono]

>> ... I believe that there are many reasons why Linus chose to give Rust for Linux a chance. I believe at least one of those reasons is mindshare. If Linux chose not to experiment with Rust drivers, then that mindshare might go somewhere else.

Again, very sorry you misunderstood me. However, I am now pretty certain one of your difficulties is that you stop short of reading my next sentence, and then my next sentence after that. See my quoted comments above. I made very clear these are strictly my beliefs.

> If you want to know Linus's reasons, the read the LKML.

Perhaps when I said "I believe" I was being too subtle about what "my beliefs" are or what "beliefs" mean.

I hope you would agree -- just because one has expressed certain technical reasons/desires does not mean that there were not any unexpressed social reasons/desires, or what philosophers also call "higher order volitions" (long term volitions, or volitions about volitions), for one's actions.

Now -- I do not know but I do believe there may be social reasons for Rust being adopted in the Linux kernel, because I have read the LKML and I have reasoned about why Linux is experimenting with Rust drivers from things Linus and others have said.

Feel free to disagree, of course, but, in the future, please make more of an effort to avoid mischaracterizing me again.

[b112]

Now, why would Linux want to lay claim to being 'the Rust kernel' and how is that different than Linux being rewritten in Rust

Drop the "mischaracterising" routine. You're asserting specific things, so expect to get challenged when they're nonsense.

[mustache_kimono]

> Drop the "mischaracterising" routine. You're asserting specific things, so expect to get challenged when they're nonsense.

If I said "Coca Cola wants to lay claim to being the best cola soda in the world", I'm sure you would also say to me: "Patently untrue. Where exactly in Coca Cola's public statements are we to find that statement?!", instead of, perhaps reflecting, and asking yourself -- is that a reasonable belief for one to hold, given Coca Cola's marketing?

If I am not conforming to your expectations, perhaps it is because your expectations that need a reset.

[bArray]

> This side steps the issue which is "Does Rust help you make software more correct?" No one is arguing that Rust is perfect. There are plenty of bugs in my Rust software. The question is only -- are we better off with Rust than the alternatives?

There is a lot of embedded knowledge in existing implementations, Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.

I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.

[mustache_kimono]

> There is a lot of embedded knowledge in existing implementations,

Agree. The question whether to rewrite and/or whether to use any new implementation should take this fact into account.

> Rust deals with just one small class of bugs but drops a lot of this knowledge in the process.

Hard disagree. Rust explicitly deals with several very important classes of bugs (memory safety and concurrency), and also aids correctness via other helpful design features like tagged unions and immutability by default. But Rust, the language, does not drop any knowledge in the process, though any decision to rewrite in any language may drop some knowledge, and/or may create new bugs, in the process.

> I would generally be in favour of just introducing better memory management to C/C++ and hard enforcing it in particular repositories.

This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.

[0]: https://www.usenix.org/conference/enigma2021/presentation/ga... [1]: https://www.darpa.mil/research/programs/translating-all-c-to...

[bArray]

> This is really easy to say, but in practice it just hasn't worked out, and there is loads of empirical evidence to back that up.[0] It is not as if market incentives don't exist to create better C/C++ code.[1] If you have a way to do it better, I have no doubt Google, half a dozen other hyper-scalers, and the US government will pay you handsomely for your solution. But, at this point in time, if this is the solution, I'm afraid it's time to put up or shut up.

It really wasn't too difficult to get high reliability for memory management in C/C++ which is also concurrency safe (I have active projects running for years like this). The difficulty was enforcing it so that you are reduced to a subset of the language and it has to be followed with discovery at compile time.

The trap I'm concerned we are falling into is the "just re-write the C/C++ project in Rust". I still believe the solution is in enforcing better practices at compile time.