[Rpm-ecosystem] DNF team would like to take over libdnf ownership
pmatilai at redhat.com
Mon Oct 30 14:11:21 UTC 2017
On 10/30/2017 03:21 PM, Colin Walters wrote:
> On Mon, Oct 30, 2017, at 09:15 AM, Neal Gompa wrote:
>> As much as I like Rust, it's hampered more by LLVM than anything else.
>> I struggle to see the advantage of writing in Rust. Not to mention
>> that the learning curve is quite high compared to other languages. I'd
>> be more likely to suggest D than Rust.
> While D supports GC-less programming, the whole ecosystem is
> bifurcated by that (that said this is based on what I've read
> and I'm not a D expert). And if we're keeping DNF in Python, then
> having two GC's in the same process isn't going to work.
> (Actually, *are* we keeping DNF in Python?)
That's what I'm wondering too. If most of the thing is written in
language X, then why drag the Python elephant in for ... a cli interface?
Don't get me wrong, I like Python a lot, but I'm not sure it's the best
language for implementing a depsolver, or a frontend to one. And keeping
it all in one language would also make debugging and developing easier +
saner and probably faster too because with the multi-language setting
you're always first writing the thing itself, then bindings for it, and
then the actual code to use the thing, and then you discover the
interface wasn't quite what you wanted so back to drawing board. And of
course trimming down the dependencies also cuts down the footprint on
rescue-images, the number of the things that can go wrong etc.
/me never understood why we're doing depsolvers in Python
- Panu -
More information about the Rpm-ecosystem