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: Wed, 4 Sep 2024 12:57:21 +0200
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <vb9eeh$3q993$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> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 12:57:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0366692407b62e2f3ab0bc1ba1697c81";
	logging-data="4007203"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19knkT7x6+X/OSxesgjRxOmx47OhCtM8xU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:/wAUxVoqLlDW2XiW210nQ0BIx18=
Content-Language: en-GB
In-Reply-To: <vb91e7$3o797$1@dont-email.me>
Bytes: 6856

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