A package manager shouldn’t be written in C
eugeneia opened this issue · comments
A package manager shouldn’t be written in C. Besides the security implications, using C means lots and lots of tedious work. Meanwhile, the performance benefits of using C are questionable. C11 atomics? For parallelized dependency resolution? Maybe I am missing something, but I don’t see where a package manager needs a lot of number crunching in general, and the requirement for low level synchronization constructs seem a bit far fetched for the level of concurrency to be expected.
Have you thought about languages that are higher level than C with better implementation quality than Python? There is a lot to choose from.
I would recommend taking a look at LuaJIT. It implements a tiny, well designed language (Lua, a bliss, I promise!), has an amazingly high performance JIT compiler, and a super convenient FFI so you can easily reuse any C libraries (which you will probably need a bunch of).
This repo hasn't been updated in a long long time as you can see. Since then I've already drawn the same conclusion as you (apart from the security aspect. While C gives you the tools to shoot you in the foot its up to you to use them).
TBH I'm rather more considering Go - with a blackbox package manager and no libraries around it. Then a daemon (from the same codebase) that wraps it and provides all the queuing/atomic stuff you'd want to connect to from a GUI.
Think of it as more of a plan9 approach, completely avoiding an ABI and providing a socket API only, and the package manager being a static binary (or at least linked to sane libs only) so it's immune to it's own update procedure. Thoughts?
IMHO go is the best choice its: fast, stable, safe, and easy to learn.
i think c is a fine language to write a package manager in it, but it seems like a lot more work.
Lua is great but it does not maintain ABI or API compatibility between version like 5.2 and 5.3. LuaJIT does not support 5.3 and the creator of LuaJIT has some thoughts 🙂
and easy to learn.
But I'm the one writing this :P
I think that, so long as people aren't making the package manager for themselves, they shouldn't say too much...
I would put forward another alternative; D. It's based on (and backwards compatible with) C, so you could theoretically plug in all the C you've got now into D, and you can use C libraries. The syntax is very similar to C's, but it allows for any paradigm you want, and it just overall a really nice language.
I might try plugging what you've got right now into the dmd and see what happens...
Tbh I've never used D and I don't really see me ever adopting it. I don't want to use languages
purely because they're not C (I don't subscribe to that school of thought) - I want to look at what
they empower me to do.
Well, D has a lot of features that could be useful. For example, Dynamic arrays and slices, powerful templates, foreach, optional garbage collection, etc. It compiles to C-compatible object code and compiles faster than C.
What are your goals and needs for designing sol?
Sure but I can do foreach, dynamic arrays and slices, RAII, etc, in C using libnica anyway. Garbage collection isn't a winner for me
Closing as an opinion piece as this thread has only served as a place for others to promote their language choices, and in no way serves as contribution to Solus itself