[TUHS] yet another C discussion (YACD) and: Rust is not C++

[TUHS] yet another C discussion (YACD) and: Rust is not C++

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

I did not want to disrupt the FD 2 discussion, but I could not really let
this comment go unanswered:

"Smells like C++ to me. Rust in essence is a re-implementation of C++ not
C. It tries to pack as much features as it possibly can. "

It's hard for me to see how you can say this if you have done any work in
Rust and C++.

But, short form: Rust is not C++. Full stop.

I did not feel that comment should go unanswered, lest people believe it.

[-- Attachment #2: Type: text/html, Size: 582 bytes --]

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Andy Kosela]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Monday, January 30, 2023, ron minnich <rminnich@gmail.com> wrote:

> I did not want to disrupt the FD 2 discussion, but I could not really let
> this comment go unanswered:
>
> "Smells like C++ to me. Rust in essence is a re-implementation of C++ not
> C. It tries to pack as much features as it possibly can. "
>
> It's hard for me to see how you can say this if you have done any work in
> Rust and C++.
>
> But, short form: Rust is not C++. Full stop.
>
> I did not feel that comment should go unanswered, lest people believe it.
>

Well, I will stand by my opinion, but perhaps you misread what I meant. I
meant that as a whole Rust resembles more C++ than C. Technically it might
lie in between C and C++, but the amount of "features" certainly bring it
closer to C++. While it might be easier to write safer code in Rust than in
C++, I still think that its "weird" syntax and feature bloat make me
dislike it the way I dislike C++.

Just my .02. YMMV.

--Andy

[-- Attachment #2: Type: text/html, Size: 1342 bytes --]

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[segaloco via TUHS]

[-- Attachment #1: Type: text/plain, Size: 3200 bytes --]

My understanding is it might "look and feel" more C++-ish than C, but what it is doing under the hood for memory safety and such results in code much closer in candor to C.

C++ relies on a pretty hefty stack of runtime for things that Rust takes care of much earlier through concepts like ownership. The result is that things like memory safety are handled by the compiler's analysis rather than libraries. Sure you may have more modern-looking OOP constructs, but my understanding is those constructs are closer to syntactic sugar than what most C++ environments do with constructing/destructing, passing pointers, concurrency, etc.

Of course, I'm no expert so I'm just speaking from my own experiences with the two languages, but my understanding is Rust is a C-ish systems language parading around in fancy modern clothes, but it achieves most of its more sophisticated functionality at compile time rather than relying on a bunch of runtime code to keep everything rolling.

I don't think Rust will "replace" C any time soon, just like C hasn't really "replaced" FORTRAN and COBOL in a lot of places, but it will continue to grow as a systems-programming language, especially what with the Linux kernel starting to greenlight Rust components. Regardless, I personally see future value in Rust and so I nabbed the book and am slowly learning it. Hopefully it isn't time wasted and we start seeing more Rust-native interfaces out there. One of the main things holding me back is a lack of native OpenGL interfacing. There are binding layers of course, but that's just another stinky layer of code I don't control doing things I may or may not agree with. As for writing my own bindings, I could do that...or I could just write in C and be done with it :P

Who knows, as time goes on though, Rust may verge more and more into that territory of "best of both worlds" with familiar OOP constructs for modern programmers and​ similar performance to C where it counts. If nothing else, I can credit Rust as the first new language I've actually bought the book for in a long, long time.

- Matt G.
------- Original Message -------
On Monday, January 30th, 2023 at 10:47 AM, Andy Kosela <akosela@andykosela.com> wrote:

> On Monday, January 30, 2023, ron minnich <rminnich@gmail.com> wrote:
>
>> I did not want to disrupt the FD 2 discussion, but I could not really let this comment go unanswered:
>>
>> "Smells like C++ to me. Rust in essence is a re-implementation of C++ not C. It tries to pack as much features as it possibly can. "
>>
>> It's hard for me to see how you can say this if you have done any work in Rust and C++.
>>
>> But, short form: Rust is not C++. Full stop.
>>
>> I did not feel that comment should go unanswered, lest people believe it.
>
> Well, I will stand by my opinion, but perhaps you misread what I meant. I meant that as a whole Rust resembles more C++ than C. Technically it might lie in between C and C++, but the amount of "features" certainly bring it closer to C++. While it might be easier to write safer code in Rust than in C++, I still think that its "weird" syntax and feature bloat make me dislike it the way I dislike C++.
>
> Just my .02. YMMV.
>
> --Andy

[-- Attachment #2: Type: text/html, Size: 4606 bytes --]

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 5270 bytes --]

I don't know how many ways there are to say this, but Rust and C/C++ are
fundamentally different at the lowest level.

If you are just looking at Rust syntax in a superficial way, you might be
excused for thinking it's "C with features / C++ with differences."

But that's not how it is. It's like saying C is "just like assembly"
because labels have a ':' in them; or that Unix is "just like RSX" because
they have vaguely similar commands.

Here's a real question that came up where I work: should the code shown
below be accepted (this is abstracted from a real example that is in use
... everywhere)?
We had one code analyzer that said, emphatically, NO; one person said YES,
another MAYBE. One piece of code, 3 answers :-)

char f() {

  char *y;

  g(&y);

  return *y;

}

A specific question: should y be initialized to NULL?
The case to set y to NULL: otherwise it has an unknown value and it's
unsafe.
The case against setting y to NULL: it is pointless, as it slows the code
down slightly and g is going to change it anyway.
The case maybe: Why do you trust g() to always set it? Why don't you trust
g()? convince me.

You can't write this in Rust with this ambiguity. It won't compile. In
fact, & doesn't mean in Rust what it does in C.

Sorry to be such a pedant, but I was concerned that we not fall into the
"Rust is C++ all over again" trap.

As for replacing C, the velocity of Rust is just astonishing. I think folks
have been waiting for something to replace C for a long time, and Rust,
with all its headaches and issues, is likely to be that thing.

Personally, I still prefer Go, but I can also see which way the wind is
blowing, especially when I see Rust use exploding in firmware and user
mode, and now even in the Linux kernel.

On Mon, Jan 30, 2023 at 11:00 AM segaloco <segaloco@protonmail.com> wrote:

> My understanding is it might "look and feel" more C++-ish than C, but what
> it is doing under the hood for memory safety and such results in code much
> closer in candor to C.
>
> C++ relies on a pretty hefty stack of runtime for things that Rust takes
> care of much earlier through concepts like ownership.  The result is that
> things like memory safety are handled by the compiler's analysis rather
> than libraries.  Sure you may have more modern-looking OOP constructs, but
> my understanding is those constructs are closer to syntactic sugar than
> what most C++ environments do with constructing/destructing, passing
> pointers, concurrency, etc.
>
> Of course, I'm no expert so I'm just speaking from my own experiences with
> the two languages, but my understanding is Rust is a C-ish systems language
> parading around in fancy modern clothes, but it achieves most of its more
> sophisticated functionality at compile time rather than relying on a bunch
> of runtime code to keep everything rolling.
>
> I don't think Rust will "replace" C any time soon, just like C hasn't
> really "replaced" FORTRAN and COBOL in a lot of places, but it will
> continue to grow as a systems-programming language, especially what with
> the Linux kernel starting to greenlight Rust components.  Regardless, I
> personally see future value in Rust and so I nabbed the book and am slowly
> learning it.  Hopefully it isn't time wasted and we start seeing more
> Rust-native interfaces out there.  One of the main things holding me back
> is a lack of native OpenGL interfacing.  There are binding layers of
> course, but that's just another stinky layer of code I don't control doing
> things I may or may not agree with.  As for writing my own bindings, I
> could do that...or I could just write in C and be done with it :P
>
> Who knows, as time goes on though, Rust may verge more and more into that
> territory of "best of both worlds" with familiar OOP constructs for modern
> programmers *and*​ similar performance to C where it counts.  If nothing
> else, I can credit Rust as the first new language I've actually bought the
> book for in a long, long time.
>
> - Matt G.
> ------- Original Message -------
> On Monday, January 30th, 2023 at 10:47 AM, Andy Kosela <
> akosela@andykosela.com> wrote:
>
>
> On Monday, January 30, 2023, ron minnich <rminnich@gmail.com> wrote:
>
>> I did not want to disrupt the FD 2 discussion, but I could not really let
>> this comment go unanswered:
>>
>> "Smells like C++ to me. Rust in essence is a re-implementation of C++ not
>> C. It tries to pack as much features as it possibly can. "
>>
>> It's hard for me to see how you can say this if you have done any work in
>> Rust and C++.
>>
>> But, short form: Rust is not C++. Full stop.
>>
>> I did not feel that comment should go unanswered, lest people believe it.
>>
>
> Well, I will stand by my opinion, but perhaps you misread what I meant. I
> meant that as a whole Rust resembles more C++ than C. Technically it might
> lie in between C and C++, but the amount of "features" certainly bring it
> closer to C++. While it might be easier to write safer code in Rust than in
> C++, I still think that its "weird" syntax and feature bloat make me
> dislike it the way I dislike C++.
>
> Just my .02. YMMV.
>
> --Andy
>
>
>

[-- Attachment #2: Type: text/html, Size: 8377 bytes --]

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Stuff Received]

On 2023-01-30 14:35, ron minnich wrote (in part):
> As for replacing C, the velocity of Rust is just astonishing. I think 
> folks have been waiting for something to replace C for a long time, and 
> Rust, with all its headaches and issues, is likely to be that thing.

Of possible interest: 
https://devclass.com/2023/01/23/rust-has-no-formal-specification-and-it-is-time-that-was-fixed-says-team-which-longs-for-formalized-type-system/

N.

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Alejandro Colomar]

