nimbus-eth1 VS Unchained

It certainly seems it will be remembered as a major success story for open p2p protocols on the global Internet of our time.

A great multitude of developers and enthusiasts belonging or contributing to diverse teams spread across the world: developing, debating, and collaborating for years to arrive at the big event.

And it's all been done very much in the public view:

https://weekinethereumnews.com/

https://hackmd.io/@benjaminion/eth2_news

https://github.com/ethereum/pm

https://www.youtube.com/c/EthereumFoundation/videos

Consensus Clients:

https://github.com/sigp/lighthouse#readme

https://github.com/ChainSafe/lodestar#readme

https://github.com/status-im/nimbus-eth2#readme

https://github.com/prysmaticlabs/prysm#readme

https://github.com/ConsenSys/teku#readme

Execution Clients:

https://github.com/akula-bft/akula#readme

https://github.com/hyperledger/besu#readme

https://github.com/ledgerwatch/erigon#readme

https://github.com/ethereum/go-ethereum#readme

https://github.com/NethermindEth/nethermind#readme

https://github.com/status-im/nimbus-eth1#readme

https://github.com/status-im/nimbus-eth1 (yes, this is also for eth2, see "About" at top right)

I expect we will see a "merged" client in the future. Nimbus could be the closest of anyone to this vision (nimbus-eth1, nimbus-eth2). Not sure when this will happen though. Anyways, you have to remember -- these are two extremely complicated pieces of software. Just the interface between the two has been developed and tests over the last 18 months. I think there will always need to be serious encapsulation of logic for it to be maintainable.

Anything with a finite (200 is small even) number of units misses the algebraic structure of the problem mentioned in https://news.ycombinator.com/item?id=36988497 wherein multiplying|dividing two things gives you a (potentially) new unit which implies an open ended "space" of units.

To be concrete (hah!), in C++ a template meta-type with 12 signed integer parameters (6 numerators & 6 denominators for rational exponents of SI base units) might be one way to model it.

Unlike C++ template stuff, Nim macros (like Lisp macros) makes metaprogramming more like procedural programming - just against abstract syntax trees. I think that helps to shield some of this type complexity from users, but the documentation README https://github.com/SciNim/Unchained does better job than I can in an HN comment.

Of course, for unit system conversion, the number of dimensions (6 in SI, 3 in CGS/Gaussian) changes. So, for full generality you need compile-time (if you want static type integration/CT errors) linear algebra over a rational field (at least & conventionally) to project|inverse project. That might be theoretically possible in C++. I would think it very un-fun and unlikely to ever have been done. There's probably a Mathematica package, though.

I've recently written a units library for Nim [0]. It's still WIP, but it's already proven extremely useful for me as a physicist.

Thanks to Nim's strong type system and metaprogramming features, it allows for a fully compile time design, without any runtime overhead (in form of special unit objects or such things; everything is a `distinct float`).

In addition Nim's unicode support, the code even looks nice!

A more complex use case (I can link more if desired): [1]

[0]: https://github.com/SciNim/Unchained/

[1]: https://github.com/SciNim/Unchained/tree/master/examples