Nim partners with Status.im | Hacker News Reader

Nim partners with Status.im

nim-lang.org

174 pointsdom9655 comments

Nim is still the best language I know of in terms of clean code, speed, metaprogramming, FFI, etc.

And I think a sharded and/or light client/browser for Ethereum could actually replace banking and potentially a ton of other applications if it becomes popular. The trick will be all of the competition in terms of clients.

Rather than Dapp browsers I would like to see a lightweight mobile client library and server combo that would allow me to just build a freestanding app. Maybe just a lightweight client rather than an actual node. Or maybe have a way to install the ethereum node server only if it's not already there.

But with when sharding actually comes online I am very hopeful that Ethereum will blow up. So I may buy some more Ether tonight.

I'd wish there was a Rust with Nim syntax, haha.

I suppose something close might be OCAML or Haskell, since they have similar type safety to Rust (whose syntax is loosely based on OCAML from what I understand) but have some nice features that Python and Nim use like list comprehensions and generators, lazy evaluating, etc. But also with Rust macros you can sort of make your own sub-DSL's which add some of those features.

Yes, I know about the ML syntax languages, they are pretty cool, but Rusts unique selling point is the borrow-checker. Getting GC style code without runtime overhead.

This is great news. Nim (and the team working on it) deserves much support and praise.

It is a language that enables C/C++ programmers to be more productive and makes performant programming approachable for beginners as well.

This is great news Dominik. I remember speaking to you guys in your IRC channel a few years ago about Nim, and you all answered my questions and criticisms very professionally, and I really liked the direction you have all taken with Nim. This post is a good reminder to write something fun in it tonight. :)

Way to go team Nim!

I was dabbling in this community almost a year ago before being distracted by work/life, very fun and supportive.

Still enjoy wearing my Nim t-shirt and look forward to returning to some dabbling in the (hopefully near) future.

I've played with Nim, I think it's great and deserves more attention. Especially in the scientific computing and gamedev communities.

It has Python-like terseness, static typing, and simple C interop.

Amazing. Interesting to see programming language teams getting together with web3.0 teams.

Nim is new to me and I'm missing the "why" of it. From the website, I'm getting "we like Python but wanted to compile to native code and JavaScript". Is that fair?

That's why I started using it.

But Nim is much more than just this, it's more like "We like Python, but we also like static typing, efficient and dependency-free programs, super easy C/C++ FFI and metaprogramming. We also like to write all our software in the same programming language so we compile to JavaScript" :)

How is the concurrency story with Nim. I know that this is a repeating question, just wondering how well it works and how safe it is.

I am still eyeballing Pony-lang for it's design choices, but development seems to have slowed down there.

Concurrency is achieved via async await. For parallelism each thread has its own GC so that makes things a lot safer, but sadly less efficient if your algorithm wants to share data between threads a lot (you can copy data between threads). You can also allocate shared memory but that's considered unsafe, this will hopefully be improved in the future.

As for how well this all works, well, I recently implemented a high performance parallel HTTP server [1]. It's currently hosting the Nim Forum[2] and has been doing so for the past few months. Also it's proving very performant[3].

1 - https://github.com/dom96/httpbeast

2 - http://forum.nim-lang.org/

3 - https://www.techempower.com/benchmarks/#section=test&runid=b...

Many thanks for the detailed answer & ref.links.

It would be amazing if Pony Lang's[+] concurrency model could be realized in Nim, or if Nim could be extended as a language to optionally and cleanly support it. That's easier said than done, of course, since Pony's concurrency model is deeply wedded to its type system ("reference capabilities").

[+] https://www.ponylang.org/discover/#what-makes-pony-different

We are still going strong in Pony land. There an ebb and flow to publicly seen development.

The writing style in your documentation is awesome! I haven't come across Pony before but it looks really nice, definitely going to give it a try. :)

This is literally Go, save the fact that it compiles to WA instead of JS.

Go is nowhere near as expressive/high-level as Nim or Python.

The learning curve is significantly steeper.

Except Nim doesn't make you copy/paste constantly.

Or write code gens, haha

> This is literally Go, save the fact that it compiles to WA instead of JS.

