
Nimbus, An Ethereum 2.0 Sharding Client - jonnyz
https://our.status.im/introducing-nimbus-an/
======
treeform
Nim is great. To me it feels like typed python that is fast.

It also runs everywhere. I use its C mode on the server, its js mode on the
website, and even its c++ mode to interface with c++ libraries such as
steamworks which are hard to interface with.

Nim is also pretty cool by offering templates and macros. Which allow you to
make some awesome DSLs that make your code short and sweet. Just don't go too
crazy!

I used to really hate typing in C or Java because it felt so boring. I stayed
away from typed languages for a long time, but nim has won me back. Types have
saved me many times now!

Its also super fast, I mostly programmed in JS/Python and I never knew how
fast computers can be.

~~~
erikpukinskis
I have avoided typed languages too, mostly because I’ve been web focused and
it’s just rare in that space.

But from what I’ve tracked probably 5-10% of my coding errors are type errors,
and I do a fair amount of ad hoc type checking (if !arg.expectedAttribute
throw new Error(“the second arg to blahFunc should have expectedAttribute”)).

There’s definitely a clear cost there, which feels like it outweighs the
mundanity of typing.

However, I have come to believe transpiling is the devil, and many-languages
syndrome is very counterproductive, so I stick to js, since it’s the only
serious candidate for a “One Language” language.

~~~
arc776
Mundane typing? Typing is awesome! Haven't you ever wondered what a parameter
actually is in say, Python, and have to track back through callers to work out
what the parameter is expected to contain? Completely solved by specifying
type.

Nim has really good type inference, so the 'mundane' aspect I _guess_ you're
referring to isn't there.

    
    
      let
        myStr = "Hello"
        myInt = 12
        myFloat = 1.2
      var myHashTable = newTable[string, int]()
    

The need for checking types at runtime is of course completely eliminated in
typed languages so you get that for free. Nim also offers an extension to this
with distinct types.

    
    
      type
        Euros = distinct float   # NB: Don't use float for currency
        Dollars = distinct float
      let
        a = 10.Dollars
        b = 10.Euros
        c = a + b  # Compile time error
        d = a + 1  # Compile time error
    
      proc dollars(e: Euros): Dollars =
        let exchangeRate = 1.117
        result = (e.float * exchangeRate).Dollars
    
      proc euros(d: Dollars): Euros =
        let exchangeRate = 0.858
        result = (d.float * exchangeRate).Euros
    
      let
        e = a.euros
        f = b.dollars
    
      echo e.float  # 8.58
      echo f.float  # 11.17
    

> I have come to believe transpiling is the devil and many-languages syndrome
> is very counterproductive

Why do you believe this? In Nim the language creates an AST and it's this that
is output in various forms. The underlying representation is the same, but it
allows many targets. Similar to LLVM (which is also a Nim target, if
unofficially), it's one of the reasons why it can compile on almost every
platform, and why it is a good choice for the low resource devices that
projects like Nimbus target.

It also means you can write servers and clients in the same language but
target C and JavaScript, respectively.

~~~
erikpukinskis
> > I have come to believe transpiling is the devil and many-languages
> syndrome is very counterproductive

> Why do you believe this?

In isolation it’s fine.

But when I look at the complete toolchains required to maintain “modern”
applications it’s not ok.

There are too many different languages in a single application, too many
declarative configuration surfaces, too many chained pipes.

I grew up in a time where you wrote code, compiled and ran. We are overdue for
a major collapse of how deep tooling is tolerable for a simple roundtrip
source change.

If you’re a pro developer (and I assume you are) then you can ignore this. You
can afford to spend 40 hours debugging your toolchain, teaching through 5
different languages and configuration environments to locate a problem.

But tolerable isn’t good enough for me. Frankly, I’m tired of spending my time
slogging though DSL after DSL and runtime after runtime. I miss just code.

I believe we are overdue for a resurgence of native languages that can be
written just as pure compiled or intetpreted code without a stockade of
bizarre executables propping them up.

------
cslarson
This is ecosystem. Status is a project that was funded as an Ethereum ICO. To
support their existing work they're incentivised to help support core
development of Ethereum itself. Love it.

------
sremani
[https://nim-lang.org/features.html](https://nim-lang.org/features.html)

Crypto has become an interesting play-ground to test out esoteric languages,
which is a good thing esp. in a world where we are close to end of moore's
law.

------
losvedir
Can someone explain sharding here as it relates to ethereum? I've often
thought the goals of ethereum about putting all the world's data in a
blockchain weren't technically feasible, but maybe if there was a sharding
mechanism it could be.

Also, what exactly are the capabilities of the client here. They mention
running on mobile devices... surely that's not actually doing any _mining_ is
it?

~~~
thunderbird120
The idea behind sharding is to essentially parallelize the blockchain by
splitting the one big chain into many smaller chains which can communicate
with each other asynchronously. This is a really difficult problem for
countless reasons but if they can get it working it offers a lot of very
important benefits. It can process orders of magnitude more transactions than
a conventional blockchain without the loss of decentralization seen in schemes
using dPoS such as Steem, light clients get to be much lighter while still
maintaining high security, and smart contracts which live on an individual
shard and do not require cross shard communication are massively more
efficient and can operate at a far lower cost than smart contracts currently
can. The last issue is probably the most important for Ethereum specifically
because currently most smart contracts simply cost too much to operate
limiting their usefulness. Much lower operating costs greatly expands their
realistic use cases. If you'd like a detailed writeup I'd recommend reading
the Sharding FAQ [https://github.com/ethereum/wiki/wiki/Sharding-
FAQs](https://github.com/ethereum/wiki/wiki/Sharding-FAQs)

------
perturbation
I'm excited to see a high-profile project like this in Nim :)

Any challenges with getting Nim on mobile? Do you compile to objective-C for
iOS devices?

~~~
mratsim
For now, we are still in research phase so we compile to C then machine code
on our dev desktops.

In the future we will probably stay with C or use C++ (for zero cost
exceptions).

We might not need Objective-C because the UI/UX part is taken care of by
Status React[1] which is written in ClojureScript (and it's currently using Go
as an Ethereum/Web3 backend).

The options to compile to Objective-C or JS are still there and that is very
nice.

[1]: [https://github.com/status-im/status-react](https://github.com/status-
im/status-react)

