5 ms·

Status dev here (i.e. colleague with the benchmarker) and prolific high-performance Nim libraries author. Note that Nim standard library focuses on maintenanc

Status dev here (i.e. colleague with the benchmarker) and prolific high-performance Nim libraries author. Note that Nim standard library focuses on maintenance cost as the Nim team is small. When raw performance is needed, Nim gives us the tools to reach for it. For instance at Status we use our own json serialization/deserialization library: https://github.com/status-im/nim-serialization https://github.com/status-im/nim-serialization and even Araq, Nim language creator, has his own JSON library: https://github.com/Araq/packedjson https://github.com/Araq/packedjson This allows Nim to be in the top10 of json parsing in TechEmpower: http://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json http://www.techempower.com/benchmarks/#section=data-r18&hw=p... Disclaimer: Status is the main sponsor behind Nim https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://our.status.im/status-partners-with-the-team-behind-t... / https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html https://nim-lang.org/blog/2018/08/07/nim-partners-with-statu... Status is committed to Nim but we do have a pretty diverse stack (i.e. most of our code is in Clojurescript and we have part of the codebase in Go that we are migrating to Nim at the moment) and teams work very independently from each other, so other teams are sharing back their experiences with Nim.

modernerd 7y ago
Have you written about why you're migrating from Go to Nim?
- mratsim 7y ago
  We did cover part of it here: https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://our.status.im/status-partners-with-the-team-behind-t... But to give more detailed explanations: - We are a blockchain company and close partner with the Ethereum Foundation. Ethereum research is done in Python, using Nim allows to quickly transcribe research to fast code. - We focus on resource-restricted devices; for now mobile phone but running a blockchain node on a router might make sense in the future as well, so we need tight control over memory allocation. - We can reuse C and C++ tooling (Valgrind, LLVM Sanitizers, gdb, lldb) - The biggest bottleneck we have (and all Ethereum clients have) is cryptography, using Nim means being able to reuse cryptographic libraries written in C or C++ or even using C++ templates with one of the easiest FFI or rolling our own implementation. - WASM is going to be very important for blockchain development and the most important thing is generated codesize (because it lives forever in the blockchain), Go and Rust struggles with WASM codesize at the moment. Nim is very good at that: https://www.youtube.com/watch?v=QtsCwRjtbrQ https://www.youtube.com/watch?v=QtsCwRjtbrQ - Being the main sponsor of a language means also being able to shape it suitable for our needs from scratch. So this was why we started using Nim in the first place. The Nim team was started 2 years ago and the experiment is successful. For example, our Ethereum client was kickstarted by translating python to Nim with an automated tool: https://github.com/metacraft-labs/py2nim https://github.com/metacraft-labs/py2nim. Our main go codebase is supporting our own fork of the major Etehreum client go-ethereum. But this is costly for us as upstream and our teams have different goals. Now that the Nim Ethereum client is more mature, moving completely to Nim with a homegrown clients will allow us to have better API, better logging, controlled release cycles and avoid the cost of syncing with upstream.
  - steveklabnik 7y ago
    The smallest wasm binary produced by rustc is ~110 bytes, Rust struggles with this far, far less than Go, or any language that has a significant runtime. This doesn’t mean that the rest of your reasons are invalid, of course.
    - RX14 7y ago
      Hopefully wasm's gc proposals will be implemented and get LLVM support, allowing languages like Crystal to sanely support wasm.
  - Icathian 7y ago
    The linked py2nim github is basically empty, though some forks of it show substantial content. Was this project intentionally pulled down?
    - alehander42 7y ago
      https://github.com/metacraft-labs/py2nim_deprecated/ https://github.com/metacraft-labs/py2nim_deprecated/ sorry, the other repo is part of github.com/metacraft-labs/languist/ now: a more expanded tool which also tries to support ruby etc : (however its also on pause for now) https://metacraft-labs.github.io/fast-rubocop/ruby-kaigi-2019/ https://metacraft-labs.github.io/fast-rubocop/ruby-kaigi-201... to be honest: the py2nim original tool was used for some initial transpiling experiments, but i am not sure how much of it ended in the actual codebase, the tech surely has more potential if developed
