DARPA suggests turning old C code automatically into Rust

[Doctorandus_P]

Maybe making memory safe C++ a better idea.


https://safecpp.org/draft.html

[tggzzz]

Maybe making memory safe C++ a better idea.

That's building an extention to an enormous edifice that is built on sand.

C/C++ are 70s/80s languages which started by defining that any multithread/multicore functions were outside the scope of the language, and were a libraries' responsibility. That was fine in the 70s, but was already a pain point in the 90s.

Rust and Go (and xC ) are pleasingly simple languages (unlike C++) which started by presuming they would run on modern multicore/multiprocessor operation.

Finally people are realising that if C++ is the answer, then you asked the wrong question.

Unfortunately it needs to be recognised that C/C++ will never go away, for the same reasons that COBOL has never gone away.

[SiliconWizard]

That's one reason Rust is a relatively bad answer to this as well. The only thing it kind of deals with is memory ownership. The rest of multiprocessing is still handled via libraries (and there are already several of them for the same job, which adds to the confusion).

[DiTBho]

That's one reason Rust is a relatively bad answer to this as well. The only thing it kind of deals with is memory ownership. The rest of multiprocessing is still handled via libraries (and there are already several of them for the same job, which adds to the confusion).

if we consider one of the worst RISC systems ever, a highly speculative R10K with more than 13 pages of "bad-side effect" due to its nature of being zero hardware support for anything, including cache coherence... then... RUST is even worse than C because you have twice the effort to write "workaround" patchs.

Here the problem is clearly bad hw.

The hw must offer support, it must not be the software that gets to the details of the cache, especially when there are DMA, external COPs and all the things that then are not clear how to model in the language constructs.

