Re: The Case for Rust (in any system)

On Tue, 10 Sep 2024 13:23:52 -0500
Kyle Evans <kevans@FreeBSD.org> wrote:

> On 9/10/24 11:06, Tomoaki AOKI wrote:
> > On Tue, 10 Sep 2024 10:11:54 -0500
> > Kyle Evans <kevans@FreeBSD.org> wrote:
> > 
> >> On 9/10/24 09:49, Tomoaki AOKI wrote:
> >>> On Mon, 9 Sep 2024 16:11:40 -0500
> >>> Kyle Evans <kevans@FreeBSD.org> wrote:
> >>>
> >>>> On 9/5/24 13:09, Alan Somers wrote:
> >>>>> By now I expect that most of you have seen the long list of new
> >>>>> security advisories that just came out.  Strikingly, all were the
> >>>>> result of memory handling errors.  And none of them wouldn't have
> >>>>> happened if their respective programs had been written in a
> >>>>> memory-safe language.
> >>>>>
> >>>>> In fact, of all the C bug fixes that I've been involved with (as
> >>>>> either author or reviewer) since May, about three quarters could've
> >>>>> been avoided just by using a better language.
> >>>>>
> >>>>> The real takeaway here is that C is no longer sufficient for writing
> >>>>> high quality code in the 2020s.  Everyone needs to adapt their tools.
> >>>>> Programmers who don't will increasingly come to resemble experimental
> >>>>> archaeologists, i.e. people who learn flintknapping to "keep the
> >>>>> knowledge alive".  Such people are valuable, but definitely niche.  I
> >>>>> for one don't want my career to go in that trajectory.
> >>>>>
> >>>>> To summarize, here's the list of this week's security advisories, and
> >>>>> also some other recent C bug fixes of my own involvement:
> >>>>    > [... snip ...]
> >>>>
> >>>> If even half of the energy that has gone into these threads would've
> >>>> been spent on a proof-of-concept rust-xtoolchain implementation with
> >>>> some motivating cases instead, we'd be in a lot better place to actually
> >>>> have these conversations.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Kyle Evans
> >>>
> >>> Shawn would be working on the PoC now. Let's see how it goes.
> >>>
> >>> The worst is that the work is rejected AFTER it's almost done.
> >>> It's clearly wastes of times/efforts.
> >>>
> >>
> >> IMO if (general) you did enough work that you're angry about it being
> >> rejected, then you probably did way more than you should've for the
> >> stage we're at.  If you're rewriting major utilities/daemons for a PoC /
> >> talking point, then you're doing it wrong.
> > 
> > Angry or not does not at all matter here.
> > Proceeding wrong direction because of insufficient discussion and
> > consensus is the waste of time.
> > 
> > Introducing brand-new language(s) into base is quite a large movement.
> > So my guess is that now is still the time for "brainstorming" before
> > starting actual and effective discussions.
> > 
> 
> It's really not a large movement, though, to get the bare basics done to 
> evaluate a new language.  As stated repeatedly, we don't need the 
> toolchain for a new language in base and the new language wouldn't be in 
> the 'default on' path.  That's not exactly a huge commitment, then you 
> talk about where it needs to go from there (preferably as part of 
> pre-commit discussion, but also ongoing as you want to try and expand).

Evaluation and introduction is mutually different thing.
I guess evaluating a new language is NOT a large movement.
But actually introducing it into tree is quite different.

With new language (means, compiler) outside base (in ports/pkgs),
I and some others suport the idea, but there are objections, too. 

Why I consider "introducing a new language" as large/huge movement is
that the codes in base written in the language should be supported
until its functionalities are required. But new languages has risks
that it doesn't survive long enough terms, both in language itself and
human resources. Without the both, FreeBSD project at the moment should
force to rewrite the codes into C/C++ or any othe new languages.

Taking the risk or not shoulf be discussed enough.
And it doesn't seem to come to an end. Still diverging.


> >>> My guess about this thread is that it is needed to determine what is
> >>> acceptable, what's not, what's needed to be confirmed.
> >>>
> >>
> >> Except it's been increasingly clear even before this discussion fired up
> >> again that a large chunk of the people involved don't have a good point
> >> of reference to even have this discussion.  You're wearing them down on
> >> the topic before you even have something to point at and say "Hey, this
> >> is what it might look like" and maybe a roadmap for some of the
> >> low-hanging fruit for things we can improve with it.
> > 
> > Again, I think now is still at the time (phase/state) of brainstorming.
> > Non-chaotic brainstorming is in many cases useless.
> > 
> 
> We'll have to agree to disagree on that, I don't really see much 
> productive vs. slightly different phrasings of the same arguments.

My most important point I've intentionally didn't directly written is
that I don't want to see cases like newbus vs newconfig case anymore.

IIRC, newconfig was proposed from Japanese developers when it was almost
ready, and rejected. I think if enough discussions are done on quite
early phase, the huge mess shouldn't happen.
So I love to see these quite active discussions on this quite early
phase.

And opinion from yuri@ [3] seems to be a good example for "constructive
objections".

[3]
https://lists.freebsd.org/archives/freebsd-hackers/2024-September/003872.html


> >>> Clarifying the above as much as possible before starting the work is
> >>> a good thing. Now we know how many pros&cons exists, and what are
> >>> proposed as possible alternatives. Unfortunately, it's still "chaotic"
> >>> and maybe need some more times.
> >>>
> >>> And discussions are ongoing at forums.frebsd.org, too. [1]
> >>> It already is quite a long thread.
> >>>
> >>>
> >>> [1]
> >>> https://forums.freebsd.org/threads/the-case-for-rust-in-the-base-system.92024/
> >>>
> >>
> >> I'd go as far as to say that none of this is all that useful until we
> >> can evaluate how much pain we're in for in trying to add this
> >> dependency, but we're apparently more interested in discussing it to
> >> death without putting in the effort to demonstrate the feasibility
> >> through bare minimum integration.
> > 
> > What's making it difficult is that Rust is still a "moving goal".
> > No standards yet. So we have some more time until it settles.
>  >
> 
> That doesn't stop anyone from doing the basic xtoolchain integration.

I don't object to introduce basic xtoolchain integration itself, as
there are governmental pressures to introduce (use) memory-safe
languages.
But it shouldn't be limited for Rust. Other candidates of memory-safe
language to be introduced are proposed (including on forums) such as
Swift, Go, Ada, and so on.


> >> It's not very encouraging for future work in the area between that and
> >> also that the request made months ago for something tangible to point at
> >> to discuss further was answered by exactly one person who's already
> >> terribly busy.  It's great that he's trying to make time, but you
> >> would've thought from these threads that *someone*, *anyone* would have
> >> made time with all of this demonstrated passion if they really cared
> >> enough to push it forward.
> > 
> > Unfortunately, right, maybe.
> > But the direction Shawn noted for his PoC seems becoming better than
> > the start of these brainstorming.
> > 
> > 
> >> We've been able to use C++ in base in a safer fashion for years and that
> >> simply has not happened, so one has to question the interest in
> >> alternatives.
> > 
> > Yes, C++ is already in our base toolchain.
> > But unfortunately, C++ doesn't seem to be treated as memory-safe
> > language. [2] So switching to C++ can cause future (governmental)
> > pressures for rewriting with another language again.
> > 
> > [2]
> > https://www.techrepublic.com/article/white-house-report-memory-safe-programming-languages/
> > 
> > Regards.
> > 
> >>
> >> Thanks,
> >>
> >> Kyle Evans


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>