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

[ron minnich <rminnich@gmail.com>]

[-- 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 --]