You are viewing a single comment's thread:

RE: hive-nectar v0.1.3 - The "green" edition

This is the first time I've noticed this project. I'll soon be looking at your repo to see if there is anything to learn from it. I'm interested to learn what made you choose to fork BEEM rather than starting from scratch or from something less bloated and a bit more suitable for integrated usage like lihghive.

When diving back into HIVE python code (I wrote the asyncsteem lib back in the early days) I looked at my old (Python 2) code, BEEM and lighthive, and after dismissing BEEM I gave lighthive a long thought and try before ending up starting from scratch myself. My own efforts are less general purpose ( aiohivebot ), and delayed because my main project (that I aim to incorporate) is about piggybagging (and eventualy integrating) hash based signatures, so quite a long way from usable, also because I'm not adding signing untill I can complete my stack and add both eliptic curve and hash based signatures at the same time.

So basicly my old python 2 code was too outdated (it was pure python 2, used twisted and used unthrottled communication with the nodes), beem was too synchonous, too bloated, using virtualy zero runtime python features that could make the codebase much leaner and massive the TDD focus felt just too much like an overengineered school project for what I felt should be a lean and mean lib. Lighthive was very good, with some async code under the hood, but my ideas about redundant multi-API-node async design just were too far from @emrebeyler's vission to try and fit it in.

I personaly considered BEEM a deadend road, lighthive a good general purpose replacement, and my own effort (eventualy) a specialized alternative for bots and L2 solutions unsuitable for commandline tools.

I would be interested to learn why you chose to fork from beem and not @emrebeyler's lighthive?

0.00021889 BEE
1 comments

The reason it was chosen is I've been using in since way back in the Steem days, and a lot of our stuff was already using it. So I just found it easier to fix issues as they came up and make it work for me.

Now, I do plan on going over every piece of it, possibly rewriting entire parts, but I got used the way beem was laid out. In the end I will make it my own thing, and I may end up stripping much of it out.

I guess I was just comfortable with it, and wanted something that was 1:1 with how I got used to doing things. But I am no where near done tinkering.

RE: lighthive - It's not bad, but I have used it very little.

RE: starting from scratch - I actually do want to do something like that, but I think I'm going to aim for a Golang library instead (or possibly Rust if I can ever get used to it).

0.00000127 BEE