Re: Computer architects leaving Intel...

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)