[Info-vax] Rust as a HS language, was: Re: Quiet?

[Dan Cross]

In article <t2n8va$1299$1 at gioia.aioe.org>,
chris  <chris-nospam at tridac.net> wrote:
>On 04/07/22 17:27, Dan Cross wrote:
>>> The basic idea of a language as close as possible to the bare
>>> metal, yet with enough capability for serious high level work,
>>> with layered design, is as close to an ideal language as
>>> anyone could wish for. Tricky language indeed ?, rofl...
>>
>> The "C is close to the hardware" thing hasn't been true a long
>> time now.
>>
>> https://queue.acm.org/detail.cfm?id=3212479
>
>Wrong again.

What, precisely, is wrong here?

>Mainly embedded work here and the first thing I
>do with a new architecture and tool set is to examine the assembler
>source to check for efficiency and sensible looking code. Even
>ten years ago, the gcc compiler often produced a single line
>of asm per C statement. That can be optimised by choices such
>as do while / for next style, for example. You can argue against
>that sort of thing, but you need to know your compiler to get the
>best out of it.

"It works with my compiler, so it's correct" used to get you
flamed out of e.g. comp.lang.c.

>That and being completely unambiguous in terms
>of source code and not trying to outsmart the compiler :-)...

It's funny that you are so fixated on compilers, but don't
really focus much on the language.  The language is specified
against an abstract virtual machine that's behavior is
described in the language standard.  What your program does is,
simply, not the same as what your hardware does.

Like you, I often have to read assembly language listings to
make sure I'm getting the output I expect.  But I'm not a
cowboy about it.

	- Dan C.