From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7992 invoked from network); 30 Jan 2023 19:37:04 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Jan 2023 19:37:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 189C44264C; Tue, 31 Jan 2023 05:36:58 +1000 (AEST) Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 8DAB34264B for ; Tue, 31 Jan 2023 05:36:54 +1000 (AEST) Received: by mail-qk1-f171.google.com with SMTP id d18so1608580qko.12 for ; Mon, 30 Jan 2023 11:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ALg2sxQvQr5C15d/TDJkzuWZrZ+C1tSkmNzwMS83COk=; b=Pb7NZ2LzFQ6y4kvJ6Sm7ISrTzjVhPPUFzYQEGvsSsZOJd28zwvxgh+wOt9gfbz4evw QTUOnbeFTian0PETP0kJkPmoeiFmT4lGB87wV05C5gajwilY1ZGruWNnc9vYQuksXAOC d+q3M+nNX8NM/CS4whOs0L5Zw0ytTOcrRQ1aXNHVQXnP+rEcfRoJ7vm22txC5jClUaIE Pn5giPouIHaeFCvRxcj7xykiOB03lqAsgUQAgMEOkt4AhiMn8YoEcAE6QP667nr3pYUm tRXYxEik4dPA9YMiZltUv7iYVLk+cp0Euuvwm4yVTJ6qEJLgkHRjsL7QQ1zm8yJ0I7K1 lBbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ALg2sxQvQr5C15d/TDJkzuWZrZ+C1tSkmNzwMS83COk=; b=w70bKxsrDvqWJ4nxL/7va/tPGs9cA9qz2+4rWI3O7sNAyDp9bD8gGPl5DCV8jsP5xp 1IZGbrVw/U0wnkj0EQdn5Rt48OR1lpAzmAxUbmTKaEBXJ7qIiLbkH3eRrp+Saz0r23dF 7ucrxvnq3bAGn9KnYcaxz+FnWEoZknLTKjwWBoBQfYIcoLSjKh0Uab8U4HaSZajEPbI3 Yuzzf7XTAtO9Mb8l7A0XcvWgk0UZt0DInJb3JbscZpz/fgQspJ92dx5jzJRKMRD4d0P2 dMbLIBqi0GJ9rHBWoLSjtZX+LGONMPQ4aMCpF5Yw0LdWLoolcbyxAqkJt3r2lVMxd9cx cHpg== X-Gm-Message-State: AFqh2koEq731wsN7rMGwMCPmiGndnRzDDeP+47SQrL+nQmusnOMrWPZU jC3jN/yAWjeH9WCeYleE1SjJzkXdbOeSAqtxE8DLKJkYCWQ= X-Google-Smtp-Source: AMrXdXuyL+gdqKSnEePWl4JcPbmVTYzN+6naN41xDfRo67pxnwXetSJk+HBu1YXQL8olnfz+RMB4UAvOaWdb12wMOaw= X-Received: by 2002:a05:620a:9cf:b0:6fe:d495:390a with SMTP id y15-20020a05620a09cf00b006fed495390amr3524332qky.149.1675107353449; Mon, 30 Jan 2023 11:35:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: ron minnich Date: Mon, 30 Jan 2023 11:35:42 -0800 Message-ID: To: segaloco Content-Type: multipart/alternative; boundary="000000000000c35b4e05f380523b" Message-ID-Hash: YHBJAENORVDPTQRCZS3EDQEZX5QIQNLN X-Message-ID-Hash: YHBJAENORVDPTQRCZS3EDQEZX5QIQNLN X-MailFrom: rminnich@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: yet another C discussion (YACD) and: Rust is not C++ List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c35b4e05f380523b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > My understanding is it might "look and feel" more C++-ish than C, but wha= t > it is doing under the hood for memory safety and such results in code muc= h > 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, bu= t > 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 wit= h > the two languages, but my understanding is Rust is a C-ish systems langua= ge > parading around in fancy modern clothes, but it achieves most of its more > sophisticated functionality at compile time rather than relying on a bunc= h > 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 slowl= y > 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 doin= g > 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 moder= n > programmers *and*=E2=80=8B similar performance to C where it counts. If = nothing > else, I can credit Rust as the first new language I've actually bought th= e > 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 wrote: > >> I did not want to disrupt the FD 2 discussion, but I could not really le= t >> this comment go unanswered: >> >> "Smells like C++ to me. Rust in essence is a re-implementation of C++ no= t >> 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 i= n >> 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 migh= t > 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 > > > --000000000000c35b4e05f380523b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't know how many ways there are to say this, but = Rust and C/C++ are fundamentally different at the lowest level.=C2=A0
<= br>
If you are just looking=C2=A0at 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. I= t's like saying C is "just like assembly" because labels=C2= =A0have a ':' in them; or that Unix is "just like RSX" be= cause they have vaguely similar=C2=A0commands.

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

char f() {

=C2=A0 char *y;

=C2=A0 g(&y);

=C2=A0 return *y;

}


A specific question: should y b= e initialized to NULL?=C2=A0
The case to set y to NULL: otherwise= it has an unknown=C2=A0value and it's unsafe.=C2=A0
The case= against setting y to NULL: it is pointless, as it slows the code down slig= htly and g is going to change it anyway.=C2=A0
The case maybe: Wh= y 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 amb= iguity. It won't compile. In fact, & doesn't mean in Rust what = it does in C.=C2=A0

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 R= ust is just astonishing. I think folks have been waiting for something to r= eplace C for a long time, and Rust, with all its headaches and issues, is l= ikely to be that thing.=C2=A0

Personally, I still = prefer Go, but I can also see which way the wind is blowing, especially whe= n I see Rust use exploding in firmware and user mode, and now even in the L= inux 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++-is= h than C, but what it is doing under the hood for memory safety and such re= sults 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 li= ke ownership.=C2=A0 The result is that things like memory safety are handle= d by the compiler's analysis rather than libraries.=C2=A0 Sure you may = have more modern-looking OOP constructs, but my understanding is those cons= tructs are closer to syntactic sugar than what most C++ environments do wit= h 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 paradin= g around in fancy modern clothes, but it achieves most of its more sophisti= cated functionality at compile time rather than relying on a bunch of runti= me code to keep everything rolling.

I don't think Rust will "replace&qu= ot; C any time soon, just like C hasn't really "replaced" FOR= TRAN and COBOL in a lot of places, but it will continue to grow as a system= s-programming language, especially what with the Linux kernel starting to g= reenlight Rust components.=C2=A0 Regardless, I personally see future value = in Rust and so I nabbed the book and am slowly learning it.=C2=A0 Hopefully= it isn't time wasted and we start seeing more Rust-native interfaces o= ut there.=C2=A0 One of the main things holding me back is a lack of native = OpenGL interfacing.=C2=A0 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.=C2=A0 As for writing my own bindings, I could do tha= t...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 an= d=E2=80=8B similar performance to C where it counts.=C2=A0 If nothing e= lse, I can credit Rust as the first new language I've actually bought t= he 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 discus= sion, 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, shor= t form: Rust is not C++. Full stop.

I did not fee= l 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 &q= uot;features" certainly bring it closer to C++. While it might be easi= er to write safer code in Rust than in C++, I still think that its "we= ird" syntax and feature bloat make me dislike it the way I dislike C++= .

Just my .02. YMMV.

--An= dy

--000000000000c35b4e05f380523b--