Hello Ron,

On 1/30/23 20:35, ron minnich wrote:
> I don't know how many ways there are to say this, but Rust and C/C++ are 
> fundamentally different at the lowest level.
> 
> If you are just looking at Rust syntax in a superficial way, you might be 
> excused for thinking it's "C with features / C++ with differences."
> 
> But that's not how it is. It's like saying C is "just like assembly" because 
> labels have a ':' in them; or that Unix is "just like RSX" because they have 
> vaguely similar commands.
> 
> Here's a real question that came up where I work: should the code shown below be 
> accepted (this is abstracted from a real example that is in use ... everywhere)?
> We had one code analyzer that said, emphatically, NO; one person said YES, 
> another MAYBE. One piece of code, 3 answers :-)
> 
> char f() {
> 
> char *y;
> 
> g(&y);
> 
> return *y;
> 
> }
> 
> 
> A specific question: should y be initialized to NULL?

No.  At least not if you don't want to use the value NULL in your program. 
Using NULL as something to avoid Undefined Behavior is wrong, and it will 
contribute to hide programmer errors.

These days, compilers and static analyzers are smart enough to detect 
uninitialized variables, even across Translation Units, and throw an error, 
letting the programmer fix such bugs, when they occur.

The practice of initializing always to NULL and 0 provides no value, and 
silences all of those warnings, thus creating silent bugs, that will bite some 
cold winter night.

I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't 
initialize variables and especially pointers (well, you need to enable the 
warning that does that, but it can warn).  That warning is there due to some 
coding style or certifications that require it.  I recommend disabling those 
bogus warnings, and forgetting about the bogus coding style or certification 
that requires you to write bogus code.

> The case to set y to NULL: otherwise it has an unknown value and it's unsafe.

Is an undefined value less safe than an unexpected one?  I don't think so.  At 
least compilers can detect the former, but not the latter.

> The case against setting y to NULL: it is pointless, as it slows the code down 
> slightly and g is going to change it anyway.

Performance is a very minor thing.  But it's a nice side-effect that doing the 
right thing has performance advantages.  Readability is a good reason (and in 
fact, the compiler suffers that readability too, which is the cause of the 
silencing of the wanted warnings.

> The case maybe: Why do you trust g() to always set it? Why don't you trust g()? 
> convince me.

Well, it depends on the contract of g().  If the contract is that it may not 
initialize the variable, then sure, initialize it yourself, or even better, 
check for g()'s errors, and react when it fails and doesn't initialize it.

If the contract is that it should always initialize it, then trust it blindly. 
The compiler will tell you when it doesn't happen (that is, when g() has a bug).

> 
> You can't write this in Rust with this ambiguity. It won't compile. In fact, & 
> doesn't mean in Rust what it does in C.

I don't know Rust.  Does it force NULL initialization?  If so, I guess it's a 
bad design choice.  Unless Rust is so different that it can detect such 
programmer errors even having defined default initialization, but I can't 
imagine how that is.

> 
> Sorry to be such a pedant, but I was concerned that we not fall into the "Rust 
> is C++ all over again" trap.
> 
> As for replacing C, the velocity of Rust is just astonishing. I think folks have 
> been waiting for something to replace C for a long time, and Rust, with all its 
> headaches and issues, is likely to be that thing.

Modern C is receiving a lot of improvements from C++ and other languages.  It's 
getting really good in fixing the small issues it had in the past (and GNU C 
provides even more good things).  GNU C2x is quite safe and readable, compared 
to say ISO C99 versions.

I don't think C will ever be replaced.  And I hope it doesn't.

Possibly, something like with Plan9 and Unix/Linux will happen.  The good things 
from other languages will come back in one form or another to C.  The 
not-so-good ones will be discarded.

> 
> Personally, I still prefer Go, but I can also see which way the wind is blowing, 
> especially when I see Rust use exploding in firmware and user mode, and now even 
> in the Linux kernel.

Cheers,

Alex

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Dan Cross]

On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
> Hello Ron,
>
> On 1/30/23 20:35, ron minnich wrote:
> > I don't know how many ways there are to say this, but Rust and C/C++ are
> > fundamentally different at the lowest level.
> >
> > If you are just looking at Rust syntax in a superficial way, you might be
> > excused for thinking it's "C with features / C++ with differences."
> >
> > But that's not how it is. It's like saying C is "just like assembly" because
> > labels have a ':' in them; or that Unix is "just like RSX" because they have
> > vaguely similar commands.
> >
> > Here's a real question that came up where I work: should the code shown below be
> > accepted (this is abstracted from a real example that is in use ... everywhere)?
> > We had one code analyzer that said, emphatically, NO; one person said YES,
> > another MAYBE. One piece of code, 3 answers :-)
> >
> > char f() {
> >     char *y;
> >     g(&y);
> >     return *y;
> > }
> >
> >
> > A specific question: should y be initialized to NULL?
>
> No.  At least not if you don't want to use the value NULL in your program.
> Using NULL as something to avoid Undefined Behavior is wrong, and it will
> contribute to hide programmer errors.

Sorry, I think this misses the point: how do you meaningfully tell
that `g` did something to `y` so that it's safe to indirect in the
`return`?

On the other hand, one could write,

char f() {
    char *y = NULL;
    g(&y);
    if (y == NULL)
        panic("g failed");
    return *y;
}

C, of course, can't tell in the original. And while you can now tell
that `g` did _something_ to `y`, you still really don't know that `y`
points to something valid.

> These days, compilers and static analyzers are smart enough to detect
> uninitialized variables, even across Translation Units, and throw an error,
> letting the programmer fix such bugs, when they occur.

