31 Jan
2023
31 Jan
'23
1:35 a.m.
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(a)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(a)andykosela.com> wrote:
On Monday, January 30, 2023, ron minnich <rminnich(a)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