Except Nim compiles to C and JS, no official WASM yet (though you can Emscriptenize the C output). Nim has macros, generics, inheritance, exceptions, deterministic GC, and more. Otherwise, yeah, exactly the same.

I was responding to the comment... the things they mentioned are available in Go. You're taking my comment out of context.

It is literally un-go. Great support for meta programming and generics, and actual non-foot gun error handling

It's way nicer than Go (features and syntax) tooling and libs are not as developed obviously.

Go and Nim are as different as it gets in programming language design. Nim is kitchen-sink type language, while Go builds on a small set of well-defined features. It's the difference between Scheme and Common Lisp, or JavaScript and Python - the look&feel of programming in Nim is unlike Go in almost all respects, aside from perhaps quick compilation.

Nim isn't a kitchen sink language. It is a language that has been designed to be small at its core but extremely extensible through macros.

Yes, and from what I see it worked, so the number of useful extensions became large over the years. I don't mean "kitchen-sink" in any pejorative sense, maybe "batteries included" would be the better word here.

> super easy C/C++ FFI

There's a HUGE difference between a C FFI and a C++ FFI. I doubt that Nim makes the latter easy (name mangling, exceptions, STL, ...).

You're very right to doubt me. But it does make it easy, Nim compiles to C/C++/Objective C (exceptions are mapped to C++ exceptions in C++ mode). This gives it the ability to wrap all C++ libraries, Nim takes advantage of this to make wrapping easy, here is a (very) barebones wrapper for sfml as an example: https://github.com/dom96/nim-in-action-code/blob/master/Chap...

Thanks for the link, I stand corrected! :)

That seems about right. Another big benefit of this is performace. Nim is a lot faster than python.

"A performant but garbage collected language with nice syntax that compiles to C. Plus hygienic macros."

More or less - easy and intuitive like Python (or better), fast almost like C.

I would say Nim is far less intuitive than Python, and it’s better to only iteratively refactor occasional subsets of your code for heavy performance, and not presume you need all parts to have C-like speed (you don’t).

This is why I think choosing to begin a project in Nim (or C++), is a form of drastic premature optimization, compared with Python and iterative usage of Cython.

> not presume you need all parts to have C-like speed (you don’t).

Why not? If you can, if it's easy, not error-prone, you feel comfortable with it? Performance gain is something every user will appreciate.

I think that’s a false question. The point is that it’s actually not easy, not even in Nim (in fact, especially not in Nim).

Writing safe and effective Python is easy. So then where do you go from there for the ~10% of the codebase where a user could conceivably ever care at all about performance enhancements? Wholesale switching to a different language is quite a drastic (premature) decision in such case, whereas Cython gives you the same (actually even better) facilities for type safety and detailed performance optimization, and offers it crucially on a case by case basis.

I see a lot of cheering for Nim on this front. It makes me happy that some people enjoy Nim and like to use it. Cool! But it makes me sad to see the significantly wrong-headed discussions about it as a practical alternative to Python + Cython. It’s the opposite: choosing Nim is a wildly impractical way to get what Python + Cython does better.

That's exactly what many said about Go. It was largely disproven since then.

You can integrate Nim code into your Python codebase just as readily as any other compiled language, including Cython. Cython produces shared libraries conforming to Python C-API, and you can do the same in Nim.

Having very similar, but different in surprising ways, language for extensions may be actually more of a problem then what developer familiarity might buy you. Instead of a mish-mash of two languages like Cython, using a proper language with its specific set of abstractions might be better, depending on a use case.

I would like to know what you consider the "better facilities" for type safety and performance optimizations Cython has that Nim lacks?

> “You can integrate Nim code into your Python codebase just as readily as any other compiled language, including Cython. Cython produces shared libraries conforming to Python C-API, and you can do the same in Nim.”

You can’t integrate as easily as with Cython at all (for instance any Python file is immediately already a valid Cython file). To boot, you don’t have to generate Python C-API code with Cython, you can just produce pure C shared object files and interactvwith it via cffi or ctypes if you want, or even just write an entire program in C with Cython and not have any CPython execution model anywhere in it.

