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