[Info-vax] Rust as a HS language, was: Re: Quiet?

[Dan Cross]

In article <624ce3dd$0$694$14726298 at news.sunsite.dk>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 4/5/2022 8:41 PM, Dan Cross wrote:
>> In article <624cd4e1$0$701$14726298 at news.sunsite.dk>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>> Rust checks memory access *unless* in an unsafe block (idea borrowed
>>>from C# language). As a low level language Rust has the need to be able
>>> to do some flexible memory access - I can not imagine it is
>>> possible to write a device driver if only able to access memory
>>> in variables in the program.
>> 
>> It's possible if you are willing to play games with the linker,
>> and very early bootstrap, but it's sufficiently tedious that it
>> is just much easier to transmute an integer to a pointer via
>> unsafe.  Noteably, you really only have to do that once, and you
>> can largely confine _most_ drivers to mostly safe code.
>> 
>> I don't think that Rust's unsafe was inspired by C#, but I
>> confess I haven't asked.
>
>I don't know for sure.
>
>But it seems a bit unlikely that they by coincidence chose
>the exact same construct.
>
>unsafe {
>     ...
>}

Quite possibly.  I put out a question; I'll see if I hear
anything back.  It appears that the `unsafe` keyword in
more or less present form was added in 2011 by Niko.

>>> Rust has a unique approach to memory handling based on
>>> ownership (idea borrowed from modern C++ best practice
>>> not C++ language) that avoids memory leaks without GC - as
>>> a low level language that may be used in real time
>>> context, then the standard solution to avoid memory
>>> leaks in high level languages GC could be problematic.
>> 
>> Yup.  You get something _very_ close to managed memory without
>> the overhead of GC.  Note that sometimes GC can be surprisingly
>> helpful in high-overhead situations (think tight loops where,
>> thanks to GC, you don't have to check ref counts or pointer
>> validity...), but generally you get much of that in Rust without
>> the additional overhead.
>
>Despite what many think then the problem with GC is not
>overhead. Often GC is as efficient or even more efficient
>than manual deallocation.

Eh?  It's commonly accepted that you're going to give up some
percentage of your capacity for GC overhead.  The Go runtime
reserves 25% of CPU time for GC, for instance.

>The problem with GC is the poor real time characteristics.
>It tend to give small pauses at non-deterministic point.

That's the old style GC.  Go's concurrent GC mostly avoids that
unless under severe memory pressure.

	- Dan C.