Re: The Case for Rust (in any system)

On Fri, Sep 13, 2024, 2:14 PM Aryeh Friedman <aryeh.friedman@gmail.com>
wrote:

> On Fri, Sep 13, 2024 at 3:01 PM Paul Floyd <paulf2718@gmail.com> wrote:
> >
> >
> >
> > On 13-09-24 12:24, Aryeh Friedman wrote:
> > > On Fri, Sep 13, 2024 at 7:59 AM Paul Floyd <paulf2718@gmail.com>
> wrote:
> >
> > >
> > > Incorrect a pointer by definition points to a memory region of
> >
> > It's really difficult to follow what you are banging on about. One
> > moment it's allocators and the next it's pointers.
>
> Again wrong all a pointer is at the end of the day is a memory address
> anything to do with that memory access's contents and/or addresses
> near it not what a pointer is.


We would all have an easier time understanding "what you are banging on
about" if you would use correct English grammar. Could you please try to
make an effort?

In other words arr+i == arr[i] iff
> and only iff your type is one processor word big.   In all other cases
> you just have to trust your math is right if your don't it with ptr
> math instead of array notation.   But since neither is bounds checked
> then you are completely free to address stuff beyond your allocation
> unless.   All this adds up to ptr!=arrays but array indexing==ptrs.
> In other words malloc, calloc, etc. make no guerntee that the memory
> is actually reserved for your exclusive use only that it marked that
> way at run time.
>
> >
> > > *UNKNOWN* size and it is only the runtime environment that keeps track
> >
> > I'm well aware of that.
> >
> > > Malloc is not the *ONLY* way to allocate memory at the system level an
> >
> > You could also implement your own custom allocator based on mmap.
>
> There are many other ways that are much cleaner than the above if
> you're dealing with system level stuff...  I am amazed you would point
> to mmap as a solution and recommend kernel Rust use at the same time
>

He didn't recommend that anybody use mmap directly. I think we all know
that only a masochist would use mmap directly for this purpose. A
masochist, or somebody implementing a custom allocator.

because if that is how Rust does it (which I assume it does) then you
> are relying on kernel calls to do that (which might be accessible at
> below the kernel interface).
>
> >
> > > Go read CLRS it is a very clear and obvious algorthm the only thing
> >
> > You mean this bit
> >
> > "10.3 Implementing pointers and objects
> > How do we implement pointers and objects in languages that do not
> > provide them?"
>
> Your being purposely dense here if we are talking about
> growing/shrinking arrays there is an entire section on how  to analyze
> that since it is a classic case of you have on O(1) function [index
> lookup] and the other growing it (O(n)) then how to amortize the big-O
> over time.   How you got I was talking about anything is complete
> beyond me.
>
>
> >
> > What is the point. We are discussing languages (C, C++ and Rust) that DO
> > have them.
> >
> > > you have to be careful of is it is not O(1) so you need to time it
> > > carefully when I do the expanson/contraction instead of just letting
> > > the runtime environment do it for you.    An extreme case of this
> > > going very wrong happened in July 1969 here is the transcript:
> > >
> > > 4 06 42 10 CC
> > > Eagle, Houston. You're GO for landing. Over.
> >
> > Space cadet?
>
> Again you missed the point the point being that a simple memory
> management function that you claim Rust does real well at (async
> behind the scenes array size management) if called at the "right" time
> (like when attempting the final descent to the moon [btw in the
> real-life case the mission was saved by Armstrong taking manually
> control]) it can to catastrophic results such as the very computer you
> need to safely and softly land on the moon becoming non-responsive.
> This is a *COMPLETELY* unacceptable result in any mission-critical (or
> higher application... for example if it happened on one of the remote
> cardiac monitors we use at just the right time we can miss you having
> a heart attack... i.e. for us bugs [of any kind]==dead people).
> --
> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org


I think you are confusing "systems programming" with "real time
programming". I too have programmed real time systems. In my case, for
audio electronics.  Avoiding dynamic memory allocations is indeed important
for real time programming, but Rust is neither uniquely good nor bad at
that. And please understand that there is much more to systems programming
than real time systems.

-Alan