Re: Computer architects leaving Intel...

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.)
And there are some things that Rust simply gets wrong - such as the handling of signed integer overflows.

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

I don't know about reality, but that's what the salesmen say.
In modern C++ it's not hard to write code that doesn't leak and doesn't have out of bounds accesses, but you need to put a bit more effort into coding to track ownership properly, and not everything is as well diagnosed at compile time as it could be.  There has been progress towards the equivalent to the Rust borrow checker for C++, I hear.

  

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?

As an example, in C++, you can make your own types that are, as fast as I can see, much more expressive and flexible than in Rust, while also being safe to use.  This requires object syntax with support for multiple constructors, operator overload, function overloads, public/private separation, and multiple inheritance (at least of methods).

 

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.
 

Multiple inheritance can easily get really messy, especially with polymorphic types where data fields come from different ancestors, and it get even more messy with virtual inheritance.  I don't think that is a good solution in more than a very few niche situations.
But multiple inheritance from bases with no data (just methods, types, static data, constexpr data, etc.) is fine and can be very handy. Non-polymorphic inheritance with data fields is also fine.

  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.

Absolutely.  There's things about newer languages, like Rust, Go, and Swift that I like.  For example, they are designed with concurrency and multi-threading from the start, rather than an add-on.  C++, as we know it today, has grown gradually, and a lot of its complexity is because of features added on rather than having been part of the original design.
But it seems to me that Rust could have taken more from C++ and been a more complete rival.  That is, it could have taken more of what can be done in C++, and found more elegant way to achieve the same effects from the start.

 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.
 

I am in the same boat.  While I like C++ and find it a lot better than C, I'd be quite happy to drop it for Rust or anything else if I found they were better.