Re: The Case for Rust (in any system)

On Fri, Sep 13, 2024 at 4:54 AM David Chisnall <theraven@freebsd.org> wrote:
>
> On 13 Sep 2024, at 08:59, Joe Schaefer <joesuf4@gmail.com> wrote:
>
>
> That‘s  because you are a dork.
>
>
> In case you were wondering, that was the point when you lost all credibility in this thread.
>
> The point isn’t that calloc calls are faster than vector allocations.   The point is that by changing the way you deal with arrays (as objects that manage their own size, versus managing the sizes using up front preallocations and dealing with their growth yourself), we can exchange function calls for pointer dereferences.
>
>
> And that’s precisely the change you get by calling .reserve with the expected size.  And the speedup tends to be exactly what you claimed you got.

Speaking both as a freelance software engineer who works in
soft-realtime and soft-IoT (the EMR for a medical lab that does remote
cardiac monitoring) and as hopefully a PhD candidate in theoretical CS
(whose research revolves around the minimum number of gates needed for
Turing completeness) I can make few observations here that make clear
that while having good intentions Rust completely misses the mark for
being a true systems programming language:

1. Fixed allocations are *ALWAYS* safer and more predictable then
dynamic ones (dynamic ones are undecidable in there nature and
effects).

2. Combining fixed allocation with dynamic (under the hood and
unrequested) allocation is a very bad idea.

3. It is possible to do all the above safely with arrays and not
pointers IF the arrays are static but not dynamic.

This implies that if and when you grow/shrink the physical array you
need to have really tight control on timing and Rust does not provide
that by putting it all under the hood.


-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org