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

[Dan Cross]

In article <t2nk1q$1p31$1 at gioia.aioe.org>,
chris  <chris-nospam at tridac.net> wrote:
>On 04/07/22 19:42, Dan Cross wrote:
>> 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?

I reiterate the question.

>>> 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.
>
>Fixated on compilers ?, looks like projection to me :-).

Well, you've brought up GCC and looking at the listings, but
haven't touched on the standard.  That indicates a tendancy to
look at what a _compiler_ does instead of what the _langauge_
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.
>
>Now you are arm waving and can't resist sly ad hom, suggesting
>you have nothing valid to say and possibly insecure about the
>merits of you favourite solution.

I'll admit that the cowboy quip could be interpreted poorly, so
I apologize for that.  But the rest of your interpretation is
just wrong.  I don't have a "favorite solution"; I keep abreast
of developments and adopt what I perceive to be the most
appropriate solution for a given problem domain at the time when
I need it; this is always a tradeoff, and "most appropriate"
means a combination of technology, maturity, industry knowledge,
etc.

>We are all different. You seem interested in language design,
>whereas a compiler is just a tool in the box and part of a
>much larger system framewwork for me. It either produces the code
>I expect it to, or it fails. If you like rust, go for it, but
>I see no value for the work done here and I don't feel the
>need to knock it, as C has a rich history going back decades
>and is a proven solution for a wide variety of different work...

Where we seem to differ is that I concede that the set of most
appropriate tools changes over time as the industry as a whole
advances, and that tools (such as languages) that allow me to
express programs more safely and provide me with more expressive
power tend to yield better programs than those that do not.

I've given citations to why, e.g., C may be falling from favor,
and why some of the participants in this conversation may be
wrong in their perceptions of that language.  The response has
mostly been assertions without supporting evidence, and
statements implying that safer languages somehow limit the
programmer; usually these are made by people with no or very
limited experience in the languages in question.

	- Dan C.