Subnostr

golang bitcoin dev available for work!

been working with the btcd/btcwallet codebase since 2018 ( https://github.com/p9c/p9 ), and most recently developing the indra network protocol ( https://github.com/indra-labs/indra ).

i am very experienced with elliptic curves, hash functions, forward error correction, network handlers, scheduling, difficulty adjustment, deterministic execution, concurrency, CLI interfaces, gRPC/Protobuf, libp2p, IPv4 multicast over UDP, binary and ASCII encoding systems.

currently working on a nostr signing CLI/library ( https://github.com/mleku/signr ) which included taking the btcd/btcec elliptic curve package and consolidating the stuff they use from decred (btcd has decred code included in it, for schnorr signatures!) in https://github.com/mleku/ec which anyone can use to avoid pulling down the whole btcd codebase and importing decred's elliptic curve package.

willing to work with Rust codebases but more likely to make a persuasive argument that you should not use Rust because rust is spook funded mozilla trash, and the Go libraries needed are far more mature and battle tested.

Reply to this note

Please Login to reply.

Discussion

jonathan 2y ago

What would be interesting for you to work on next?

gsovereignty 2y ago

Also have a look at Zig vs Rust

mleku 2y ago

Zig? what is Zig?

I've done a little with rust, wrote some microservices gRPC/protobuf stuff. threading is lame in rust, feels like a straight-jacket after goroutines and channels.

mleku 2y ago

https://github.com/ziglang/zig

there is also V.

but seriously! there's so much more reusable tooling and instrumentation for go, and it's the only language with coroutines and fifo queues as first class syntactic elements.

most programming languages are not built with simplicity as a key value, and go's got enough years behind it that you can depend on it, and unlike almost every other language, it's still possible to pick up ten year old code and use it, almost without any extra effort required.

you can't say that about any ANY other language. with Ken Thompson in the leadership it's got the best pedigree of any language too.

gsovereignty 2y ago

Yeah V is pretty good too.

Go is my daily driver. I love it. I don't use anything else unless there's a reason. A bit opinionated wrt package management but that seems to be improving.

But I do find it annoying that I can't easily reason about stack/heap allocation etc. I would really like it if Go had the option of immutability and borrowing.

We are missing the perfect language.

mleku 2y ago

i dunno about immutability. i mean, i find it problematic that strings are by force in this way locked, since passwords come in this way there's some sanitation issues with that. and there is gonna be some adding of overhead with MMU having a huge map of immutables, and in general, the whole reason to have immutability is to avoid race conditions, and i'm very strict about atomics and mutexes on any shared data.

i'd rather remove immutability from strings and a simple static analysis could reveal what data needs to be mutex protected.

i'd also rewrite the entire 'fmt' library to work with an alias of []byte types and the 'strings' library too, so it's all built to be mutable.

the stack/heap allocation stuff can literally be avoided with GOGC set to zero. you just have to probably write a bunch of libraries that do your memory handling for you. a lot of unsafe stuff could easily be done with freelists managing blobs, it would require an allocation manager.

it would certainly be cool if you could drop in alternative runtime back ends in place of the default one. and if possible, make these blobs shared libraries so they can not be repeated in every binary.

imo, the whole shennanigans with generics was such a waste of time making changes to the language that have really borne minimal benefits. the two issues you name are far more important to broadening the use cases, flexibility and efficiency of the language.

as for avoiding big allocations and stuff, i am always considering this in how i write my code. i tend to do a lot of explicit variable declaration and try to move them explicitly outside of loops since the compiler could miss that and be running allocations pointlessly when a pointer can be reused easily and the GC can easily identify when a big long list of pointers need to be freed up.

things like network handlers, it's pretty easy to just make one collection of buffers and always reuse them so GC doesn't touch them.

good to know you are also a go maxi :) too many wishy washy people with fondness for following what is 'cool', not even considering for a minute that cool is not necessarily practical or secure, or efficient.