[Rpm-ecosystem] DNF team would like to take over libdnf ownership

Panu Matilainen 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 mailing list