dom96 7y ago
> This allows Nim to be in the top10 of json parsing in TechEmpower: http://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json http://www.techempower.com/benchmarks/#section=data-r18&hw=p... Maybe I'm misreading but to me this implies that the TechEmpower JSON benchmark doesn't use the `json` module. Just to be clear that is not the case, it uses the `json` module. Parsing performance is not benchmarked there, just serialization.
deleted 7y ago
[deleted]
Scarbutt 7y ago
How has the experience of working with Clojurescript been?
- mratsim 7y ago
  Apparently it's fantastic so Clojurescript is here to stay, the future stack will probably be Clojurescript in the frontend and Nim in the backend. See our Clojure repos: https://github.com/status-im?utf8=%E2%9C%93&q=&type=&language=clojure https://github.com/status-im?utf8=%E2%9C%93&q=&type=&languag...

modernerd 7y ago

Have you written about why you're migrating from Go to Nim?

mratsim 7y ago
We did cover part of it here: https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim/ https://our.status.im/status-partners-with-the-team-behind-t... But to give more detailed explanations: - We are a blockchain company and close partner with the Ethereum Foundation. Ethereum research is done in Python, using Nim allows to quickly transcribe research to fast code. - We focus on resource-restricted devices; for now mobile phone but running a blockchain node on a router might make sense in the future as well, so we need tight control over memory allocation. - We can reuse C and C++ tooling (Valgrind, LLVM Sanitizers, gdb, lldb) - The biggest bottleneck we have (and all Ethereum clients have) is cryptography, using Nim means being able to reuse cryptographic libraries written in C or C++ or even using C++ templates with one of the easiest FFI or rolling our own implementation. - WASM is going to be very important for blockchain development and the most important thing is generated codesize (because it lives forever in the blockchain), Go and Rust struggles with WASM codesize at the moment. Nim is very good at that: https://www.youtube.com/watch?v=QtsCwRjtbrQ https://www.youtube.com/watch?v=QtsCwRjtbrQ - Being the main sponsor of a language means also being able to shape it suitable for our needs from scratch. So this was why we started using Nim in the first place. The Nim team was started 2 years ago and the experiment is successful. For example, our Ethereum client was kickstarted by translating python to Nim with an automated tool: https://github.com/metacraft-labs/py2nim https://github.com/metacraft-labs/py2nim. Our main go codebase is supporting our own fork of the major Etehreum client go-ethereum. But this is costly for us as upstream and our teams have different goals. Now that the Nim Ethereum client is more mature, moving completely to Nim with a homegrown clients will allow us to have better API, better logging, controlled release cycles and avoid the cost of syncing with upstream.
- steveklabnik 7y ago
  The smallest wasm binary produced by rustc is ~110 bytes, Rust struggles with this far, far less than Go, or any language that has a significant runtime. This doesn’t mean that the rest of your reasons are invalid, of course.
  - RX14 7y ago
    Hopefully wasm's gc proposals will be implemented and get LLVM support, allowing languages like Crystal to sanely support wasm.
- Icathian 7y ago
  The linked py2nim github is basically empty, though some forks of it show substantial content. Was this project intentionally pulled down?
  - alehander42 7y ago
    https://github.com/metacraft-labs/py2nim_deprecated/ https://github.com/metacraft-labs/py2nim_deprecated/ sorry, the other repo is part of github.com/metacraft-labs/languist/ now: a more expanded tool which also tries to support ruby etc : (however its also on pause for now) https://metacraft-labs.github.io/fast-rubocop/ruby-kaigi-2019/ https://metacraft-labs.github.io/fast-rubocop/ruby-kaigi-201... to be honest: the py2nim original tool was used for some initial transpiling experiments, but i am not sure how much of it ended in the actual codebase, the tech surely has more potential if developed

dom96 7y ago

> This allows Nim to be in the top10 of json parsing in TechEmpower: http://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json http://www.techempower.com/benchmarks/#section=data-r18&hw=p... Maybe I'm misreading but to me this implies that the TechEmpower JSON benchmark doesn't use the `json` module. Just to be clear that is not the case, it uses the `json` module. Parsing performance is not benchmarked there, just serialization.

deleted 7y ago

[deleted]

Scarbutt 7y ago

How has the experience of working with Clojurescript been?

mratsim 7y ago
Apparently it's fantastic so Clojurescript is here to stay, the future stack will probably be Clojurescript in the frontend and Nim in the backend. See our Clojure repos: https://github.com/status-im?utf8=%E2%9C%93&q=&type=&language=clojure https://github.com/status-im?utf8=%E2%9C%93&q=&type=&languag...