Quote from: ndalliard on Today at 06:21:22 AM

Quote from: n0nce on August 31, 2021, 10:08:09 PM

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

I had the same impression of a larger lnd user base though.

Quote from: ndalliard on Today at 06:21:22 AM

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...

Quote from: ndalliard on Today at 06:21:22 AM

Quote from: n0nce on August 31, 2021, 10:08:09 PM

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

, 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.

Quote from: ndalliard on Today at 06:21:22 AM

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....