Post
Topic
Board Development & Technical Discussion
Re: The Lightning Network FAQ
by
n0nce
on 01/09/2021, 12:29:47 UTC
Hey LN friends, I'm a c-lightning user for around half a year now, and I'm seriously debating about switching to lnd instead. What do you guys think is the cleaner solution? And what is the more commonly used implementation here?
I just hate hacked-together solutions and dirty code, since those are precursors of failed projects in 5-10 years time max.
welcome n0nce to the c-lightning users, i am one too. if you mean here in the forum i am not sure, we maybe could make a poll for that at one point, but in general lnd seems to be used a lot more and has also the bigger community it seems
Thanks a lot, ndalliard! A poll would be fun, just to get a general idea Smiley I had the same impression of a larger lnd user base though.

also especially because it seems that everyone is using lnd i went with c-lightning, cause i think it is important to have some diversity. i also see that on developer calls, that the 3 (or 4 if you count the rust implementation) implementations help each other to find bugs and be compliant with the rfcs. i just went with the minority (and not eclair cause that is written in java/scala which sounds bloat to me)
Yep, that's true, I really like how the implementation teams work together, also joined a "Lightning Specification Meeting" once to see how it's like, very interesting. And surely, diversity helps. But to me, right now, c-lightning (unintuitively) seems less clean than lnd. This might change once I try it, so I'll do that as soon as I find the time, while keeping my existing node up for the time being...

However, after a while of using the node and interacting with it, I noticed the plugin interface isn't as clean and bloat-free as I hoped: some plugins require me to install Node JS Roll Eyes Roll Eyes Roll Eyes, they're all written in tons of different languages and often totally unmaintained for years.
because the community / number of developers around c-lightning is much smaller than for lnd, some plugins are rotting away, but i like the fact, that a developer is free to choose his prefered language to write a plugin and is not forced to use go for it. i agree with you, i try to avoid nodejs and i am even hesitant using python in some cases (that might be a little bit extreme on my part)
Yeah, that makes sense, however I would have much preferred all plugins to be in C. I mean that's kind of the reason various implementations exist, imagine the next c-lightning plugin to be coded in Go - that would be quite ironic wouldn't it Grin
I myself like Python quite a lot, but wouldn't write a c-lightning plugin in it for sure. Unfortunately one plugin I needed was only available as a NodeJS implementation and that really sucks, I even have to start it manually after a reboot for example due to node (or I did something wrong, no time for further investigation so far).
Like, let's be honest: NodeJS is more bloat than the whole of lnd, so there's no real point of c-lightning if you need a single node plugin for it.

i stumbled the other day about this github issue for lnd. it seems that lnd doesn't run on 32 bit systems, after the size of the database gets bigger than 1 gb. and the last commenter there mentions that raspbian (used on raspberrypies) is a 32 bit system) - something to keep in mind when you run lightning on a rpi
Oh, that's very good to know! My node is based on a repurposed laptop motherboard, the Pi synched way too slowly for my liking and I had it sitting around.. But keeping it in mind! Since I might instead of replacing my old node, instead deploy a second on a Pi....