Re: Computer architects leaving Intel...

On 04/09/2024 09:15, Terje Mathisen wrote:

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.

OK, that's good.  And I presume there is no problem keeping these versions locally in your git (or other source code system), for when the old versions are removed from their internet sources.

 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.

But if you've determined that they do not occur (during debugging), then your code never makes use of the results of an overflow - thus why is it defined behaviour?  It makes no sense.  The only time when you would actually see wrapping in final code is if you hadn't tested it properly, and then you can be pretty confident that the whole thing will end in tears when signs change unexpectedly.  It would be much more sensible to leave signed overflow undefined, and let the compiler optimise on that basis.
I'm all in favour of temporarily having checks for overflow (and other errors) during debugging, but I am sceptical to having distinct debug/release builds.  It encourages people to use debug builds during development, bug hunting and testing, then when all looks good they switch to release build and deploy it.  I prefer a single build, and enable run-time checks on parts of it if and when necessary.

 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.
 

If the compiler can see that code is never run, or that it will have all gone horribly wrong before the code is reached, I am happy to see it removed by the compiler.  (Where possible - and there are unfortunately limits to warning abilities - I like the compiler to tell me about it.) I see no benefit in keeping code in place if it can't be run.
(But I agree that there are pros and cons to many of these things.)