Why not migrate Portage to C language?

[Goverp]

Oh, come now, surely it's time for a Rust emerge.

[dmpogo]

Oh, come now, surely it's time for a Rust emerge.

I was just coming to say that as long as it is not Rust ...

[pun_guin]

I'm positive Lisp will survive Rust.

[fpemud]

The portage command itself is only a frontend and doesn't need to be written in C.
The core logic should reside in a well-designed library, or a set of libraries where each implements a specific subfunction. This core could be developed in C.
This architecture naturally allows for multiple frontends (with the portage command itself being one) to be developed in any language.

[pjp]

Common Lisp can outperform C

Is there anything meaningful written about that? I'm genuinely interested. Or is it "under certain workloads" or limited things no one does? :)

[flexibeast]

Common Lisp can outperform C

Is there anything meaningful written about that? I'm genuinely interested. Or is it "under certain workloads" or limited things no one does?

The following is in some sense "perform comparably to" rather than "outperform", but Tim Bradshaw has just written a blog post ("The lost cause of the Lisp machines") which in passing says:

The most important thing is that we have good stock-hardware Lisp compilers today. As an example, today’s CL compilers are not far from CLANG/LLVM for floating-point code. I tested SBCL and LispWorks: it would be interesting to know how many times more work has gone into LLVM than them for such a relatively small improvement. I can’t imagine a world where these two CL compilers would not be at least comparable to LLVM if similar effort was spent on them.

and in a footnote to that says:

If anyone has good knowledge of Arm64 (specifically Apple M1) assembler and performance, and the patience to pore over a couple of assembler listings and work out performance differences, please get in touch. I have written most of a document exploring the difference in performance, but I lost the will to live at the point where it came down to understanding just what details made the LLVM code faster. All the compilers seem to do a good job of the actual float code, but perhaps things like array access or loop overhead are a little slower in Lisp. The difference between SBCL & LLVM is a factor of under 1.2.

[pa4wdh]

Oh, come now, surely it's time for a Rust emerge.

That would sure make me start searching for a different distro ... i mean, the command emerge rust is already bad enough, but emerge written in rust is just hell on earth in my opinion .

Nice joke: The feature to remove rust in Gentoo is actually called WD-40 : https://wiki.gentoo.org/wiki/WD-40

[NeddySeagoon]

pa4wdh,

I've been doing it wrong all these years!
I use an angle grinder, MiG welder and sheet steel. :)

[pun_guin]

Is there anything meaningful written about that? I'm genuinely interested. Or is it "under certain workloads" or limited things no one does?

As Debian's benchmarkgame seems to have been erased from the net, most meaningful things are code examples:
https://stackoverflow.com/questions/349 ... ler%20flag.

TL;DR: You can compile both C and Lisp with and without optimisations. (Chances are that Lisp's optimisations are more portable though, given that SBCL compiles to bytecode.)

[pa4wdh]

pa4wdh,

I've been doing it wrong all these years!
I use an angle grinder, MiG welder and sheet steel.

This makes me curious to see what those tools can do with an evil piece of software
... on the other hand, we can always just print it's source code and we'll be quite sure about what they can do

[Banana]

Splitted a discussion into introducing grpm since it diverged from the OP.

[sam_]

Oh, come now, surely it's time for a Rust emerge.

Enter pkgcraft: https://wiki.gentoo.org/wiki/Pkgcraft