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

[chris]

On 04/08/22 13:02, Dan Cross wrote:
> 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.
>

I think it must be the practical engineer in me, where the goal
is to design the most elegant and often least complex solution to a 
given problem It's about efficiency and transparency and also
wary because the early C compilers were often not very good at
all. Still quite wary of anything where the
internal workings are not fully transparent. Modern compilers are
very good in general, but still like to look at the entrails
to see what sort of code is being generated. Trust, but verify
etc.

Maybe rust will be significant, time and the global community
will decide, but there will always be a place for less safe
languages, just as we still need assembler from time to time...

Chris