ML family languages are already the "polyvalent languages" you describe and have been a better choice than C for at least 20 years now. If your goal is seeing adoption of such a language, your time would be better spent fixing the things that lead you to dismiss Haskell and Scala - any new language would certainly be even more of a "niche language" than they are.

> there is a need for a polyvalent language that would enable development of Linux kernel (low level and performance), that would be easy to learn and that would enable quick development

That's a pretty tall order for a single language to support all those desires. But Rust seems to at least aim for that space (it doesn't check all your boxes though).

I'm not sure how old that article is, but parts of gcc suite have been rewritten in a subset of C++ for several years now (https://lwn.net/Articles/542457/), starting from over 10 years ago.

Yes, I know that. C++ is also very much used for game development. C++ allows to build very impressive abstractions that are very handy. The main drawback is that this flexibility has a huge impact on the language. When you switch between two projects writen in C++, it is almost as if they were using a different language. I have understood that this language was a mess in 98 when I have bought the standard and read it completely. In professional projects, I always try to avoid it in favor of java despite all the years I have spent learning and using C++.

Re: C++ allows to build very impressive abstractions that are very handy. The main drawback is that this flexibility has a huge impact on the language. When you switch between two projects writen in C++, it is almost as if they were using a different language.

This has always been the two-edged sword of high abstraction: people use high abstraction to invent idioms that match their OWN head, and other heads have difficultly reading it. I've been in long debates with Lisp fans over the commercial practicality of Lisp. Lisp and its variations have had almost 60 years to "catch on" in the mainstream, and keeps failing, staying a niche. If you keep losing beauty pageants for 60 years, it's time to admit you may be ugly. Just because YOU like it and/or YOU can read a certain style does NOT mean others can.

Domain-specific languages tend to herd people into certain styles and idioms, making cross-staff reading easier, even if it's more typing. Standardization often trumps linguistic parsimony in real-world work. I'm just the messenger. (I'm talking general domains here, not necessarily specific industries.)

My own experience with C++ is mainly limited to game development since the base classes in UE4 are written in and can be extended with C++ (as is most of the engine itself).

Unreal has a crazy bolted on reflection system implemented with its own pre-processor to work around the lack of reflection in C++. Otherwise C++ makes sense there I think because (a) performance is extremely good which is important for games, 3D games in particular; and (b) games are the type of program which can often benefit from OO design and inheritance.

I'm a long time C casual who only recently made the leap to C++, but I know what you mean when you say two C++ codebases can have vastly different styles. Of course that is true of many languages but it does appear to be amplified with C++.

> When you switch between two projects writen in C++, it is almost as if they were using a different language.

I strongly disagree. This may have been the case 20 years ago, but most current projects use C++, not some weird -fno-rtti -no-stdinc -fno-whatever sub-language. Maybe they don't use all the features of the standard library, but which project in Java or Python would ?

Well, to me it's like the way Shakespeare, e e cummings, and Kool Keith all write in the same language.

Context switching between working on work codebase, Chromium code base, and various third party C++ codebases is a headache as much for their basic differences in coding style (use of whitespace, capitalization, naming, etc.) as for their wildly varying build/metabuild processes.

And of course, each implements and then extensively uses their own library features like reference-counted pointers, managed GC pointers, collection data structures, iterator-like abstractions, etc.

> their wildly varying build/metabuild processes.

Boost? I'm sure there's good reason for the -- sui generis -- build system. Always been too underwater to spend much time wondering about why that's a yak I'm shaving.

Not easy, because you want the best of all worlds: safe(1), low level(2), efficient(3), easy to learn(4) and easy to implement (5)? All of that seems quite incompatible to me. And C remains the language of choice, because it fulfills all the needs except safety.

Dynamic typing and garbage collection go directly against the "low level and performant" goals. You can avoid GC with clever lifetime rules (Rust) but that loses "easy to learn".

There's no particular reason you have to use C to write Linux. Linux is written in C because when the project started, that was the most reasonable choice. It persists today because of inertia and because introducing something better, like C++, would cause big flamewars.

People have written perfectly functional and competent kernels in C#, Java and C++ after all. There's no technical reason why you can't do it.

> The fact that such a poor language remains the single sane choice to build the kernel of Linux is a proof of the lack of languages.

Or a deep lack of understanding in our field as to what actually makes a good programming language?