MS going to rust (and Linux too)

[Dmitry A. Kazakov]

Apparently Microsoft does not want to use C/C++ anymore:

https://www.zdnet.com/article/programming-languages-its-time-to-stop-using-c-and-c-for-new-projects-says-microsoft-azure-cto

and going to Rust. No word about glorious VBA and illustrious C#,
though. The best ever inventions of computing era deserve no mention...
(:-))

Ah, GC does not sit well with them, who might think? (:-))

BTW, It seems that Linux kernel will rust as well...

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Luke A. Guest]

On 24/09/2022 08:52, Dmitry A. Kazakov wrote:
> Apparently Microsoft does not want to use C/C++ anymore:

Yeah, they're 20 years behind, I came to that conclusion then.

> https://www.zdnet.com/article/programming-languages-its-time-to-stop-using-c-and-c-for-new-projects-says-microsoft-azure-cto

Well, people and companies will follow like sheep.

> and going to Rust. No word about glorious VBA and illustrious C#,
> though. The best ever inventions of computing era deserve no mention...
> (:-))

They'll stay as they are but likely will move to being implemented in rust.

> Ah, GC does not sit well with them, who might think? (:-))

Go is weird.

> BTW, It seems that Linux kernel will rust as well...
>

There was conversation about using zig as well a while ago.

[Dmitry A. Kazakov]

On 2022-09-24 10:50, Luke A. Guest wrote:

>> and going to Rust. No word about glorious VBA and illustrious C#,
>> though. The best ever inventions of computing era deserve no
>> mention... (:-))
>
> They'll stay as they are but likely will move to being implemented in rust.

I bet MS-Rust gets written in QBasic... (:-))

>> BTW, It seems that Linux kernel will rust as well...
>
> There was conversation about using zig as well a while ago.

This one is from Linus himself.

Anyway, as expected, since computing resources begin actively
stagnating, damn, even a used rusted (no pun intended (:-)) 3 years old
HDD is twice more expensive now, the SW industry slowly turns away from
well established practices of not caring about performance, efficiency,
quality etc. I wonder, who will first dare proclaim that Agile was
trash... (:-))

[Gautier write-only address]

Sounds like "U.S. Department of Defense going to Ada" :-) ...

[G.B.]

On 24.09.22 11:13, Dmitry A. Kazakov wrote:
> On 2022-09-24 10:50, Luke A. Guest wrote:
>

>>> and going to Rust. (...)
> I wonder, who will first dare proclaim that [xyz] was trash... (:-))

Won't it be the presenter to use [xyz] in an economically informed
speech about a new trendy replacement that is already a thing.

Trash in systems obeys a universal law, familiar to every consultant.
That it piles up, and while leading to stagnation, trash also
creates opportunities
- for oblivion,
- for cleaning out and
- for rebuilding.
A fresh start.

As a starting point, Rust has the fine mechanisms that will
facilitate turning the language into a generator of
consumable goods, including itself. It is, therefore,
economically viable.
By design, Rust meets many a business demand, since it doesn't stop
at just technical ideas, of which it inherits many.


Write a really good driver for Linux using Ada 2012 and do not use
capital letters in the source text, at least where Linux doesn't.
Be silent about the language. Can an Adaist do that, to save the
language?

[Dmitry A. Kazakov]

On 2022-09-24 13:41, G.B. wrote:

> Write a really good driver for Linux using Ada 2012 and do not use
> capital letters in the source text, at least where Linux doesn't.
> Be silent about the language. Can an Adaist do that, to save the
> language?

The song remains same. No, Python need not to have Linux drivers in
order to be hugely popular, like the Herpes virus need not to be...

And it is not about Ada. It is about a potentially turning point as the
SW developing process hits certain limits one ignored before. Selling
hot air is a very respectable and profitable activity, but in this case
the reality begin showing its ugly bigotry face. Though Ada could
provide some answers, it is not in the game anyway. Nevertheless, things
become interesting...

[Nasser M. Abbasi]

On 9/24/2022 2:52 AM, Dmitry A. Kazakov wrote:

>
> BTW, It seems that Linux kernel will rust as well...
>

fyi;

This is a link that talks about using rust in linux kernel

"Linux embracing Rust will boost robotics community"

"Linus Torvalds mentioned that the Rust programming
language would be used in the upcoming Linux 6.1 kernel"

<https://www.therobotreport.com/linux-embracing-rust-will-boost-robotics-community/>

What I do not understand is, why not Ada instead of rust?
I thought Ada was designed for embedded low level software.

May be it is just more verbose than rust, and do not use {}.

--Nasser

[Luke A. Guest]

On 24/09/2022 12:41, G.B. wrote:

> Write a really good driver for Linux using Ada 2012 and do not use
> capital letters in the source text, at least where Linux doesn't.
> Be silent about the language. Can an Adaist do that, to save the
> language?

The biggest problem is that the compiled runtime is compiler version
dependent and the pain of making a runtime for linux kernel dev
available for each and every compiler version, remember these things can
also change on a version change too.

[Dmitry A. Kazakov]

On 2022-09-24 14:46, Nasser M. Abbasi wrote:

> What I do not understand is, why not Ada instead of rust?
> I thought Ada was designed for embedded low level software.

Look it this way. If Linus was not aware 30 years ago that there were
better OSes than UNIX and better languages than C, why should he
suddenly do now?

> May be it is just more verbose than rust, and do not use {}.