The bigger benefit though is that you can target optimizations to specific subsets of code by creating both the CPython api for them and the underlying C implementation in one place, with just one kind of syntax.

> “Having very similar, but different in surprising ways, language for extensions may be actually more of a problem then what developer familiarity might buy you.”

I don’t understand this. Cython is a superset of Python. It’s not “different in surprising ways” because if you write Python it’s literally not different.

It has extra features you optionally can use, but that’s in no sense “different in surprising ways.” If a feature surprised you, it would be because you did not understand its usage, and not because it was a tricky, different way to achieve the same effect as something in pure Python (because to do that, you’d just write Python).

In terms of “better facilities” I am hesitant to engage because it seems like your mind is made up that e.g. Cython is “mish mash” and I highly doubt you would genuinely consider the significant design flaws of Nim (and in general I hate how religious about Nim these discussions always seem to be on HN), but one particular issue is the nasty Sum Type syntax in Nim with a companion enum for value constructors. Compared with fused types in Cython (which auto-generate the whole multiple dispatch apparatus and don’t need pattern matching), I’d prefer taking Cython as a way to make performant and polymorphic type safe code in Python any day.

very cool. hopefully you guys take off. i love python for being productive but static typing and easier distribution (compiling down to binary) are killer features for a language with similar semantics/expressiveness.

Is there a transpiling / migration story for a python code base into Nim? I briefly looked at Nuitka to get to a dependency free binary from python but this could be another approach.

Just use Cython in that case.

There is some experimental stuff, py2nim for example: https://github.com/metacraft-labs/py2nim

That’s awesome, congratulations Nim team!

Awesome!

So nobody is going to comment on why Status.im even exists? 100m dollars for an "open source mobile dApp browser" and messaging system, when dApp browsers are dime a dozen, open source, and pretty good!

Trust Wallet any one? Toshi?

Hopefully all those bucks can be used to propel development of other things, like with Nim and a real sharding ecosystem.

I know a lot about Nim, not nearly as much about crypto / Status, but their blog does reveal quite a bit of information about what they're trying to accomplish.

The two wallets you mention are not running an ethereum like client on the phone and are therefore depending on third parties to get access to the ethereum network.

Running a node on a phone sounds like a horrible idea. Why would this be desirable?

This is a solved problem and I never understand why people keep going back to it. Host a node or use a public node. Use a local wallet to do signing and depend on the public node for RPC calls. The vast majority of users and clients do not need to be dealing with Ethereum nodes on their own devices, they just need good key management systems.

It's desirable for a couple reasons. Firstly, the node enables whisper, which is a p2p messaging protocol. You can't do p2p messaging with a public node, and nearly zero users will host their own nodes.

Also, public nodes can be DOSed or otherwise taken down. They can invisibly filter the requests they receive. Some jurisdictions could have the nodes completely blocked.

The point here is to build a fully p2p system, so running an on-device node is an attempt to do that. That doesn't mean that public nodes can't also still exist.

Care to elaborate on how they intend to accomplish this?

This seems to have predictable limitations, and the last people I talked to a month ago said it killed their batteries. Surpriseeeeeeeee or not really?

That's part of the motivation for developing a new Ethereum client, in Nim. The theory is that the executables produced can be more readily tuned according to various device profiles, e.g. desktop clients, mobile clients, beefy server clients, and so on.

i had to lol at this comment.

So you think Apple and Google don't count as a "third party"? What will happen when they kick them off the app store? How else will they communicate through push notification WITHOUT going through FCM or APNS?

The whole premise is completely flawed and naive if they're trying to build a truly "decentralized browser". The only way to make something truly decentralized on mobile is if you have the capacity to build your own phone and distribute it to wide audience. Otherwise you are relying on "3rd parties" like Apple and Google. In fact YOU are the "3rd party" that can be always cut off from users.

They raised at the peak of the 2017 ico frenzy. Now they are funding open source projects for lack of anything better to do with the money. Not a bad outcome. Right time, right marketing strategy. Their app is not yet in the App Store today.

IIRC they raised around 200 million at the time. It would be nice if they throw some money at Clojure/script too , because they depend on it heavily.

Reply on news.ycombinator.com