(in myC, you can override monads, but it's still ugly)

In effect what *we all do* is sweep the dust under the carpet. In a library, which then "fixes things" by hitting barriers on barriers written in inline-assembly.

kind of Voodoo code.

Now, doing this in RUST... is just much more more convoluted than in C 

[tggzzz]

That's one reason Rust is a relatively bad answer to this as well. The only thing it kind of deals with is memory ownership. The rest of multiprocessing is still handled via libraries (and there are already several of them for the same job, which adds to the confusion).

True enough: Rust isn't the solution to all problems. (Neither is Go, of course).

But the memory ownership issue is a key problem with C/C++, spreading its tentacles into multithreading, multicore processors, multiprocessor computers. Rust has addressed (ho ho) those issues head-on from the beginning, whereas with C/C++ they are a bolt-on afterthought (yuk!) which plays badly with much existing code. Hence Rust is a significant and useful advance.

A few years ago I decided to keep a weather eye on Rust and Go; they seemed to have advantages but it was unclear whether they would materialise in practice. History is littered with a succession of irrelevantly different "languages du jour" (e.g. C#, Delphi, Perl), and it is beneficial to ignore most of those.

It is becoming clearer that Go and Rust will have a solid future, even if they aren't finished yet. As with all scientific/engineering revolutions, advances are made in a generational timeframe, as the current incumbents die.

[DiTBho]

It is becoming clearer that Go and Rust will have a solid future, even if they aren't finished yet.

So it seems. There are more and more tools written in Go
Text editors, versioning tools (lazy git), ...

[Nominal Animal]

I claim object access (range) validation and synchronization is a bigger problem than memory ownership, considering the number and severity of related problems.  Locking schemes are difficult for us humans to design properly, so static analysis of those would be very important too.  Coroutine and async support would be nice.

I firmly believe these cannot be solved via increased abstraction, abstracting away the implementation and giving the developers tools to avoid thinking about these.  An intuitive and effective way of annotating accesses, expressions, and arbitrary sections of code is needed.  Function/member annotations like "must hold lock X when calling/accessing this" would be very useful, even if only heuristically verified by static code analysis.

A particular detail that bugs me in C and C++ is that you designate an object atomic, instead of specific accesses to it.  Just think about the locking nightmare if the compiler is allowed to reorder a pair of accesses to atomic objects, when such atomicity requires locks at the machine code level?  Yeah, deadlocks galore.

[tggzzz]

Wouldn't it be more usefull to analyse the code for potential buffer overflows and mitigate those?

That is already done, but naturally only to the extent it is possible. If it was possible, then that analysis would be useful in many areas, e.g. optimising compilation.

The possibility of pointer aliasing kills many performance optimisations. The mitigation is compiler command line arguments to the effect that "I promise that my code and the code I call in other companies' libraries doesn't misbehave". Yeah right.

Such compiler command line arguments affect the generated code as much as the source code, and ought to be part of the language definition.

Meanwhile, back on planet Earth....

[tggzzz]

It is becoming clearer that Go and Rust will have a solid future, even if they aren't finished yet.

So it seems. There are more and more tools written in Go
Text editors, versioning tools (lazy git), ...

... duplicates of C libraries such as coreutils, https://www.phoronix.com/news/Rust-Coreutils-uutils-0.0.28 , openssl https://www.phoronix.com/news/Rustls-0.23.17-Released etc

If you have foundation that is more theoretically sound than C's foundation, then more sound optimizations become possible.

[tggzzz]

I claim object access (range) validation and synchronization is a bigger problem than memory ownership, considering the number and severity of related problems.  Locking schemes are difficult for us humans to design properly, so static analysis of those would be very important too.  Coroutine and async support would be nice.

Locking is the low level primitive on which usable, composable high level abstractions can be built.

I firmly believe these cannot be solved via increased abstraction, abstracting away the implementation and giving the developers tools to avoid thinking about these.  An intuitive and effective way of annotating accesses, expressions, and arbitrary sections of code is needed.  Function/member annotations like "must hold lock X when calling/accessing this" would be very useful, even if only heuristically verified by static code analysis.

A particular detail that bugs me in C and C++ is that you designate an object atomic, instead of specific accesses to it.  Just think about the locking nightmare if the compiler is allowed to reorder a pair of accesses to atomic objects, when such atomicity requires locks at the machine code level?  Yeah, deadlocks galore.

All that is still too low level.

More useful system-level abstractions have been developed over the decades. Starting points are realtime design patterns[1], enterprise automation design patterns, and high performance computing design patterns.

Naturally nothing will prevent inappropriate use of such design patterns, and it is still possible to get system level deadlock and livelock. But at least you have shifted the problems to a higher level, away from the implementation domain and towards the problem domain.

[1] one I've used repeatedly in various forms over the decades is the half-sync half-async  pattern https://www.dre.vanderbilt.edu/~schmidt/PDF/PLoP-95.pdf

[SiliconWizard]

I claim object access (range) validation and synchronization is a bigger problem than memory ownership, considering the number and severity of related problems.  Locking schemes are difficult for us humans to design properly, so static analysis of those would be very important too.  Coroutine and async support would be nice.

Agreed.

[tggzzz]

I claim object access (range) validation and synchronization is a bigger problem than memory ownership, considering the number and severity of related problems.  Locking schemes are difficult for us humans to design properly, so static analysis of those would be very important too.  Coroutine and async support would be nice.

Agreed.

A lot of system design and programming is bridging the gap between the processor level abstractions (ISA, caches, memory consistency, multicores) and the problem domain level abstractions. Usually there are several levels of abstractions (programming languages, libraries, design patterns) between the two ends. Finding a single person that can think at all levels is, um, challenging.

Anything that makes it easier to create executables that are structured so that a problem domain specialist can understand and reason about the code is very valuable.

Unfortunately too often abstractions are layered on each other without understanding the underlying abstractions. If you doubt that, start by considering the numbers of synchronous and asynchronous protocols between, say, a network PHY and an enterprise application.

[Nominal Animal]

Unfortunately too often abstractions are layered on each other without understanding the underlying abstractions.

My point exactly.  Added abstractions are not the correct answer.  Yet, that is exactly what we are doing.

As you know, I personally prefer using C for systems and library programming, and switch to interpreted high-level languages like Python for the UI.  Not to manage abstractions per se, but to solve the particular problems at the same level of abstraction, simplifying the interdependencies.

The recent storm in a teacup about Rust and the Linux kernel internal interfaces (lack of internal APIs, and subsystem maintainers being unwilling to commit to maintaining them for Rust developers), and the number of abstractions and additions and annotations Rust requires for interoperability with foreign machine code, makes me believe it is not the correct direction either for low-level code.  I see it falling to the same trap C++ did, trying to be everything for everyone, while still trying to discover what it should be and might be, and growing all sorts of warts extending and ballooning itself as a result.

I suspect that to properly solve the human capability versus abstraction issues, we'll need different programming languages at different complexity levels.  Even in Python, you already have three different string formatting approaches, two completely different ones; just like in PHP, when they added OOP on top you ended up with a doubled standard library, with two or more approaches to solving every problem.  In theory, that sounds like only a good thing, but when you mix in humans with our limited capabilites, it turns out that simplified tools work better.  Which, in turn, leads us back to Unix philosophy: simple, modular tools that you connect together, instead of All-Encompassing Frameworks to Solve All Problems Everywhere.

In that light, the DARPA suggestion is similar to the political revolutions, where the former oppressed become the new rulers, and former rulers the new oppressed, but nothing actually changes.  I guess it is a good gig if you get paid for turning the wheel in place, though.  Me, I just want to solve problems and make better stuff, not tell others what to do and how (unless they explicitly ask).

[magic]

The recent storm in a teacup about Rust and the Linux kernel internal interfaces (lack of internal APIs, and subsystem maintainers being unwilling to commit to maintaining them for Rust developers), and the number of abstractions and additions and annotations Rust requires for interoperability with foreign machine code, makes me believe it is not the correct direction either for low-level code.  I see it falling to the same trap C++ did, trying to be everything for everyone, while still trying to discover what it should be and might be, and growing all sorts of warts extending and ballooning itself as a result.

I also find this fad annoying, and I hope that it will ultimately lead to Yet One More Programming Language, this time designed for close interoperability with C and for converting existing C codebases rather than rewriting them from scratch or wrapping in pointless glue layers. Obvious crippling limitations of this month's Safe Language Of The Month are lack of type erasure to naturally cover the countless uses of void* out there and opaque vtables (like in C++) which can't straightforwardly interoperate with equally countless object oriented designs in C.

For low level use case "tagged unions" and "traits" should be simple annotations to raw C-style structures which constrain their semantics, giving you control over memory layout for interoperability with other languages, with hardware, with anything that isn't Safe Language Of the Month which you may need to work with.

Safe Language Of The Month was designed by application developers to replace C++ and I suppose it has a good chance in this space, but the attempts at pushing it into traditional C areas is just that: annoying. Hopefully YOMPL will learn from those mistakes and offer an actual viable migration path from C, and there is certainly a growing demand for that.

[tggzzz]

I've omitted points that I agree with.

As you know, I personally prefer using C for systems and library programming, and switch to interpreted high-level languages like Python for the UI.  Not to manage abstractions per se, but to solve the particular problems at the same level of abstraction, simplifying the interdependencies.

Simplifying the interdependencies is always important, but I'm not sure I'd put it in terms of "... same level of abstraction".

Some abstractions are impossible to sensibly hide, and trying to do so leads to subtle errors. A classic example is distributed computing, where too many libraries try to pretend that https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing don't exist. Many times low-level failures can only be correctly dealt with at the top level.

The recent storm in a teacup about Rust and the Linux kernel internal interfaces (lack of internal APIs, and subsystem maintainers being unwilling to commit to maintaining them for Rust developers), and the number of abstractions and additions and annotations Rust requires for interoperability with foreign machine code, makes me believe it is not the correct direction either for low-level code. 

That is a serious and important impedence mismatch, but I don't agree with your conclusion. That impedance mismatch is largely a culture clash, and with the technology clash being the less important aspect.

The counter example to your conclusion will come when Rust becomes sufficiently effective to implement a kernel. Redox https://www.redox-os.org/ is a good start. Practically it isn't there yet, but I haven't seen any theoretical show stoppers.

I see it falling to the same trap C++ did, trying to be everything for everyone, while still trying to discover what it should be and might be, and growing all sorts of warts extending and ballooning itself as a result.

C with classes C++ has always been a distasteful mess, where the creators were too ignorant to plant a pole in the ground saying "this is a good set of concepts that have been shown to play well together". Instead they punted the problems to their users, hoping they would sort them out (they didn't).

Unfortunately in the 1990s C also fell into the trap of trying to be both a low level and an application level language. Either choice would have been OK, but the result is a mess. Hence we have Java and Python taking over the application domains, and C becoming too complex for low level stuff.

Which, in turn, leads us back to Unix philosophy: simple, modular tools that you connect together, instead of All-Encompassing Frameworks to Solve All Problems Everywhere.

I like languages where their white paper states "X and Y have previously been shown to work well and work together, but Z has been omitted because of the problems it causes". In other words, simple modular concepts and abstractions that play well together.

In that light, the DARPA suggestion is similar to the political revolutions, where the former oppressed become the new rulers, and former rulers the new oppressed, but nothing actually changes.  I guess it is a good gig if you get paid for turning the wheel in place, though.  Me, I just want to solve problems and make better stuff, not tell others what to do and how (unless they explicitly ask).

Every {technical, legal, corporate, political} empire starts small, then accretes crap, and that forms the basis for their demise. They rot from within.

[tggzzz]

The recent storm in a teacup about Rust and the Linux kernel internal interfaces (lack of internal APIs, and subsystem maintainers being unwilling to commit to maintaining them for Rust developers), and the number of abstractions and additions and annotations Rust requires for interoperability with foreign machine code, makes me believe it is not the correct direction either for low-level code.  I see it falling to the same trap C++ did, trying to be everything for everyone, while still trying to discover what it should be and might be, and growing all sorts of warts extending and ballooning itself as a result.

I also find this fad annoying, and I hope that it will ultimately lead to Yet One More Programming Language, this time designed for close interoperability with C and for converting existing C codebases rather than rewriting them from scratch or wrapping in pointless glue layers. Obvious crippling limitations of this month's Safe Language Of The Month are lack of type erasure to naturally cover the countless uses of void* out there and opaque vtables (like in C++) which can't straightforwardly interoperate with equally countless object oriented designs in C.

For low level use case "tagged unions" and "traits" should be simple annotations to raw C-style structures which constrain their semantics, giving you control over memory layout for interoperability with other languages, with hardware, with anything that isn't Safe Language Of the Month which you may need to work with.

Safe Language Of The Month was designed by application developers to replace C++ and I suppose it has a good chance in this space, but the attempts at pushing it into traditional C areas is just that: annoying. Hopefully YOMPL will learn from those mistakes and offer an actual viable migration path from C, and there is certainly a growing demand for that.

Avoiding the variant-language-of-the-month is key professional skill, but it is also necessary to encourage advances and then to spot and use the benefits. Such advances and benefits seem to happen once a decade or so, and take a generation to become understood and accepted.

Any language with untyped memory is an architectual sand pit. It is much safer and more expandable to have untyped variables operating on typed memory. Even better to have typed variables and typed memory; the former enables better/faster source code and tools, the latter enables safety/debugging.

C and C++, of course, have untyped memory - which causes endless problems.

I'd much rather concentrate my efforts on discovering and ameliorating the problems inherent in the application domain. I dislike tools that add their own problems, and prefer tools that help me solve application domain problems.

[JPortici]

That is a serious and important impedence mismatch, but I don't agree with your conclusion. That impedance mismatch is largely a culture clash, and with the technology clash being the less important aspect.

The counter example to your conclusion will come when Rust becomes sufficiently effective to implement a kernel. Redox https://www.redox-os.org/ is a good start. Practically it isn't there yet, but I haven't seen any theoretical show stoppers.

Having an actual specification and a compiler conforming to said also would help, same for embedded, or we are all going to have the same exact arguments we see about C (see for example the code-size limited thread in the microcontroller section) all over again, but with a more toxic community behind them.

[madires]

I wonder if it is actually feasible to turn C code into Rust automatically. Or would it make more sense to fix the memory management bugs and security issues in the old C code? Using Rust (or whatever) for new projects could be a reasonable approach to tackle the typical sloppiness of C developers regarding memory management. It would decrease the attack surface to some extend. However, there are many things more that can be screwed up. If a developer can't manage memory, how likely will he also fail to validate some input? I think, teaching developers to write good and secure code is the best way to go forward. The programming language isn't that important, but how it is used matters.

[tggzzz]

I wonder if it is actually feasible to turn C code into Rust automatically.

It is feasible provided either you want to duplicate the bugs or the tool automatically determines the intended operation and implements that.

Oh.

[tggzzz]

My RSS feed has just thrown up this example of abstraction leakage, plus how C/C++ compiler command line arguments are in effect part of the language (ugh).

https://www.phoronix.com/news/Torvalds-Mind-Fart-x86_64-Level

[coppice]

My RSS feed has just thrown up this example of abstraction leakage, plus how C/C++ compiler command line arguments are in effect part of the language (ugh).

https://www.phoronix.com/news/Torvalds-Mind-Fart-x86_64-Level

Those CPUID bits are a serious PITA. What started as a nice "I can detect how advanced the machine is, and see which tricks will work" feature has become a free for all "let's fragment the fragments of the fragments" kind of thing. What brain dead idiot thought making 1000 different configurations of what an x86_64 machine might be would encourage programmer to get the best out of them?

[tggzzz]

My RSS feed has just thrown up this example of abstraction leakage, plus how C/C++ compiler command line arguments are in effect part of the language (ugh).

https://www.phoronix.com/news/Torvalds-Mind-Fart-x86_64-Level

Those CPUID bits are a serious PITA. What started as a nice "I can detect how advanced the machine is, and see which tricks will work" feature has become a free for all "let's fragment the fragments of the fragments" kind of thing. What brain dead idiot thought making 1000 different configurations of what an x86_64 machine might be would encourage programmer to get the best out of them?

Intel and AMD, of course

With the exception of backwards compatibility, to them software is an "externality" - i.e. somebody else's problem.

[Nominal Animal]

Simplifying the interdependencies is always important, but I'm not sure I'd put it in terms of "... same level of abstraction".

What I mean by that, is that I want a low level imperative language with minimal abstractions to implement low level library, number crunching, and data processing libraries and system services.  For graphical UIs, I want an event driven language with high abstractions (but good interface to low level machine code, preferably with minimal added machine code).

I do not want a single language that can do both, because that means others modifying or writing more code have a high chance of using the wrong paradigm.  (And that is assuming I get it right myself, which is definitely not guaranteed!)

A classic example is distributed computing, where too many libraries try to pretend that https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing don't exist. Many times low-level failures can only be correctly dealt with at the top level.

Ah yes, now I see your point.  I definitely agree, because one of my buttons is how most current distributed molecular dynamics simulators compute then communicate, wasting a lot of potential CPU time, rather than communicate while computing, simply because their designers didn't want the added complexity of thinking how to do it right (which is spatial subdivision of the simulated volume, and computing these in a specific order that allows the shared regions to be communicated to neighboring nodes while computing the non-shared regions).

That is a serious and important impedence mismatch, but I don't agree with your conclusion. That impedance mismatch is largely a culture clash, and with the technology clash being the less important aspect.

Perhaps; I am often wrong.  In that case, however, I don't see how a cultural change will solve the added workload of maintaining the C-Rust interfaces required for Rust.  My opinion is also coloured by observing how much abstractions and changes to Rust itself I see discussed at LKML, for achieving an usable C-Rust interface.

The counter example to your conclusion will come when Rust becomes sufficiently effective to implement a kernel.

No, because you can write a kernel in any sufficiently low-level programming language.  The counter example will be when you have a functional kernel written in one of these new languages with core functionality easier to manage –– considering the modification rate in the Linux kernel, i.e. refactoring and changes, not just bugfixes and maintenance against bitrot –– and preferably with lower bug density, than the Linux kernel.

That, I believe, is the true test by fire for a low level language.  For a kernel, it will also need to have high enough performance, which in practice means low cost of kernel calls, high-bandwidth low-latency userspace - kernel data transfers, regardless of kernel design (monolithic or microkernel), but the main weight, in my opinion, should be how well human users can use it.

(I do not believe in using the average human developer as a metric, though.  Any tool can be misused; see real world issues with firearms.  Rather, I want to focus on the best existing examples, best open source code implemented with finite resources, to evaluate the language used.)

Unfortunately in the 1990s C also fell into the trap of trying to be both a low level and an application level language. Either choice would have been OK, but the result is a mess.

Yep.  I can do a graphical UI in C using Gtk+, and it isn't horrible, but one has to be quite careful to avoid bugs and issues.

Combining Gtk+ UI and low level data processing or computing, I personally need to "switch" between paradigms or complexity levels or whatever you want to call them, and treat the two as if I were using different programming languages: I need to think in different patterns.  When you add to that the communication needed between the two, it just isn't worth it for anything except basic tools and examples (of what is possible, to motivate learners).

I like languages where their white paper states "X and Y have previously been shown to work well and work together, but Z has been omitted because of the problems it causes". In other words, simple modular concepts and abstractions that play well together.

Yep, exactly: interoperability, not encompassing frameworks.

I do not particularly like Python either.  I use it because it interfaces to low-level code so easily, and allows one to create event-driven graphical user interfaces at the same level that you can get humans to think of.  (My examples of Python + Qt5, using Qt Designer -edited XML .ui files, with events mapped to systematically named methods in your main window class implementation, are exactly that: no matter where or what it is, you need to give a widget a name, and look up the name of the signal/event generated from the documentation, and that will tell you the name of the method you need to implement.  Plus, it allows UI editing by modifying the XML –– even multiple UIs one can choose from at run time ––; and UI behaviour by modifying the interpreted human-readable code.)

I do believe it was a masterstroke from Guido van Rossum to ensure C interoperability.  Without that, I do not believe Python would be as popular as it is now.  Interoperability with any shimming implemented in the high-level language side is possibly Python's strongest point.

Every {technical, legal, corporate, political} empire starts small, then accretes crap, and that forms the basis for their demise. They rot from within.

Competition that drives crap removal is the only cure I know.

I do not believe in revolutions, because they just tend to turn the pyramid upside down, but not change its composition otherwise; and very soon it will be indistinguishable from the previous one.  Same with enemies, as we see in the world right now: all countries seem to be striving towards 1984-style dystopian eusocial systems, pointing out the flaws in others while blithely ignoring the same ones in themselves.

Gradual changes seem to work much better.

It is also the reason why I don't dabble with creating my own "better than C" low-level programming language.  C has a track record and untold hours of development by brains better than mine.  What I do as a hobby, is investigate the free-standing environment; replacing the (optional!) C Standard Library with something better, because that is compatible/interoperates with everything fluently.  It is by no means perfect, and I do wish I could change specific things even in C (namely, swap pointers and arrays, allowing compile time bounds checks over function calls), but it is better than any "revolution" I could instigate (programming language I could design).


None of this is to say I won't use Rust myself!  I wrote all this because I wanted to point out how silly the idea of automatically converting code from one paradigm and language to another is, and how silly, in light of history and all we know, the idea of Rust becoming the new C is.  Rust should be Rust, and evolve to fit whatever niche it finds, and not try to be everything for everyone because that has been tried several times and has always failed –– including C!

What that niche will be, I do not know, but seeing how I happily use even PHP in specific circumstances (webhotels with limited server-side language support), I fully expect myself to be happily using Rust also at some point.  (Thus far, I've been looking at how its developers approach problem-solving, and I'm not sure I like it yet: it seems too abstract for my needs at this point, too focused on achieving their goals, and not focused enough on actual results and behaviour of the result.  Like academics discussing mathematics from the point of proofs, when all I'm interested in is using it as a tool to solve problems.  It is my impression only, though.)

[SiliconWizard]

There is a point in this endless "safe language" debate that I find interesting (and yes, I know I talk about it on a regular basis). We have a quite reasonably safer language in many respects, and it's Ada.
The recent revisions of the language make it pretty nice.
There is just one thing, for which I have (probably like you do) a few answers, but nothing that I find completely rational: outside of niche fields, nobody uses it.

I admit I don't use it either. Yes, I have a few reasons, again, but they aren't all completely reasonable. One is that there are much fewer compilers available than for other languages like C, C++ and even Pascal! (For Rust, that's not true at all though, as there is basically only one compiler, which freaks me out, among other things.) But still, GCC does support it and it's open and free. Though users in safety-critical fields tend to favor commercial compilers (which can be very expensive), so I can't tell for sure how robust the Ada GCC front-end is.

Is the compiler thing the only reason we don't use it though? Not so sure.
Syntax? Who cares, I personally don't mind and find it a lot more readable than Rust. It probably icks the Javascript nerds though.

Although you can use pretty lean runtimes for embedded dev, it yields "heavier" compiled code on average, so for very small targets, it may not be the best candidate. But otherwise?

It kind of puzzles me. Again, I'm questioning myself too, as I don't use it either, although that's something I've been planning on doing for years now.

[tggzzz]

That is a serious and important impedence mismatch, but I don't agree with your conclusion. That impedance mismatch is largely a culture clash, and with the technology clash being the less important aspect.

Perhaps; I am often wrong.  In that case, however, I don't see how a cultural change will solve the added workload of maintaining the C-Rust interfaces required for Rust.  My opinion is also coloured by observing how much abstractions and changes to Rust itself I see discussed at LKML, for achieving an usable C-Rust interface.

A cultural change is indeed unlikely to be sufficient in this case. I suspect it is necessary.

Rust and its community is not "innocent" in this area - and that is likely to continue as long as Rust is changing.

The counter example to your conclusion will come when Rust becomes sufficiently effective to implement a kernel.

No, because you can write a kernel in any sufficiently low-level programming language.  The counter example will be when you have a functional kernel written in one of these new languages with core functionality easier to manage –– considering the modification rate in the Linux kernel, i.e. refactoring and changes, not just bugfixes and maintenance against bitrot –– and preferably with lower bug density, than the Linux kernel.

I have this fantasy that if there is a good language, concept abstraction, coherence and coupling, then any single code mutation will have only local effects. That makes life much easier!

I like to think that a decent language will circumvent some problems, making them a non-issue. That kind of thing does occasionally happen.

It remains to be seen the extent to which Rust and Go will aid those aspirations.

That, I believe, is the true test by fire for a low level language.  For a kernel, it will also need to have high enough performance, which in practice means low cost of kernel calls, high-bandwidth low-latency userspace - kernel data transfers, regardless of kernel design (monolithic or microkernel), but the main weight, in my opinion, should be how well human users can use it.

Are you aware of The Mill Processor's and toolchain's architectural concepts? They are radically different to today's processors with many performance improvements. While their starting inspiration is the commercially successful Burroughs Algol systems, a specific principal objective is to be able to run unmodified C code exceptionally fast.

Shame none exist, due to the x86 inertia. I suspect some of their heavily-patented ideas will be found in future processors.

I like languages where their white paper states "X and Y have previously been shown to work well and work together, but Z has been omitted because of the problems it causes". In other words, simple modular concepts and abstractions that play well together.

Yep, exactly: interoperability, not encompassing frameworks.

I don't think I was sufficiently clear. My X,Y,Z are language features. A classic example of a "Z" is "multiple inheritance of implementation", omitted because it has been shown to be the source of many language problems.

Every {technical, legal, corporate, political} empire starts small, then accretes crap, and that forms the basis for their demise. They rot from within.

Competition that drives crap removal is the only cure I know.

Such crap removal is thwarted by the requirement for backward compatibility. The latest Windows still contains some GUI dialogs that are unchanged from Win 3.1; IIRC the ODBC config dialog looks positively primeval
https://www.reddit.com/r/Windows10/comments/o1x183/the_famous_windows_31_dialogue_is_again_in/#lightbox


Backwards compatibility also thwarts revolutions.

Gradual changes are like hill-climbing genetic algorithms: at best they find local peaks, but can't jump to hills with higher peaks.

None of this is to say I won't use Rust myself!  I wrote all this because I wanted to point out how silly the idea of automatically converting code from one paradigm and language to another is, and how silly, in light of history and all we know, the idea of Rust becoming the new C is.  Rust should be Rust, and evolve to fit whatever niche it finds, and not try to be everything for everyone because that has been tried several times and has always failed –– including C!

What that niche will be, I do not know, but seeing how I happily use even PHP in specific circumstances (webhotels with limited server-side language support), I fully expect myself to be happily using Rust also at some point.  (Thus far, I've been looking at how its developers approach problem-solving, and I'm not sure I like it yet: it seems too abstract for my needs at this point, too focused on achieving their goals, and not focused enough on actual results and behaviour of the result.  Like academics discussing mathematics from the point of proofs, when all I'm interested in is using it as a tool to solve problems.  It is my impression only, though.)

We need something to consign C/C++ to being equivalent to COBOL.

So far Rust is the best candidate for the mid-to-low level use cases, but time will tell. C/C++ has already lost the mind set for high level use case applications, with new applications implemented in Java, Python, Go, plus other more domain-specific languages.