From nobody Thu Sep 12 00:36:06 2024
X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X3z5p59XBz5W1Wk
for <freebsd-hackers@mlmmj.nyi.freebsd.org>; Thu, 12 Sep 2024 00:36:46 +0000 (UTC)
(envelope-from estrabd@gmail.com)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "smtp.gmail.com", Issuer "WR4" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 4X3z5n2xk2z4QTZ;
Thu, 12 Sep 2024 00:36:45 +0000 (UTC)
(envelope-from estrabd@gmail.com)
Authentication-Results: mx1.freebsd.org;
dkim=pass header.d=gmail.com header.s=20230601 header.b=WWUuZKyH;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (mx1.freebsd.org: domain of estrabd@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=estrabd@gmail.com
Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5c3d20eed0bso396494a12.0;
Wed, 11 Sep 2024 17:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1726101404; x=1726706204; darn=freebsd.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=Mq5aCm6rtzNA7ZguL1ETepzlauDVV+9YuD8v9vBqcDA=;
b=WWUuZKyHSwkZ4/PPx5XxvoqqF07f5Z5o2hIFE8ka5MQcCdWq3idXeS02MW2WsnhaK+
UrZNu3K0gxmo5eHW4aS6pX218tBBsmFM2+khrS4UJSYUqkirl39s/QT2zT6zqbJpOnEE
4+gv34NYeFjQ4SL80/1SjZ0FQj/48bizkNxf/+SZHG6pm+w4OIow77u0wi+mQpCK2IXg
pHH7y3Rri/bMWnNeasZl6nE2Q32jf8hX18uQCH2STUNvDAjY1K+6OQW1/374DNi9UBf6
15Lmg9H9HUpHjE4yIft4NRnOT5/hzngnVKYrOlSd9tkwsj3IvJOsSHMA75bgGf5BlQNh
7LXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1726101404; x=1726706204;
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=Mq5aCm6rtzNA7ZguL1ETepzlauDVV+9YuD8v9vBqcDA=;
b=RO26uLDeoltGXvlFRXhGjqwWrgvLO6lSJoMB0RBuun/by3L+9wNIlc8clT6afMrW6f
nt4cm9yMKlpknE/HNi5dZWns9LuOMpsSaWpOLbdcsXjxVP54RTuUu9hxmRXB6cpwQMbR
kKaNtk0CjvIpgZ18JhR7DBu4o6TaGY9mL5qrcVIJ9gj08BYdW89kHPbZHKhsXPOqJSiF
uLAi81qzwcetmV32oeweHpe7znL9nQe7x9PPj8UooZw8QBRfpzRrUVuiDFznGbqTErVR
IkXYcCP3XHiG53HKwcY1Wy+Ou2wT9j/yEQW0LoAALtt0CjoRKEwN1du/DiV+OQ1HhEmZ
EX/Q==
X-Forwarded-Encrypted: i=1; AJvYcCVRE6btORK2v5aL7YximPXuJGM4uA+sL7iNDW6Op2EzmE5YvZy46n2ihtTNfkvx0rNuLFc5IORcSIbhAqaefNA=@freebsd.org
X-Gm-Message-State: AOJu0YzUiQA+SHjAoLE+utyODN3tGVjAKIVtlQBhyjf/k4H/I1Zhu/Ep
XtjMsj/9MXWa/ZE9LcEMVjO8+y3ORtLuzhHYaBdZiYZFevkv7rNF+NiJUaV4Rznq1cmzVMFjAVH
JpIkFf7m58vpbA2BOeetg1nGgZhU=
X-Google-Smtp-Source: AGHT+IGJ3z2QmrjzrePFn6ILb13wBoPWGZnKm8yR+CzpjlbyrrVq1/bZvKIvtaZlDRKvprkdAHZwlGyTP2Mb50ZNjqE=
X-Received: by 2002:a17:907:26c3:b0:a72:50f7:3c6f with SMTP id
a640c23a62f3a-a9029432757mr82081666b.14.1726101403534; Wed, 11 Sep 2024
17:36:43 -0700 (PDT)
List-Id: Technical discussions relating to FreeBSD <freebsd-hackers.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-hackers
List-Help: <mailto:freebsd-hackers+help@freebsd.org>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Subscribe: <mailto:freebsd-hackers+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-hackers+unsubscribe@freebsd.org>
Sender: owner-freebsd-hackers@FreeBSD.org
MIME-Version: 1.0
References: <CAGBxaXmeLQudhP428wCSEsGh0+bpiM8=To4HbohdwsGcsE5Qbg@mail.gmail.com>
<CAOtMX2g0xcaDvXQLzntDs1cvzVx_wnTPTw7+1GV2KtS=AytOgg@mail.gmail.com> <CAGBxaXmRksYTnJyy9a88Jvt_uqZu+JDkOwNO=D60+fVqH+bBYw@mail.gmail.com>
In-Reply-To: <CAGBxaXmRksYTnJyy9a88Jvt_uqZu+JDkOwNO=D60+fVqH+bBYw@mail.gmail.com>
From: "B. E." <estrabd@gmail.com>
Date: Wed, 11 Sep 2024 19:36:06 -0500
Message-ID: <CALSf6fTGj_8f6gHN=Hz8hg0a9LZPWNsSJAr3E-jFY_yt0mHyig@mail.gmail.com>
Subject: Re: Some rather stupid questions about Rust and FreeBSD
To: Aryeh Friedman <aryeh.friedman@gmail.com>
Cc: Alan Somers <asomers@freebsd.org>, FreeBSD Mailing List <freebsd-hackers@freebsd.org>
Content-Type: multipart/alternative; boundary="000000000000010f730621e14d99"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-4.00 / 15.00];
NEURAL_HAM_SHORT(-1.00)[-1.000];
NEURAL_HAM_MEDIUM(-1.00)[-1.000];
NEURAL_HAM_LONG(-1.00)[-1.000];
DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601];
R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
MIME_GOOD(-0.10)[multipart/alternative,text/plain];
RCVD_TLS_LAST(0.00)[];
TO_DN_ALL(0.00)[];
FROM_HAS_DN(0.00)[];
ARC_NA(0.00)[];
FREEMAIL_ENVFROM(0.00)[gmail.com];
FREEMAIL_TO(0.00)[gmail.com];
FREEMAIL_FROM(0.00)[gmail.com];
MIME_TRACE(0.00)[0:+,1:+,2:~];
DKIM_TRACE(0.00)[gmail.com:+];
MISSING_XM_UA(0.00)[];
RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from];
MID_RHS_MATCH_FROMTLD(0.00)[];
TO_MATCH_ENVRCPT_SOME(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
RCPT_COUNT_THREE(0.00)[3];
MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org];
ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US];
TAGGED_RCPT(0.00)[];
RCVD_COUNT_ONE(0.00)[1];
DWL_DNSWL_NONE(0.00)[gmail.com:dkim]
X-Rspamd-Queue-Id: 4X3z5n2xk2z4QTZ
--000000000000010f730621e14d99
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
It doesn't matter the technicalities, Rust enthusiasts are looking for
relevancy in a post-language wars world; and they think falsely that their
only recourse is to invade established camps.
I feel sorry for them in a lot of ways, but this is the time for them to be
discovering problem domains or creating solutions that Rust is uniquely
good for; and not copying or corrupting established technical communites.
Augmenting FreeBSD *somehow* is not a legitimate problmem domain nor is it
something uniquely solved by Rust. Don't be a solution in search of a
problem is my best advice to the Rust community - unfortunately much of the
low hanging problems have been picked; but there are plenty of slightly
less easy problems to solve.
So, this is ideologically and existentially driven, and rational arguments
are not enough (FreeBSD is not experiencing this alone). Setting extremely
hard boundaries, in charity, is the only answer. I am a mere casual but
consistent user of FreeBSD from a long time ago, and I very strongly
support all firm (but charitable) opposition to Rust being required to run
FreeBSD.
Cheers,
Brett
On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman <aryeh.friedman@gmai=
l.com>
wrote:
> On Wed, Sep 11, 2024 at 7:02=E2=80=AFPM Alan Somers <asomers@freebsd.org>=
wrote:
>
> > > 2. The code looks no better than portable assembly and if that is the
> > > case why does it need to be in the kernel when there is already a
> > > perfectly good portable assembly already there known as C?
> >
> > I don't know if you're being serious or trolling. I ought to assume
> > the former, but if you genuinely can't tell the difference between
> > Rust and assembly source code then you obviously haven't looked at one
> > or the other for more than a few seconds.
>
> If I had wanted to troll instead of genuinely out of pure curosity I
> could of compared all three languages to a language I am currently
> writting to use in a forth come PhD thesis that is purefly function,
> gate level (with abstractions allowed), has no explicit flow control
> except for calling functions and few other really oddball things.
> But I am not going to say anything more about that and instead focus
> on why I made the comment I did:
>
> 1. C when super optimized has about a 2 to 1 ratio between expressions
> and emitted machine instructions but it self is semantically much
> easier to deal with then assembly and the fact it is a high level
> language means it in theory portable to any machine a compiler is
> implemented on.
>
> 2. I consider assembly fairly high level actually compared to the
> topic I am not trolling on (I am at the level of building UTM's from
> gates)
>
> > So I think you must be
> > exaggerating, and you really mean "Rust looks no more or less readable
> > than C". For a good example of why Rust (and other modern languages)
> > can be more readable than C, compare these examples, which sort an
> > array:
> >
> > in C
> > =3D=3D=3D=3D
> > int compare(const void* a, const void* b) {
> > return (*(int*)a - *(int*)b);
> > }
>
> I completely agree pointers are evil and that's why I (like Rust it
> appears) *ONLY* allow arrays and array references not direct pointers
> into physical address space. This way we still have the advantage of
> being able to use base+offset addressing modes instead of having the
> language processor/executor compute absolute addresses at run time.
>
> >
> > int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 };
> > int n =3D sizeof(arr) / sizeof(arr[0]);
> > qsort(arr, n, sizeof(int), compare);
>
> So C is not OO (what a surprise ;-)) but it does do one thing right is
> it separates out the concerns of storage from processing at the lowest
> levels (hard to get above that level and that is why I use Java for my
> freelancing work). Which when working in any language is a good idea
> but since C is not OO we are stuck with naked function calls (no harm
> in that)
>
> >
> > in Rust
> > =3D=3D=3D=3D=3D=3D=3D
> > let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66];
> > arr.sort();
>
> The fact the data structure even worries about behaviour instead of
> being passable to objects is asking for it (this is from my software
> engineering hat). Also the fact there is no explicit size of the
> array defined since if it is static a Turing complete process can be
> implemented on it but if it is dynamic how do you keep from
> overflowing the storage allocated to it (aka buffer overflow).
>
> > * The size of the array
>
> Very good idea from the resource management POV
>
> > * The size of each element
>
> Again correct call for an OS level language.
>
> > * The name of the comparison function
>
> Separation of concerns *STANDARD* software engineering.
>
> >
> > Each of those is error-prone. Stuff like that is a common source of
> > bugs in C code. But Rust tracks it automatically.
>
> At the cost of coupling stuff far too tightly it appears.
>
>
--000000000000010f730621e14d99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>It doesn't matter the technicali=
ties, Rust enthusiasts are looking for relevancy in a post-language wars wo=
rld; and they think falsely that their only recourse is to invade establish=
ed camps.</div><div><br></div><div><div>I feel sorry for them in a lot of w=
ays, but this is the time for them to be=20
discovering problem domains or creating solutions that Rust is uniquely goo=
d for; and not copying or corrupting
established technical communites. Augmenting FreeBSD <i>somehow</i> is no=
t a legitimate problmem domain=20
nor is it something uniquely solved by Rust. Don't be a solution in=20
search of a problem is my best advice to the Rust community -=20
unfortunately much of the low hanging problems have been picked; but=20
there are plenty of slightly less easy problems to solve.</div></div><div><=
br></div><div>So, this is ideologically and existentially driven, and ratio=
nal arguments are not enough (FreeBSD is not experiencing this alone). Sett=
ing extremely hard boundaries, in charity, is the only answer. I am a mere =
casual but consistent user of FreeBSD from a long time ago, and I very stro=
ngly support all firm (but charitable) opposition to Rust being required to=
run FreeBSD.<br></div><div><br></div><div>Cheers,<br></div><div>Brett<br><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Wed, Sep 11, 2024 at 7:11=E2=80=AFPM Aryeh Friedman <<a href=3D"=
mailto:aryeh.friedman@gmail.com">aryeh.friedman@gmail.com</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Sep 11, 20=
24 at 7:02=E2=80=AFPM Alan Somers <<a href=3D"mailto:asomers@freebsd.org=
" target=3D"_blank">asomers@freebsd.org</a>> wrote:<br>
<br>
> > 2. The code looks no better than portable assembly and if that is=
the<br>
> > case why does it need to be in the kernel when there is already a=
<br>
> > perfectly good portable assembly already there known as C?<br>
><br>
> I don't know if you're being serious or trolling.=C2=A0 I ough=
t to assume<br>
> the former, but if you genuinely can't tell the difference between=
<br>
> Rust and assembly source code then you obviously haven't looked at=
one<br>
> or the other for more than a few seconds.<br>
<br>
If I had wanted to troll instead of genuinely out of pure curosity I<br>
could of compared all three languages to a language I am currently<br>
writting to use in a forth come PhD thesis that is purefly function,<br>
gate level (with abstractions allowed), has no explicit flow control<br>
except for calling functions and=C2=A0 few other really oddball things.<br>
But I am not going to say anything more about that and instead focus<br>
on why I made the comment I did:<br>
<br>
1. C when super optimized has about a 2 to 1 ratio between expressions<br>
and emitted machine instructions but it self is semantically much<br>
easier to deal with then assembly and the fact it is a high level<br>
language means it in theory portable to any machine a compiler is<br>
implemented on.<br>
<br>
2. I consider assembly fairly high level actually compared to the<br>
topic I am not trolling on (I am at the level of building UTM's from<br=
>
gates)<br>
<br>
> So I think you must be<br>
> exaggerating, and you really mean "Rust looks no more or less rea=
dable<br>
> than C".=C2=A0 For a good example of why Rust (and other modern l=
anguages)<br>
> can be more readable than C, compare these examples, which sort an<br>
> array:<br>
><br>
> in C<br>
> =3D=3D=3D=3D<br>
> int compare(const void* a, const void* b) {<br>
>=C2=A0 =C2=A0 =C2=A0 return (*(int*)a - *(int*)b);<br>
> }<br>
<br>
I completely agree pointers are evil and that's why I (like Rust it<br>
appears) *ONLY* allow arrays and array references not direct pointers<br>
into physical address space.=C2=A0 =C2=A0This way we still have the advanta=
ge of<br>
being able to use base+offset addressing modes instead of having the<br>
language processor/executor compute absolute addresses at run time.<br>
<br>
><br>
> int arr[] =3D { 170, 45, 75, 90, 802, 24, 2, 66 };<br>
> int n =3D sizeof(arr) / sizeof(arr[0]);<br>
> qsort(arr, n, sizeof(int), compare);<br>
<br>
So C is not OO (what a surprise ;-)) but it does do one thing right is<br>
it separates out the concerns of storage from processing at the lowest<br>
levels (hard to get above that level and that is why I use Java for my<br>
freelancing work).=C2=A0 =C2=A0Which when working in any language is a good=
idea<br>
but since C is not OO we are stuck with naked function calls (no harm<br>
in that)<br>
<br>
><br>
> in Rust<br>
> =3D=3D=3D=3D=3D=3D=3D<br>
> let mut arr =3D vec![170, 45, 75, 90, 802, 24, 2, 66];<br>
> arr.sort();<br>
<br>
The fact the data structure even worries about behaviour instead of<br>
being passable to objects is asking for it (this is from my software<br>
engineering hat).=C2=A0 =C2=A0Also the fact there is no explicit size of th=
e<br>
array defined since if it is static a Turing complete process can be<br>
implemented on it but if it is dynamic how do you keep from<br>
overflowing the storage allocated to it (aka buffer overflow).<br>
<br>
> * The size of the array<br>
<br>
Very good idea from the resource management POV<br>
<br>
> * The size of each element<br>
<br>
Again correct call for an OS level language.<br>
<br>
> * The name of the comparison function<br>
<br>
Separation of concerns *STANDARD* software engineering.<br>
<br>
><br>
> Each of those is error-prone.=C2=A0 Stuff like that is a common source=
of<br>
> bugs in C code.=C2=A0 But Rust tracks it automatically.<br>
<br>
At the cost of coupling stuff far too tightly it appears.<br>
<br>
</blockquote></div></div>
--000000000000010f730621e14d99--