Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 3 Sep 2024 09:54:11 -0700
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <vb7evj$12ukk$4@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 03 Sep 2024 18:54:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="88e7c0fe572bfdd694f692c23c589b2a";
	logging-data="1145492"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Fn/MGMPg3nO33AmeA46N7nxHzkHYgXiM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Ar0fYI6/2aKQ2xay4F3e6e65l38=
Content-Language: en-US
In-Reply-To: <vb6a16$38aj5$1@dont-email.me>
Bytes: 6793

On 9/2/2024 11:23 PM, David Brown wrote:
> On 02/09/2024 18:46, Stephen Fuld wrote:
>> On 9/2/2024 1:23 AM, Terje Mathisen wrote:
>>> Stephen Fuld wrote:
>>>> On 8/31/2024 2:14 PM, MitchAlsup1 wrote:
>>>>> On Sat, 31 Aug 2024 21:01:54 +0000, Bernd Linsel wrote:
>>>>>> You compare apples and peaches. Technical specifications for your
>>>>>> pressure vessel result from the physical abilities of the chosen
>>>>>> material, by keeping requirements as vessel border width, geometry 
>>>>>> etc.,
>>>>>> while compiler writers are free in their search for optimization 
>>>>>> tricks
>>>>>> that let them shine at SPEC benchmarks.
>>>>>
>>>>> A pressure vessel may actually be able to contain 2× the pressure it
>>>>> will be able to contain 20 after 20 years of service due to stress
>>>>> and strain acting on the base materials.
>>>>>
>>>>> Then there are 3 kinds of metals {grey, white, yellow} with different
>>>>> responses to stress and induced strain. There is no analogy in code--
>>>>> If there were perhaps we would have better code today...
>>>>
>>>> Perhaps an analogy is code written in assembler, versus coed written 
>>>> in C versus code written in something like Ada or Rust.  Backing 
>>>> away now . . . :-)
>>>
>>> IMNSHO, code written in asm is generally more safe than code written 
>>> in C, because the author knows exactly what each line of code is 
>>> going to do.
>>>
>>> The problem is of course that it is harder to get 10x lines of 
>>> correct asm than to get 1x lines of correct C.
>>>
>>> BTW, I am also solidly in the grey hair group here, writing C code 
>>> that is very low-level, using explicit local variables for any loop 
>>> invariant, copying other stuff into temp vars in order to make it 
>>> really obvious that they cannot alias any globals or input/output 
>>> parameters.
>>>
>>> Anyway, that is all mostly moot since I'm using Rust for this kind of 
>>> programming now. :-)
>>
>> Can you talk about the advantages and disadvantages of Rust versus C?
>>
> 
> And also for Rust versus C++ ?

I asked about C versus Rust as Terje explicitly mentioned those two 
languages, but you make a good point in general.



> My impression - based on hearsay for Rust as I have no experience - is 
> that the key point of Rust is memory "safety".  I use scare-quotes here, 
> since it is simply about correct use of dynamic memory and buffers.

I agree that memory safety is the key point, although I gather that it 
has other features that many programmers like.

> 
> It is entirely possible to have correct use of memory in C, but it is 
> also very easy to get it wrong - especially if the developer doesn't use 
> available tools for static and run-time checks.  Modern C++, on the 
> other hand, makes it much easier to get right.  You can cause yourself 
> extra work and risk by using more old-fashioned C++, but following 
> modern design guides using smart pointers and containers, along with 
> easily available tools, and you get a lot of the management of memory 
> handled automatically for very little cost.

Is it fair to say then that Rust makes it harder to get memory 
management "wrong"?




> C++ provides a huge amount more than Rust - when I have looked at Rust, 
> it is (still) too limited for some of what I want to do. 


Can you give a few examples?


> Of course, 
> "with great power comes great responsibility" - C++ provides many 
> exciting ways to write a complete mess :-)

Sure.  I gather that templates are very powerful and potentially very 
useful.  On the other hand, I gather that multiple inheritance is very 
powerful, but difficult to use and potentially very ugly, and has not 
been carried forward in the same way into newer languages.




snip stuff about the inadequacy of existing Rust versus C++ comparisons.


> To my mind, the important question is not "Should we move from C to 
> Rust?", but "Should we move from bad C to C++, Rust, or simply to good C 
> practices?".

I understand.  This brings up an important issue, that of older versus 
newer languages.

A newer language has several advantages.  One is it can take advantage 
of what we have learned about language design and usage since the older 
language was designed. I can't underestimate this enough.  While many 
new language features turn out to be not useful, many are.

Another is that it doesn't have to worry about support for "dusty 
decks", i.e. the existing base which may conform to an older version of 
the language, nor for "dusty brains", that is programmers who learned 
the older (i.e. worse) ways and keep generating new code using those 
ways.  You mention this issue in your comments.

Of course, the counter to that is that new languages have to overcome 
the huge "installed base" advantage of existing languages.

Let me be clear.  I am not a Rust evangelist.  I am just looking for a 
way forward that will help us make programmer easier and not to make 
some of the same mistakes we have made in the past.  Is Rust that?  Some 
people think so.  I just want to understand more.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)