Re: The Case for Rust (in any system)

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).

> 
>>> 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.

> 
>>> 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.

> 
>> 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
>>
> 
>