Re: Computer architects leaving Intel...

David Brown wrote:

On 03/09/2024 18:54, Stephen Fuld wrote:

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:

 

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

 I want to know about both :-)
 In my field, small-systems embedded development, C has been dominant for a long time, but C++ use is increasing.  Most of my new stuff in recent times has been C++.  There are some in the field who are trying out Rust, so I need to look into it myself - either because it is a better choice than C++, or because customers might want it.
 

>

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

 Sure.  There are certainly plenty of things that I think are a better idea in a modern programming language and that make it a good step up compared to C.  My key interest is in comparison to C++ - it is a step up in some ways, a step down in others, and a step sideways in many features.  But is it overall up or down, for /my/ uses?
 Examples of things that I think are good in Rust are making variables immutable by default and pattern matching.  Steps down include lack of function overloading and limited object oriented support.
 There are some things that some people really like about Rust, that I am far from convinced about - such as package management.  I could be misunderstanding (since I don't have the experience), but for /my/ work, I am very much against anything that encourages an "always get the latest version" attitude.  Stability is much more important to me.  (I dislike the rate at which Rust changes - every two weeks or so for small things, and every couple of years for breaking changes.)

That's yet another of the things cargo (the rust package manager, as well as lots of other stuff) get right:
Yes, by default you'll pick up the latest of every package/module you "cargo add foo" to your project, but then you can edit the resulting text-format configuration file, and lock down exact versions of some or all of those packages.
This is similar to how we always freeze python packages: Any changes are something we decide to employ.

 And there are some things that Rust simply gets wrong - such as the handling of signed integer overflows.

Maybe?
Rust will _always_ check for such overflow in debug builds, then when you've determined that they don't occur, the release build falls back standard CPU behavior, i.e. wrapping around with no panics.
You can argue both pro and con here, personally I like the Rust setup much more than C(++) which will use code that could do so as an excuse to elide that as well as all surrounding/dependent code.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"