Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 3 Sep 2024 08:23:33 +0200
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <vb6a16$38aj5$1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 03 Sep 2024 08:23:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a946dd5e0cae023ba864921a9beb09ea";
	logging-data="3418725"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZoilqavTF2q6gtz/IdYYN4psdF6Vo1wU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:x9+RUR8sX6XLY3TU0QMOcZPdZKI=
Content-Language: en-GB
In-Reply-To: <vb4q5o$12ukk$3@dont-email.me>
Bytes: 5341

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++ ?

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.

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.

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.  Of course, 
"with great power comes great responsibility" - C++ provides many 
exciting ways to write a complete mess :-)


Most of the "Rust vs C++" comparisons I see are complete rubbish in 
regards to C++ - they tend to see it as "C with a couple of OOP bits 
added", and are usually strongly biased towards the Rust fad.  For example :

<https://www.geeksforgeeks.org/rust-vs-c/>

This says Rust is "Multi-paradigm (functional, imperative)" while C++ is 
"Object-oriented".  C++ is as "multi-paradigm" as you can get in a 
programming language - object-oriented /and/ functional /and/ imperative 
/and/ generic /and/ lots of other "paradigms".  And it says C++ has 
"manual memory management", while omitting that it /also/ has extensive 
automatic memory management.


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?".