Re: The Case for Rust (in the base system)

On 1/31/2024 16:31, Wojciech Puchar wrote:
>
> On Wed, 31 Jan 2024, David Chisnall wrote:
>
>> On 31 Jan 2024, at 15:07, Tomoaki AOKI <junchoon@dec.sakura.ne.jp> 
>> wrote:
>>>
>>> First of all, NO MEMORY-SAFE language can write codes using volatile
>>> memory objects, most notably, memory-mapped I/O and/or DMA driver.
>>
>> The first half of that is obvious nonsense.  Memory-mapped I/O is not 
>> intrinsically unsafe, from a memory-safety perspective. Even Java has 
>> volatile objects and Sun Labs used Java for device drivers twenty 
>> years ago.  Having a memory-safe interface for MMIO is helpful.
> This line above is complete nonsense. as most of that discussion.
>
> ......
>
I've read most of this thread thus far and have a few observations.  
Mind you this is coming from a 60 year old who was programming in 
assembler before I had a driver's license and has run FreeBSD both 
personally and professionally all the way back to the mid 1990s when 
MCSNet ran on it both on our back end and in customer-facing use.  I'll 
try to keep this somewhat-brief as I'm not really interested in a catfight.

Languages come and go in popularity.  Some concepts endure, but 
implementations often not-so-much.  Sometimes decisions made a long time 
ago wind up locking you up "almost forever"; witness Android as an 
example.  Sometimes much less-consequential decisions (e.g. to use 
something from packages) bites you; Digital Ocean, for example, no 
longer "supports" FreeBSD at all. They used to up to FreeBSD 11. Why no 
longer? Maybe (can't be proved) because they used "jq" to parse the 
cloud config files, that's a package, their cloud init script /forgot 
/to put the "REQUIRE" for "ldconfig" in there to make sure adding local 
libraries was run first /and thus on an upgrade to a newer version if 
rcorder spat things out differently it could try to run the cloud init 
before the linker knew where the shared libraries were and thus break 
all networking, appearing to be entirely dead. /It took me 30 seconds to 
find this and eight bytes of inserted text to fix it, I reported it back 
to DO but.... they haven't changed their mind on forward support.  Sad 
too because their infrastructure works really well with FreeBSD (in fact 
my blog has been on it for several years now and still is on 13.2p8)

The idea of having a language at compile time cover for foolish mistakes 
or lack of attention sounds good but as we have all seen with various 
data breaches whenever you think you've made something idiot-proof 
Murphy comes up with a better idiot.  I'm not much of a fan of the 
premise that with more-rapid development of working code one also gets 
both correct and more-efficient code, and again I post up Android (which 
I do write app code for) as a counter-example.

Bringing a language into base IMHO ought to be very carefully considered 
/as removing it might be impossible down the road and ultimately FreeBSD 
could pay horribly for that. /This is especially true when the language 
itself isn't simply a language; it also means that in practical use it 
has a huge number of other outside resources (e.g. containers or 
whatever) particularly when they're not static and might have 
compilation issues down the road.  I personally hate coding for Android 
(although I do it) because its essentially required to use their IDE to 
be productive at all and it changes out from under you whenever Google 
decides to deprecate or change something; do we really want to bring 
that sort of situation into FreeBSD?  In addition I've been bit several 
times by the "floating dependency" thing with with php over the years -- 
php itself is of course a package but there are /other /packages that 
use it as a language and a huge number of modules that are brought in to 
handle various things from xml parsing to database connectivity. Several 
times over the years I've upgraded php using "pkg upgrade" and 
immediately had one or more packages that allegedly should be 
forward-compatible break with missing dependencies that weren't 
originally there and thus "pkg" had no knowledge of them.  These are the 
risks you accept when using a "language + other things" model in all 
respects; it can happen with code linked against openssl, for example 
(e.g. Postgres was a recent one built from source that required a bit of 
effort to resolve as I build that in a production environment I'm 
responsible for from source.)

I would argue that this risk in a core component should not be accepted 
without a showing of extraordinary benefit in the context of improvement 
of some element that the core system includes now, and even then only if 
the container problem can be resolved in a way that will not wind up 
screwing the ability to build -- including a retrospective release -- on 
an indefinite basis down the road.  That is, if you can't (for example) 
check out 14.x five years from now /and build it from source /then its 
not acceptable, which implies that whatever containerized assets are 
required they must also be in said tree and versioned in same without 
having to be pulled from an external source (which may have changed such 
that backward compatibility to build has been lost.)  This could get 
into more than just a technical question if there are potential 
licensing issues with those "must have to build" assets as well.

My 2 bits of contribution; carry on.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/