This is the sort of response I wanted to write but did not have time to,
so thank you for punching it out. I agree wholeheartedly. Don't burn
people for trying new things and playing with code and languages and
such. At the same time, acknowledge that what's being made is a toy, an
experiment, a thing to enjoy playing with but not to be taken too
seriously as a replacement program for its parent. Let them have their fun!
Let's all be excellent to each other. A rising tide lifts all boats.
- Jody Bruchon
On 11/16/2019 7:01 AM, Laurent Bercot wrote:
The busybox mailing-list has managed, for the most part, to stay clear
of language flamewars during all these years.
Of course, blips happen now and then. A few years ago, the fashionable
language was Go, so inevitably, someone wrote "Gobox", because of course
they did. For the most part, we nodded, and moved on. Gobox is still a
thing somewhere; obviously it hasn't replaced busybox.
It was just as inevitable that someone would come up with a busybox
equivalent in Rust. The most surprising thing about it is that it took
so much time: Rust is already old news by today's standards.
Please just acknowledge and move on. Let rustybox be a thing. Don't let
the thread devolve into a n+1th avatar of the "Rust vs. C" discussion,
which can be found about anywhere on the Web (and that you can basically
spark anywhere) if that's what you like.
The reason why these takes don't stick has nothing (or very little) to
do with the intrinsic value of alternative languages vs. C. The reason is
purely operational.
The main advantage of busybox compared to, say, GNU coreutils, is the
ease of deployment. It's easy to build (you need a C toolchain and make,
no other dependencies), it's easy to cross-build, it's easy to deploy
(a single binary you can copy), it's easy to make a static executable,
it's easy to bootstrap a rootfs from scratch when you have busybox.
Those aspects are important in the embedded world, where busybox shines;
the development cycle for a product that includes busybox can be *a lot*
shorter than what it is with coreutils, and that's why it's used.
(The thriftier RAM use is a nice point too, but clearly not the main
reason nowadays.)
Alternative approaches to busybox forfeit that advantage. Neither Go,
nor Rust, nor anything else, comes anywhere close to C when it's about
ease of deployment, and especially ease of bootstrapping. And that's
really on the implementation of those languages, where ease of
deployment,
and especially ease of bootstrapping, has clearly not being seen as a
design goal. It's a choice that has been made; there were certainly very
good reasons for that choice; but an effect of that choice is that, no
matter how "good" the language is, it is unsuitable for software such as
busybox.
It's not on the language design, it's not on "whether it can replace C
or not" (it cannot, but not for language reasons). And it's not on the
OP,
who wanted to perform an experiment. The experiment has value, even if
the result isn't something we would use. So, thanks OP, and please don't
take it personally if the general reaction isn't what you wanted to see.
--
Laurent
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