In many cases, yes, but not in all. That would be equivalent to
solving the halting problem.

> The practice of initializing always to NULL and 0 provides no value, and
> silences all of those warnings, thus creating silent bugs, that will bite some
> cold winter night.
>
> I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
> initialize variables and especially pointers (well, you need to enable the
> warning that does that, but it can warn).  That warning is there due to some
> coding style or certifications that require it.  I recommend disabling those
> bogus warnings, and forgetting about the bogus coding style or certification
> that requires you to write bogus code.

Oh my.

> > The case to set y to NULL: otherwise it has an unknown value and it's unsafe.
>
> Is an undefined value less safe than an unexpected one?  I don't think so.  At
> least compilers can detect the former, but not the latter.
>
> > The case against setting y to NULL: it is pointless, as it slows the code down
> > slightly and g is going to change it anyway.
>
> Performance is a very minor thing.  But it's a nice side-effect that doing the
> right thing has performance advantages.  Readability is a good reason (and in
> fact, the compiler suffers that readability too, which is the cause of the
> silencing of the wanted warnings.
>
> > The case maybe: Why do you trust g() to always set it? Why don't you trust g()?
> > convince me.
>
> Well, it depends on the contract of g().  If the contract is that it may not
> initialize the variable, then sure, initialize it yourself, or even better,
> check for g()'s errors, and react when it fails and doesn't initialize it.
>
> If the contract is that it should always initialize it, then trust it blindly.
> The compiler will tell you when it doesn't happen (that is, when g() has a bug).

The number of situations where the compiler can't tell whether `g` has
a bug is unbounded.

> > You can't write this in Rust with this ambiguity. It won't compile. In fact, &
> > doesn't mean in Rust what it does in C.
>
> I don't know Rust.  Does it force NULL initialization?  If so, I guess it's a
> bad design choice.  Unless Rust is so different that it can detect such
> programmer errors even having defined default initialization, but I can't
> imagine how that is.

Rust enforces that all variables must be initialized prior to use.
Whether they're initialized with a zero value or something else is up
to the programmer; but not initializing is a compile-time error.

For example:

| fn main() {
|     let x;
|     if thing_is_true() {
|         x = 5;
|     } else {
|         x = 3;
|     }
|     println!("x={x}");
| }

In fact, this is good; this allows us to employ a technique called,
"Type-Driven Development", whereby we can create some type that
encodes an invariant about the object. An object of that type is
written in such a way that once it has been initialized, the mere
existence of the object is sufficient to prove that the invariant
holds, and need not be retested whenever the object is used. For
example:

| #[repr(transparent)]
| struct PageFrameAddr(u64);
| impl PageFrameAddr {
|     fn new_round_down(addr: u64) -> PageFrameAddr {
|         PageFrameAddr(addr & !0xFFF)
|     }
| }

Here, "PageFrameAddr" contains a 4KiB-aligned page address.  Since the
only way to create one of these is by the, `new_round_down` associated
method that masks off the low bits, we can be sure that if we get one
of these, the contained address is properly aligned.  In C, we'd
pretty much have to test at the site of use.

This is an extremely powerful technique; cf Alexis King's blog post,
"Parse Don't Validate"
(https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
and Cliff Biffle's talk on the Hubris embedded RTOS
(https://talks.osfc.io/osfc2021/talk/JTWYEH/).

> > Sorry to be such a pedant, but I was concerned that we not fall into the "Rust
> > is C++ all over again" trap.
> >
> > As for replacing C, the velocity of Rust is just astonishing. I think folks have
> > been waiting for something to replace C for a long time, and Rust, with all its
> > headaches and issues, is likely to be that thing.
>
> Modern C is receiving a lot of improvements from C++ and other languages.  It's
> getting really good in fixing the small issues it had in the past (and GNU C
> provides even more good things).  GNU C2x is quite safe and readable, compared
> to say ISO C99 versions.

C23 looks like it will be a better language that C11, but I don't know
that even JeanHeyd would suggest it's "quite safe". :-/

        - Dan C.


> I don't think C will ever be replaced.  And I hope it doesn't.
>
> Possibly, something like with Plan9 and Unix/Linux will happen.  The good things
> from other languages will come back in one form or another to C.  The
> not-so-good ones will be discarded.
>
> >
> > Personally, I still prefer Go, but I can also see which way the wind is blowing,
> > especially when I see Rust use exploding in firmware and user mode, and now even
> > in the Linux kernel.
>
> Cheers,
>
> Alex

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 7922 bytes --]

That example was a simplified bit of code from a widely used code base. All
I need to do is change the function g go a pointer to function, or have it
be provided by a .so, and all bets are off.

In any event, the important thing here is not that y should be initialized,
or should not; it's that it is not possible to get a consistent answer on
the question, from people who have been writing in C for decades.

ron

On Mon, Jan 30, 2023 at 6:56 PM Dan Cross <crossd@gmail.com> wrote:

> On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
> > Hello Ron,
> >
> > On 1/30/23 20:35, ron minnich wrote:
> > > I don't know how many ways there are to say this, but Rust and C/C++
> are
> > > fundamentally different at the lowest level.
> > >
> > > If you are just looking at Rust syntax in a superficial way, you might
> be
> > > excused for thinking it's "C with features / C++ with differences."
> > >
> > > But that's not how it is. It's like saying C is "just like assembly"
> because
> > > labels have a ':' in them; or that Unix is "just like RSX" because
> they have
> > > vaguely similar commands.
> > >
> > > Here's a real question that came up where I work: should the code
> shown below be
> > > accepted (this is abstracted from a real example that is in use ...
> everywhere)?
> > > We had one code analyzer that said, emphatically, NO; one person said
> YES,
> > > another MAYBE. One piece of code, 3 answers :-)
> > >
> > > char f() {
> > >     char *y;
> > >     g(&y);
> > >     return *y;
> > > }
> > >
> > >
> > > A specific question: should y be initialized to NULL?
> >
> > No.  At least not if you don't want to use the value NULL in your
> program.
> > Using NULL as something to avoid Undefined Behavior is wrong, and it will
> > contribute to hide programmer errors.
>
> Sorry, I think this misses the point: how do you meaningfully tell
> that `g` did something to `y` so that it's safe to indirect in the
> `return`?
>
> On the other hand, one could write,
>
> char f() {
>     char *y = NULL;
>     g(&y);
>     if (y == NULL)
>         panic("g failed");
>     return *y;
> }
>
> C, of course, can't tell in the original. And while you can now tell
> that `g` did _something_ to `y`, you still really don't know that `y`
> points to something valid.
>
> > These days, compilers and static analyzers are smart enough to detect
> > uninitialized variables, even across Translation Units, and throw an
> error,
> > letting the programmer fix such bugs, when they occur.
>
> In many cases, yes, but not in all. That would be equivalent to
> solving the halting problem.
>
> > The practice of initializing always to NULL and 0 provides no value, and
> > silences all of those warnings, thus creating silent bugs, that will
> bite some
> > cold winter night.
> >
> > I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
> > initialize variables and especially pointers (well, you need to enable
> the
> > warning that does that, but it can warn).  That warning is there due to
> some
> > coding style or certifications that require it.  I recommend disabling
> those
> > bogus warnings, and forgetting about the bogus coding style or
> certification
> > that requires you to write bogus code.
>
> Oh my.
>
> > > The case to set y to NULL: otherwise it has an unknown value and it's
> unsafe.
> >
> > Is an undefined value less safe than an unexpected one?  I don't think
> so.  At
> > least compilers can detect the former, but not the latter.
> >
> > > The case against setting y to NULL: it is pointless, as it slows the
> code down
> > > slightly and g is going to change it anyway.
> >
> > Performance is a very minor thing.  But it's a nice side-effect that
> doing the
> > right thing has performance advantages.  Readability is a good reason
> (and in
> > fact, the compiler suffers that readability too, which is the cause of
> the
> > silencing of the wanted warnings.
> >
> > > The case maybe: Why do you trust g() to always set it? Why don't you
> trust g()?
> > > convince me.
> >
> > Well, it depends on the contract of g().  If the contract is that it may
> not
> > initialize the variable, then sure, initialize it yourself, or even
> better,
> > check for g()'s errors, and react when it fails and doesn't initialize
> it.
> >
> > If the contract is that it should always initialize it, then trust it
> blindly.
> > The compiler will tell you when it doesn't happen (that is, when g() has
> a bug).
>
> The number of situations where the compiler can't tell whether `g` has
> a bug is unbounded.
>
> > > You can't write this in Rust with this ambiguity. It won't compile. In
> fact, &
> > > doesn't mean in Rust what it does in C.
> >
> > I don't know Rust.  Does it force NULL initialization?  If so, I guess
> it's a
> > bad design choice.  Unless Rust is so different that it can detect such
> > programmer errors even having defined default initialization, but I can't
> > imagine how that is.
>
> Rust enforces that all variables must be initialized prior to use.
> Whether they're initialized with a zero value or something else is up
> to the programmer; but not initializing is a compile-time error.
>
> For example:
>
> | fn main() {
> |     let x;
> |     if thing_is_true() {
> |         x = 5;
> |     } else {
> |         x = 3;
> |     }
> |     println!("x={x}");
> | }
>
> In fact, this is good; this allows us to employ a technique called,
> "Type-Driven Development", whereby we can create some type that
> encodes an invariant about the object. An object of that type is
> written in such a way that once it has been initialized, the mere
> existence of the object is sufficient to prove that the invariant
> holds, and need not be retested whenever the object is used. For
> example:
>
> | #[repr(transparent)]
> | struct PageFrameAddr(u64);
> | impl PageFrameAddr {
> |     fn new_round_down(addr: u64) -> PageFrameAddr {
> |         PageFrameAddr(addr & !0xFFF)
> |     }
> | }
>
> Here, "PageFrameAddr" contains a 4KiB-aligned page address.  Since the
> only way to create one of these is by the, `new_round_down` associated
> method that masks off the low bits, we can be sure that if we get one
> of these, the contained address is properly aligned.  In C, we'd
> pretty much have to test at the site of use.
>
> This is an extremely powerful technique; cf Alexis King's blog post,
> "Parse Don't Validate"
> (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
> and Cliff Biffle's talk on the Hubris embedded RTOS
> (https://talks.osfc.io/osfc2021/talk/JTWYEH/).
>
> > > Sorry to be such a pedant, but I was concerned that we not fall into
> the "Rust
> > > is C++ all over again" trap.
> > >
> > > As for replacing C, the velocity of Rust is just astonishing. I think
> folks have
> > > been waiting for something to replace C for a long time, and Rust,
> with all its
> > > headaches and issues, is likely to be that thing.
> >
> > Modern C is receiving a lot of improvements from C++ and other
> languages.  It's
> > getting really good in fixing the small issues it had in the past (and
> GNU C
> > provides even more good things).  GNU C2x is quite safe and readable,
> compared
> > to say ISO C99 versions.
>
> C23 looks like it will be a better language that C11, but I don't know
> that even JeanHeyd would suggest it's "quite safe". :-/
>
>         - Dan C.
>
>
> > I don't think C will ever be replaced.  And I hope it doesn't.
> >
> > Possibly, something like with Plan9 and Unix/Linux will happen.  The
> good things
> > from other languages will come back in one form or another to C.  The
> > not-so-good ones will be discarded.
> >
> > >
> > > Personally, I still prefer Go, but I can also see which way the wind
> is blowing,
> > > especially when I see Rust use exploding in firmware and user mode,
> and now even
> > > in the Linux kernel.
> >
> > Cheers,
> >
> > Alex
>

[-- Attachment #2: Type: text/html, Size: 9768 bytes --]

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Dan Cross]

On Mon, Jan 30, 2023 at 10:59 PM ron minnich <rminnich@gmail.com> wrote:
> That example was a simplified bit of code from a widely used code base. All I need to do is change the function g go a pointer to function, or have it be provided by a .so, and all bets are off.
>
> In any event, the important thing here is not that y should be initialized, or should not; it's that it is not possible to get a consistent answer on the question, from people who have been writing in C for decades.

Indeed, I was agreeing with you, Ron. :-)

        - Dan C.

> On Mon, Jan 30, 2023 at 6:56 PM Dan Cross <crossd@gmail.com> wrote:
>>
>> On Mon, Jan 30, 2023 at 8:49 PM Alejandro Colomar
>> <alx.manpages@gmail.com> wrote:
>> > Hello Ron,
>> >
>> > On 1/30/23 20:35, ron minnich wrote:
>> > > I don't know how many ways there are to say this, but Rust and C/C++ are
>> > > fundamentally different at the lowest level.
>> > >
>> > > If you are just looking at Rust syntax in a superficial way, you might be
>> > > excused for thinking it's "C with features / C++ with differences."
>> > >
>> > > But that's not how it is. It's like saying C is "just like assembly" because
>> > > labels have a ':' in them; or that Unix is "just like RSX" because they have
>> > > vaguely similar commands.
>> > >
>> > > Here's a real question that came up where I work: should the code shown below be
>> > > accepted (this is abstracted from a real example that is in use ... everywhere)?
>> > > We had one code analyzer that said, emphatically, NO; one person said YES,
>> > > another MAYBE. One piece of code, 3 answers :-)
>> > >
>> > > char f() {
>> > >     char *y;
>> > >     g(&y);
>> > >     return *y;
>> > > }
>> > >
>> > >
>> > > A specific question: should y be initialized to NULL?
>> >
>> > No.  At least not if you don't want to use the value NULL in your program.
>> > Using NULL as something to avoid Undefined Behavior is wrong, and it will
>> > contribute to hide programmer errors.
>>
>> Sorry, I think this misses the point: how do you meaningfully tell
>> that `g` did something to `y` so that it's safe to indirect in the
>> `return`?
>>
>> On the other hand, one could write,
>>
>> char f() {
>>     char *y = NULL;
>>     g(&y);
>>     if (y == NULL)
>>         panic("g failed");
>>     return *y;
>> }
>>
>> C, of course, can't tell in the original. And while you can now tell
>> that `g` did _something_ to `y`, you still really don't know that `y`
>> points to something valid.
>>
>> > These days, compilers and static analyzers are smart enough to detect
>> > uninitialized variables, even across Translation Units, and throw an error,
>> > letting the programmer fix such bugs, when they occur.
>>
>> In many cases, yes, but not in all. That would be equivalent to
>> solving the halting problem.
>>
>> > The practice of initializing always to NULL and 0 provides no value, and
>> > silences all of those warnings, thus creating silent bugs, that will bite some
>> > cold winter night.
>> >
>> > I know some static analyzers (e.g., clang-tidy(1)) do warn when you don't
>> > initialize variables and especially pointers (well, you need to enable the
>> > warning that does that, but it can warn).  That warning is there due to some
>> > coding style or certifications that require it.  I recommend disabling those
>> > bogus warnings, and forgetting about the bogus coding style or certification
>> > that requires you to write bogus code.
>>
>> Oh my.
>>
>> > > The case to set y to NULL: otherwise it has an unknown value and it's unsafe.
>> >
>> > Is an undefined value less safe than an unexpected one?  I don't think so.  At
>> > least compilers can detect the former, but not the latter.
>> >
>> > > The case against setting y to NULL: it is pointless, as it slows the code down
>> > > slightly and g is going to change it anyway.
>> >
>> > Performance is a very minor thing.  But it's a nice side-effect that doing the
>> > right thing has performance advantages.  Readability is a good reason (and in
>> > fact, the compiler suffers that readability too, which is the cause of the
>> > silencing of the wanted warnings.
>> >
>> > > The case maybe: Why do you trust g() to always set it? Why don't you trust g()?
>> > > convince me.
>> >
>> > Well, it depends on the contract of g().  If the contract is that it may not
>> > initialize the variable, then sure, initialize it yourself, or even better,
>> > check for g()'s errors, and react when it fails and doesn't initialize it.
>> >
>> > If the contract is that it should always initialize it, then trust it blindly.
>> > The compiler will tell you when it doesn't happen (that is, when g() has a bug).
>>
>> The number of situations where the compiler can't tell whether `g` has
>> a bug is unbounded.
>>
>> > > You can't write this in Rust with this ambiguity. It won't compile. In fact, &
>> > > doesn't mean in Rust what it does in C.
>> >
>> > I don't know Rust.  Does it force NULL initialization?  If so, I guess it's a
>> > bad design choice.  Unless Rust is so different that it can detect such
>> > programmer errors even having defined default initialization, but I can't
>> > imagine how that is.
>>
>> Rust enforces that all variables must be initialized prior to use.
>> Whether they're initialized with a zero value or something else is up
>> to the programmer; but not initializing is a compile-time error.
>>
>> For example:
>>
>> | fn main() {
>> |     let x;
>> |     if thing_is_true() {
>> |         x = 5;
>> |     } else {
>> |         x = 3;
>> |     }
>> |     println!("x={x}");
>> | }
>>
>> In fact, this is good; this allows us to employ a technique called,
>> "Type-Driven Development", whereby we can create some type that
>> encodes an invariant about the object. An object of that type is
>> written in such a way that once it has been initialized, the mere
>> existence of the object is sufficient to prove that the invariant
>> holds, and need not be retested whenever the object is used. For
>> example:
>>
>> | #[repr(transparent)]
>> | struct PageFrameAddr(u64);
>> | impl PageFrameAddr {
>> |     fn new_round_down(addr: u64) -> PageFrameAddr {
>> |         PageFrameAddr(addr & !0xFFF)
>> |     }
>> | }
>>
>> Here, "PageFrameAddr" contains a 4KiB-aligned page address.  Since the
>> only way to create one of these is by the, `new_round_down` associated
>> method that masks off the low bits, we can be sure that if we get one
>> of these, the contained address is properly aligned.  In C, we'd
>> pretty much have to test at the site of use.
>>
>> This is an extremely powerful technique; cf Alexis King's blog post,
>> "Parse Don't Validate"
>> (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/)
>> and Cliff Biffle's talk on the Hubris embedded RTOS
>> (https://talks.osfc.io/osfc2021/talk/JTWYEH/).
>>
>> > > Sorry to be such a pedant, but I was concerned that we not fall into the "Rust
>> > > is C++ all over again" trap.
>> > >
>> > > As for replacing C, the velocity of Rust is just astonishing. I think folks have
>> > > been waiting for something to replace C for a long time, and Rust, with all its
>> > > headaches and issues, is likely to be that thing.
>> >
>> > Modern C is receiving a lot of improvements from C++ and other languages.  It's
>> > getting really good in fixing the small issues it had in the past (and GNU C
>> > provides even more good things).  GNU C2x is quite safe and readable, compared
>> > to say ISO C99 versions.
>>
>> C23 looks like it will be a better language that C11, but I don't know
>> that even JeanHeyd would suggest it's "quite safe". :-/
>>
>>         - Dan C.
>>
>>
>> > I don't think C will ever be replaced.  And I hope it doesn't.
>> >
>> > Possibly, something like with Plan9 and Unix/Linux will happen.  The good things
>> > from other languages will come back in one form or another to C.  The
>> > not-so-good ones will be discarded.
>> >
>> > >
>> > > Personally, I still prefer Go, but I can also see which way the wind is blowing,
>> > > especially when I see Rust use exploding in firmware and user mode, and now even
>> > > in the Linux kernel.
>> >
>> > Cheers,
>> >
>> > Alex

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Steffen Nurpmeso]

ron minnich wrote in
 <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>:
 |That example was a simplified bit of code from a widely used code base. All
 |I need to do is change the function g go a pointer to function, or have it
 |be provided by a .so, and all bets are off.
 |
 |In any event, the important thing here is not that y should be initialized,
 |or should not; it's that it is not possible to get a consistent answer on
 |the question, from people who have been writing in C for decades.

I find the syntax just terrible.  (I have not programmed with it.)
I mean annotations are for the better, ok, (but i luckily get away
with only "const" and "volatile" (and "mutable"), and leave things
like "restrict" be a good man).  Johannes Lundberg i think it was
who then left FreeBSD (?) but pointing to a Rust program
he had written (i cannot find the reference), that was a few years
ago (i looked once i composed this message first, it might even
had been as early as 2017!), and i was lucky i do not have to deal
with it.

Even nim-lang.org that at least converted its code to plain C back
in the day when it was still called Nimrod is too heavy for me now,
but claims to be hard realtime aware etc.  It at least tries to
give programmers some syntactic sugar that makes people happy when
they look at the screen for 7 hours (underpaid) or 16 hours
(over-ambitioned).  Like the only python thing i like, the
syntax sugar.  But as languages grow they get more and more
"refined", and now i read things like

  type
    BinaryTree*[T] = ref object # BinaryTree is a generic type with
                                # generic param `T`
      le, ri: BinaryTree[T]     # left and right subtrees; may be nil
      data: T                   # the data stored in a node

  proc newNode*[T](data: T): BinaryTree[T] =
    # constructor for a node
    new(result)
    result.data = data

which gets me off a bit and makes me think that "hey, maybe
Objective-C is not really the worst thing" (despite the syntax).

I do not know.  Everything beyond a small monolithic
self-contained thing is a problem per se.  You can then unit test
atomically, and if thousands of modules do that, you plug them to
a better whole.  But that also not a good answer, all those flakes
that live their own life, many maybe even in remote locations out
of any control.

You could have a language which hard fixates all the call chain,
or you could have tools which bring this to a small and simple
language which does not offer it.  A compiler can figure out which
variables are assigned etc and could create in-object-file
annotations which the linker automatically verifies.
Of course there are many code paths through functions.

Back in 2009 when i bought the one Apple i wanted to have i tried
out their Development software, which i think required internet
access.  All the pop-ups and titles, i think it (later?) could
compile on-the-fly and inject the new object in the running tested
application, etc.

And then there are semantic description languages like interface
builders, where robots create the actual code.  So then you could
have Corba interface descriptions / DBUS and plug it all via it.

Then Rob Pike says "make it a string" (more or less), and luckily
i do not have dyslexia.

Maybe Qt has a good answer by not only not banishing the
C preprocessor, but introducing another one on top.
So then the compiler can analyze the code and generate a correct
variable-state-at-function-call-time state that a dynamic linker
could then verify against the consumer or producer (whatever is
needed) of linked modules, that link modules, that link modules,
all of which are subject to replacements due to development
iterations, bug patches etc, ie, new releases.

As in, the library versioning that is used for ELF object files,
today often even linker scripts which furtherly diversify this,
offer are not enough, they do not do this.  They only bundle
a name to a library version, or multiple (as in

   1966 FUNC    GLOBAL DEFAULT   13 realpath@@GLIBC_2.3
     33 FUNC    GLOBAL DEFAULT   13 realpath@GLIBC_2.2.5)

I do not know how Rust deals with this.  Is it at all possible to
fixate all the call chain over all possibly involved dynamics?
What do i gain from initializing an object with a default value if
that default value is not not not not one of the values that
i expect after some external function is called?

Sure i not rarely see patches fly by where one more memset(,0,) is
used to fully initialize a struct / prevent memory address
disclosures (i only track BSDs).
And there are still patches that fix bugs on old code that
sometimes is twenty years or more, say zlib or tzcode.
And then there are compiler bugs that bring in bugs -- that is not
avoidable, even if the documentation is clear and obvious like

/* The application can compare zlibVersion and ZLIB_VERSION for consistency.
   If the first character differs, the library code actually used is not
   compatible with the zlib.h header file used by the application.  This check
   is automatically made by deflateInit and inflateInit.
 */

That is only graspable by a human programmer that reads it.  Rapid
application development that surely is not.
(And actually i am not sure this is really true.  But i personally
would hope for it.  It is more earthy, and has more blood, sweat
and tears.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Larry McVoy]

Even though I participated in this thread, so I too have sinned, this 
definitely wants to be discussed elsewhere.  comp.lang.c maybe?

This discussion reminds a lot of what my career has been like.  Over and
over again, I got told "that won't work".  I wasn't very interested in
those people, if they stayed out of my way.  I was way more interested
in the people who said "hmm, maybe if you did it this way".

I've written a ton of working C code.  I've managed and guided others
to do the same.  I'm positive that I've written way more commercially
supported C code than was present in v6/v7 kernels.  Not sure about
userspace, I think Unix has me beat there.

The point?  It's very possible to write working C code.  You need good
programmers and those seem to be going out of style so people are turning
to Rust because it doesn't compile crappy code.

I'm just happy to be retired, C worked for me for 40+ years, I feel
like I dodged a learning curve bullet by getting out before I had to
switch to Rust (or whatever).

On Wed, Feb 01, 2023 at 01:40:23AM +0100, Steffen Nurpmeso wrote:
> ron minnich wrote in
>  <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>:
>  |That example was a simplified bit of code from a widely used code base. All
>  |I need to do is change the function g go a pointer to function, or have it
>  |be provided by a .so, and all bets are off.
>  |
>  |In any event, the important thing here is not that y should be initialized,
>  |or should not; it's that it is not possible to get a consistent answer on
>  |the question, from people who have been writing in C for decades.
> 
> I find the syntax just terrible.  (I have not programmed with it.)
> I mean annotations are for the better, ok, (but i luckily get away
> with only "const" and "volatile" (and "mutable"), and leave things
> like "restrict" be a good man).  Johannes Lundberg i think it was
> who then left FreeBSD (?) but pointing to a Rust program
> he had written (i cannot find the reference), that was a few years
> ago (i looked once i composed this message first, it might even
> had been as early as 2017!), and i was lucky i do not have to deal
> with it.
> 
> Even nim-lang.org that at least converted its code to plain C back
> in the day when it was still called Nimrod is too heavy for me now,
> but claims to be hard realtime aware etc.  It at least tries to
> give programmers some syntactic sugar that makes people happy when
> they look at the screen for 7 hours (underpaid) or 16 hours
> (over-ambitioned).  Like the only python thing i like, the
> syntax sugar.  But as languages grow they get more and more
> "refined", and now i read things like
> 
>   type
>     BinaryTree*[T] = ref object # BinaryTree is a generic type with
>                                 # generic param `T`
>       le, ri: BinaryTree[T]     # left and right subtrees; may be nil
>       data: T                   # the data stored in a node
> 
>   proc newNode*[T](data: T): BinaryTree[T] =
>     # constructor for a node
>     new(result)
>     result.data = data
> 
> which gets me off a bit and makes me think that "hey, maybe
> Objective-C is not really the worst thing" (despite the syntax).
> 
> I do not know.  Everything beyond a small monolithic
> self-contained thing is a problem per se.  You can then unit test
> atomically, and if thousands of modules do that, you plug them to
> a better whole.  But that also not a good answer, all those flakes
> that live their own life, many maybe even in remote locations out
> of any control.
> 
> You could have a language which hard fixates all the call chain,
> or you could have tools which bring this to a small and simple
> language which does not offer it.  A compiler can figure out which
> variables are assigned etc and could create in-object-file
> annotations which the linker automatically verifies.
> Of course there are many code paths through functions.
> 
> Back in 2009 when i bought the one Apple i wanted to have i tried
> out their Development software, which i think required internet
> access.  All the pop-ups and titles, i think it (later?) could
> compile on-the-fly and inject the new object in the running tested
> application, etc.
> 
> And then there are semantic description languages like interface
> builders, where robots create the actual code.  So then you could
> have Corba interface descriptions / DBUS and plug it all via it.
> 
> Then Rob Pike says "make it a string" (more or less), and luckily
> i do not have dyslexia.
> 
> Maybe Qt has a good answer by not only not banishing the
> C preprocessor, but introducing another one on top.
> So then the compiler can analyze the code and generate a correct
> variable-state-at-function-call-time state that a dynamic linker
> could then verify against the consumer or producer (whatever is
> needed) of linked modules, that link modules, that link modules,
> all of which are subject to replacements due to development
> iterations, bug patches etc, ie, new releases.
> 
> As in, the library versioning that is used for ELF object files,
> today often even linker scripts which furtherly diversify this,
> offer are not enough, they do not do this.  They only bundle
> a name to a library version, or multiple (as in
> 
>    1966 FUNC    GLOBAL DEFAULT   13 realpath@@GLIBC_2.3
>      33 FUNC    GLOBAL DEFAULT   13 realpath@GLIBC_2.2.5)
> 
> I do not know how Rust deals with this.  Is it at all possible to
> fixate all the call chain over all possibly involved dynamics?
> What do i gain from initializing an object with a default value if
> that default value is not not not not one of the values that
> i expect after some external function is called?
> 
> Sure i not rarely see patches fly by where one more memset(,0,) is
> used to fully initialize a struct / prevent memory address
> disclosures (i only track BSDs).
> And there are still patches that fix bugs on old code that
> sometimes is twenty years or more, say zlib or tzcode.
> And then there are compiler bugs that bring in bugs -- that is not
> avoidable, even if the documentation is clear and obvious like
> 
> /* The application can compare zlibVersion and ZLIB_VERSION for consistency.
>    If the first character differs, the library code actually used is not
>    compatible with the zlib.h header file used by the application.  This check
>    is automatically made by deflateInit and inflateInit.
>  */
> 
> That is only graspable by a human programmer that reads it.  Rapid
> application development that surely is not.
> (And actually i am not sure this is really true.  But i personally
> would hope for it.  It is more earthy, and has more blood, sweat
> and tears.)
> 
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Luther Johnson]

I think people expect the language to do too much these days, sort of 
like if it compiles without warnings then likely as not it works. I 
suppose that can be true with some languages if you follow certain 
patterns cookbooks, but it's not true of C or any program I ever wrote, 
I think this issue is a combination of style and language mechanics. I 
recently had to explain to a young manager, why I couldn't look at a 
program and tell him definitively whether it works or not. I did 
explain, but I don't think he really understood me, and I'm sure he was 
disappointed that I wasn't "good enough" to do that. Sort of the 
negative proof thing - if I find something wrong, I can make a pretty 
convincing argument why it's broken, but if I don't see anything wrong, 
that doesn't mean it works, and depending on such reviews without 
testing (which is also incomplete, but has the benefit that it may 
happen upon something we don't think of) is incredibly dangerous.

I think general software engineering knowledge and experience cannot be 
'obsoleted' or made less relevant by better languages. If they help, 
great, but you have to do the other part too. As languages advance and 
get better at catching (certain kinds of) mistakes, I worry that 
engineers are not putting enough time into observation and understanding 
of how their programs actually work (or do not).

On 01/31/2023 05:49 PM, Larry McVoy wrote:
> Even though I participated in this thread, so I too have sinned, this
> definitely wants to be discussed elsewhere.  comp.lang.c maybe?
>
> This discussion reminds a lot of what my career has been like.  Over and
> over again, I got told "that won't work".  I wasn't very interested in
> those people, if they stayed out of my way.  I was way more interested
> in the people who said "hmm, maybe if you did it this way".
>
> I've written a ton of working C code.  I've managed and guided others
> to do the same.  I'm positive that I've written way more commercially
> supported C code than was present in v6/v7 kernels.  Not sure about
> userspace, I think Unix has me beat there.
>
> The point?  It's very possible to write working C code.  You need good
> programmers and those seem to be going out of style so people are turning
> to Rust because it doesn't compile crappy code.
>
> I'm just happy to be retired, C worked for me for 40+ years, I feel
> like I dodged a learning curve bullet by getting out before I had to
> switch to Rust (or whatever).
>
> On Wed, Feb 01, 2023 at 01:40:23AM +0100, Steffen Nurpmeso wrote:
>> ron minnich wrote in
>>   <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>:
>>   |That example was a simplified bit of code from a widely used code base. All
>>   |I need to do is change the function g go a pointer to function, or have it
>>   |be provided by a .so, and all bets are off.
>>   |
>>   |In any event, the important thing here is not that y should be initialized,
>>   |or should not; it's that it is not possible to get a consistent answer on
>>   |the question, from people who have been writing in C for decades.
>>
>> I find the syntax just terrible.  (I have not programmed with it.)
>> I mean annotations are for the better, ok, (but i luckily get away
>> with only "const" and "volatile" (and "mutable"), and leave things
>> like "restrict" be a good man).  Johannes Lundberg i think it was
>> who then left FreeBSD (?) but pointing to a Rust program
>> he had written (i cannot find the reference), that was a few years
>> ago (i looked once i composed this message first, it might even
>> had been as early as 2017!), and i was lucky i do not have to deal
>> with it.
>>
>> Even nim-lang.org that at least converted its code to plain C back
>> in the day when it was still called Nimrod is too heavy for me now,
>> but claims to be hard realtime aware etc.  It at least tries to
>> give programmers some syntactic sugar that makes people happy when
>> they look at the screen for 7 hours (underpaid) or 16 hours
>> (over-ambitioned).  Like the only python thing i like, the
>> syntax sugar.  But as languages grow they get more and more
>> "refined", and now i read things like
>>
>>    type
>>      BinaryTree*[T] = ref object # BinaryTree is a generic type with
>>                                  # generic param `T`
>>        le, ri: BinaryTree[T]     # left and right subtrees; may be nil
>>        data: T                   # the data stored in a node
>>
>>    proc newNode*[T](data: T): BinaryTree[T] =
>>      # constructor for a node
>>      new(result)
>>      result.data = data
>>
>> which gets me off a bit and makes me think that "hey, maybe
>> Objective-C is not really the worst thing" (despite the syntax).
>>
>> I do not know.  Everything beyond a small monolithic
>> self-contained thing is a problem per se.  You can then unit test
>> atomically, and if thousands of modules do that, you plug them to
>> a better whole.  But that also not a good answer, all those flakes
>> that live their own life, many maybe even in remote locations out
>> of any control.
>>
>> You could have a language which hard fixates all the call chain,
>> or you could have tools which bring this to a small and simple
>> language which does not offer it.  A compiler can figure out which
>> variables are assigned etc and could create in-object-file
>> annotations which the linker automatically verifies.
>> Of course there are many code paths through functions.
>>
>> Back in 2009 when i bought the one Apple i wanted to have i tried
>> out their Development software, which i think required internet
>> access.  All the pop-ups and titles, i think it (later?) could
>> compile on-the-fly and inject the new object in the running tested
>> application, etc.
>>
>> And then there are semantic description languages like interface
>> builders, where robots create the actual code.  So then you could
>> have Corba interface descriptions / DBUS and plug it all via it.
>>
>> Then Rob Pike says "make it a string" (more or less), and luckily
>> i do not have dyslexia.
>>
>> Maybe Qt has a good answer by not only not banishing the
>> C preprocessor, but introducing another one on top.
>> So then the compiler can analyze the code and generate a correct
>> variable-state-at-function-call-time state that a dynamic linker
>> could then verify against the consumer or producer (whatever is
>> needed) of linked modules, that link modules, that link modules,
>> all of which are subject to replacements due to development
>> iterations, bug patches etc, ie, new releases.
>>
>> As in, the library versioning that is used for ELF object files,
>> today often even linker scripts which furtherly diversify this,
>> offer are not enough, they do not do this.  They only bundle
>> a name to a library version, or multiple (as in
>>
>>     1966 FUNC    GLOBAL DEFAULT   13 realpath@@GLIBC_2.3
>>       33 FUNC    GLOBAL DEFAULT   13 realpath@GLIBC_2.2.5)
>>
>> I do not know how Rust deals with this.  Is it at all possible to
>> fixate all the call chain over all possibly involved dynamics?
>> What do i gain from initializing an object with a default value if
>> that default value is not not not not one of the values that
>> i expect after some external function is called?
>>
>> Sure i not rarely see patches fly by where one more memset(,0,) is
>> used to fully initialize a struct / prevent memory address
>> disclosures (i only track BSDs).
>> And there are still patches that fix bugs on old code that
>> sometimes is twenty years or more, say zlib or tzcode.
>> And then there are compiler bugs that bring in bugs -- that is not
>> avoidable, even if the documentation is clear and obvious like
>>
>> /* The application can compare zlibVersion and ZLIB_VERSION for consistency.
>>     If the first character differs, the library code actually used is not
>>     compatible with the zlib.h header file used by the application.  This check
>>     is automatically made by deflateInit and inflateInit.
>>   */
>>
>> That is only graspable by a human programmer that reads it.  Rapid
>> application development that surely is not.
>> (And actually i am not sure this is really true.  But i personally
>> would hope for it.  It is more earthy, and has more blood, sweat
>> and tears.)
>>
>> --steffen
>> |
>> |Der Kragenbaer,                The moon bear,
>> |der holt sich munter           he cheerfully and one by one
>> |einen nach dem anderen runter  wa.ks himself off
>> |(By Robert Gernhardt)

[TUHS] Re: yet another C discussion (YACD)

[Warren Toomey via TUHS]

On Wed, Feb 01, 2023 at 01:50:05AM +0000, segaloco via COFF wrote:
> COFF'd

Thanks Matt. Yes please, C vs. Rust should mv to the COFF list.

Cheers, Warren

[TUHS] Algol rules: was something about Rust is not C++

[Will Senn]

Well, I just read this as Rust is dead... here's hoping, but seriously, 
if we're gonna go off and have a language vs language discussion, I 
personally don't think we've had any real language innovation since 
Algol 60, well maybe lisp... sheesh, surely we're in COFF territory.

On 1/31/23 6:40 PM, Steffen Nurpmeso wrote:
> ron minnich wrote in
>   <CAP6exY+Qz2Oe4gC4D1Fqy22JKKDaanTOYpc0gxugBv485JUknQ@mail.gmail.com>:
>   |That example was a simplified bit of code from a widely used code base. All
>   |I need to do is change the function g go a pointer to function, or have it
>   |be provided by a .so, and all bets are off.
>   |
>   |In any event, the important thing here is not that y should be initialized,
>   |or should not; it's that it is not possible to get a consistent answer on
>   |the question, from people who have been writing in C for decades.
>
> I find the syntax just terrible.  (I have not programmed with it.)
> I mean annotations are for the better, ok, (but i luckily get away
> with only "const" and "volatile" (and "mutable"), and leave things
> like "restrict" be a good man).  Johannes Lundberg i think it was
> who then left FreeBSD (?) but pointing to a Rust program
> he had written (i cannot find the reference), that was a few years
> ago (i looked once i composed this message first, it might even
> had been as early as 2017!), and i was lucky i do not have to deal
> with it.
>
> Even nim-lang.org that at least converted its code to plain C back
> in the day when it was still called Nimrod is too heavy for me now,
> but claims to be hard realtime aware etc.  It at least tries to
> give programmers some syntactic sugar that makes people happy when
> they look at the screen for 7 hours (underpaid) or 16 hours
> (over-ambitioned).  Like the only python thing i like, the
> syntax sugar.  But as languages grow they get more and more
> "refined", and now i read things like
>
>    type
>      BinaryTree*[T] = ref object # BinaryTree is a generic type with
>                                  # generic param `T`
>        le, ri: BinaryTree[T]     # left and right subtrees; may be nil
>        data: T                   # the data stored in a node
>
>    proc newNode*[T](data: T): BinaryTree[T] =
>      # constructor for a node
>      new(result)
>      result.data = data
>
> which gets me off a bit and makes me think that "hey, maybe
> Objective-C is not really the worst thing" (despite the syntax).
>
> I do not know.  Everything beyond a small monolithic
> self-contained thing is a problem per se.  You can then unit test
> atomically, and if thousands of modules do that, you plug them to
> a better whole.  But that also not a good answer, all those flakes
> that live their own life, many maybe even in remote locations out
> of any control.
>
> You could have a language which hard fixates all the call chain,
> or you could have tools which bring this to a small and simple
> language which does not offer it.  A compiler can figure out which
> variables are assigned etc and could create in-object-file
> annotations which the linker automatically verifies.
> Of course there are many code paths through functions.
>
> Back in 2009 when i bought the one Apple i wanted to have i tried
> out their Development software, which i think required internet
> access.  All the pop-ups and titles, i think it (later?) could
> compile on-the-fly and inject the new object in the running tested
> application, etc.
>
> And then there are semantic description languages like interface
> builders, where robots create the actual code.  So then you could
> have Corba interface descriptions / DBUS and plug it all via it.
>
> Then Rob Pike says "make it a string" (more or less), and luckily
> i do not have dyslexia.
>
> Maybe Qt has a good answer by not only not banishing the
> C preprocessor, but introducing another one on top.
> So then the compiler can analyze the code and generate a correct
> variable-state-at-function-call-time state that a dynamic linker
> could then verify against the consumer or producer (whatever is
> needed) of linked modules, that link modules, that link modules,
> all of which are subject to replacements due to development
> iterations, bug patches etc, ie, new releases.
>
> As in, the library versioning that is used for ELF object files,
> today often even linker scripts which furtherly diversify this,
> offer are not enough, they do not do this.  They only bundle
> a name to a library version, or multiple (as in
>
>     1966 FUNC    GLOBAL DEFAULT   13 realpath@@GLIBC_2.3
>       33 FUNC    GLOBAL DEFAULT   13 realpath@GLIBC_2.2.5)
>
> I do not know how Rust deals with this.  Is it at all possible to
> fixate all the call chain over all possibly involved dynamics?
> What do i gain from initializing an object with a default value if
> that default value is not not not not one of the values that
> i expect after some external function is called?
>
> Sure i not rarely see patches fly by where one more memset(,0,) is
> used to fully initialize a struct / prevent memory address
> disclosures (i only track BSDs).
> And there are still patches that fix bugs on old code that
> sometimes is twenty years or more, say zlib or tzcode.
> And then there are compiler bugs that bring in bugs -- that is not
> avoidable, even if the documentation is clear and obvious like
>
> /* The application can compare zlibVersion and ZLIB_VERSION for consistency.
>     If the first character differs, the library code actually used is not
>     compatible with the zlib.h header file used by the application.  This check
>     is automatically made by deflateInit and inflateInit.
>   */
>
> That is only graspable by a human programmer that reads it.  Rapid
> application development that surely is not.
> (And actually i am not sure this is really true.  But i personally
> would hope for it.  It is more earthy, and has more blood, sweat
> and tears.)
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)

[TUHS] Re: Algol rules: was something about Rust is not C++

[Chet Ramey]

On 1/31/23 7:50 PM, Will Senn wrote:
> Well, I just read this as Rust is dead... 

Rust never sleeps.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[TUHS] Re: Algol rules: was something about Rust is not C++

[Luther Johnson]

I worry about Rust on bare metal.

On 01/31/2023 06:18 PM, Chet Ramey wrote:
> On 1/31/23 7:50 PM, Will Senn wrote:
>> Well, I just read this as Rust is dead... 
>
> Rust never sleeps.
>

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
 <20230201004023.rHE9j%steffen@sdaoden.eu>:
 ...

P.S.: What i will never forget, it came in the major news TV
program of Germany (ARD Tagesschau, public law; iirc), was when
JAVA came up.  Small (Campus?) Cafe in America, two young male
programmers and one young female programmer, and she was asked why
JAVA, .. and she said something like "this is our opportunity".
Maybe this is the thing about the name Rust that i go with.
Whether it makes anything "better", i do not know.  But it is
maybe an opportunity for a generation to go/nim/julia their way.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Luther Johnson]