It is never technical. You can try to rationalize your preference
afterwards, but in reality it is free will at play, even in the case of
choosing Ada.

[Emmanuel Briot]

There is also a lot more emphases on performance in the Rust world than in the Ada world. Part of this is due to resources, but a lot has to do with how the language itself is defined unfortunately.
People working on the linux kernel are definitely interested in performance (and remember they are using any programming language is a significantly different fashion than other programmers).
People coming from C++ likely initially chose that language because it was advertised as the most performant.

[G.B.]

Won't the Ada run-time need very little?
Even the full Ravenscar profile seems to offer too much,
as, for example, Linux kernel drivers need no Ada tasking
at all. Would I want Ada exceptions in drivers?
And to hell with Ada Strings and non-kernel I/O ;-)

If a "kernel-profiled" flavor of protected types will be
an interesting approach to handling events and race
conditions, by basing protected objects on kernel primitives,
then I imagine their implementation to be another nice one
_not_ to brag about, but to just use. Every language is adding
"await" and "async", Java has gone lower than "synchronized"
many versions ago. Every language is not just catching up,
from users' POV...

Ada 2022 is full of popular niceties (cf. "Ada 2022 Overview posted").
Combine them with added insight into program properties
when using SPARK and similar features. The resulting language
needs no mention of the name "Ada" at all in order to be convincing.

[G.B.]

On 24.09.22 15:36, Dmitry A. Kazakov wrote:

> Look it this way. If Linus was not aware 30 years ago that there were better OSes than UNIX and better languages than C, why should he suddenly do now?

Why not? He is actually talking about Rust, given C.

> It is never technical.

It needs to be technical to some extent.
Suggesting to write a kernel in Python would
encounter some technical opposition.

> You can try to rationalize your preference afterwards, but in reality it is free will at play, even in the case of choosing Ada.

The point is that it's not free will.
It seems about choice and about what drives choice.
Some very old job descriptions very sincerely
include "manipulating public opinion".

Think "Ada mandate"... Or better, don't, just don't.

[Dmitry A. Kazakov]

On 2022-09-24 19:56, G.B. wrote:
> On 24.09.22 15:36, Dmitry A. Kazakov wrote:
>
>> Look it this way. If Linus was not aware 30 years ago that there were
>> better OSes than UNIX and better languages than C, why should he
>> suddenly do now?
>
> Why not? He is actually talking about Rust, given C.

He is just growing old... (:-))

>> It is never technical.
>
> It needs to be technical to some extent.

To some very infinitesimal extent. Actually my point was that the extent
has an obvious tendency to grow now. Which is why we observe knee-jerk
reactions from some weaklings... (:-))

> Suggesting to write a kernel in Python would
> encounter some technical opposition.

Honestly? The next generation will fully embrace Python as soon the last
of the old farts retire. Linux held way too long, IMO... (:-))

>> You can try to rationalize your preference afterwards, but in reality
>> it is free will at play, even in the case of choosing Ada.
>
> The point is that it's not free will.
> It seems about choice and about what drives choice.

Huh, in not so distant future I expect drivers using HTTP to communicate
inside the kernel encoding data in JSON and XML and written in Java
script... I am almost serious. This garbage triumphally marches across
embedded world right now, so no smiley.

[Luke A. Guest]

On 24/09/2022 18:49, G.B. wrote:
> On 24.09.22 15:05, Luke A. Guest wrote:
>> On 24/09/2022 12:41, G.B. wrote:
>>
>>> Write a really good driver for Linux using Ada 2012 and do not use
>>> capital letters in the source text, at least where Linux doesn't.
>>> Be silent about the language. Can an Adaist do that, to save the
>>> language?
>>
>> The biggest problem is that the compiled runtime is compiler version
>> dependent and the pain of making a runtime for linux kernel dev
>> available for each and every compiler version, remember these things
>> can also change on a version change too.
>
> Won't the Ada run-time need very little?

You would need to generate bindings to the linux header files per release.

1) I guarantee you he will have a hissy fit over having to have a
bootstrap compiler.
2) Likely another hissy fit because gcc's binding generator has a
propensity for stripping out names and replacing them with useless
"arg*" type identifiers.

There are likely some small parts you might want, maybe a small
secondary stack? Partial interfaces.c packages.

[Simon Wright]

"Luke A. Guest" <lag...@archeia.com> writes:

> 2) Likely another hissy fit because gcc's binding generator has a
> propensity for stripping out names and replacing them with useless
> "arg*" type identifiers.

g++'s binding generator makes a (somewhat) better job, I found

[G.B.]

On 24.09.22 21:07, Dmitry A. Kazakov wrote:

> Huh, in not so distant future I expect drivers using HTTP to communicate inside the kernel encoding data in JSON and XML and written in Java script... I am almost serious. This garbage triumphally marches across embedded world right now, so no smiley.

Example:
DNS over HTTP. Done because when HTTP is secured using TLS,
it still allows for proxy servers to intercept in an already
sanctioned way.

If the technically minded were to speak against this setup,
then a convincing argument is required.
Specifically, the argument needs to present an alternative
solution to be economically and politically more valuable
than DNS-over-HTTP whilst also preserving the proxies'
capabilities (economically and politically).

In case you have a suggestion in favor of DNSSEC, say,
please disseminate.

There is a tricky bit, though. DNSSEC must look better on
all accounts than buying DNS-over-HTTP appliances.
Given some background noise generated by complaints about
performance, speed might become an influential factor.