I think you are right, this is an important component, people joining 
and identifying themselves with a language movement. And planning to be 
there to fill the need for "Language X" programmers.

On 01/31/2023 05:53 PM, Steffen Nurpmeso wrote:
> Steffen Nurpmeso wrote in
>   <20230201004023.rHE9j%steffen@sdaoden.eu>:
>   ...
>
> P.S.: What i will never forget, it came in the major news TV
> program of Germany (ARD Tagesschau, public law; iirc), was when
> JAVA came up.  Small (Campus?) Cafe in America, two young male
> programmers and one young female programmer, and she was asked why
> JAVA, .. and she said something like "this is our opportunity".
> Maybe this is the thing about the name Rust that i go with.
> Whether it makes anything "better", i do not know.  But it is
> maybe an opportunity for a generation to go/nim/julia their way.
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>

[TUHS] Re: yet another C discussion (YACD) and: Rust is not C++

[Blake McBride]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Although few will admit when their uneducated opinion is wrong, it is true
that Rust and C++ are very different.  They are as different as any two
clearly different languages are.  Their respective feature sets are quite
different and do not overlap any more than any two totally different
languages do.

Blake McBride


On Mon, Jan 30, 2023 at 11:26 AM ron minnich <rminnich@gmail.com> wrote:

> I did not want to disrupt the FD 2 discussion, but I could not really let
> this comment go unanswered:
>
> "Smells like C++ to me. Rust in essence is a re-implementation of C++ not
> C. It tries to pack as much features as it possibly can. "
>
> It's hard for me to see how you can say this if you have done any work in
> Rust and C++.
>
> But, short form: Rust is not C++. Full stop.
>
> I did not feel that comment should go unanswered, lest people believe it.
>

[-- Attachment #2: Type: text/html, Size: 1306 bytes --]