Hi there everyone.
Although I'm aware that Nim has a lot of potential for low-level use cases, the reality is that a lot of people work writing high-level software, me being one of them. But usually I don't see those use cases having too much attention in the community.
I've been following the Nim project for a couple of years now and due to my experience in architecture and development of event-driven microservices-based systems and integrations I've been thinking about writing a Nim book about these topics. From simple things on how to use Nim in famous serverless platforms like AWS Lambda, Azure Function App, and GCP Cloud Functions; to examples of Integrations, ETL Pipelines and and Real-Time notification systems in using Nim codebases.
However I'm not really sure how useful and cohesive with the project's direction this book would be, after all, a book about writing a Kernel in Python or writing a backend in C (even if it's interesting) it wouldn't be too useful for realistic use cases.
What are your opinions on this?
Thank you in advance.
"after all, a book about writing a Kernel in Python or writing a backend in C (even if it's interesting) it wouldn't be too useful for realistic use cases."
Are you saying that Nim has no realistic use case in the Cloud? I don't think that is true but above seems to imply it.
I think this is actually one of Nim's great strengths. It's quite ergonomic for writing high level code, and if you need performant code, you still just write Nim. You don't have to write a C module, or Cython, or depend on some other giant ecosystem package for one or two fast functions.
And resources like this are exactly what's missing also. With Nim's smaller community, it can be tough to find guidance or existing packages for any given high level service.
I'd buy your book! : )
I've used Nim at work for processing Excel files; it had been a great experience!
Code modularisation is also super clean in Nim.
Go ahead sir! More power to you!
From simple things on how to use Nim in famous serverless platforms like AWS Lambda, Azure Function App, and GCP Cloud Functions; to examples of Integrations, ETL Pipelines and Real-Time notification systems using Nim codebases.
You could do this, but outside of Status' Chronos async implementation, Nim doesn't have a very good async story, which makes event-driven systems hard. As far as serverless goes, I'd love to see Nim have better out-of-the-box support for WASM because that would allow it to more easily be deployed to platforms like Cloudflare Workers, or any other serverless product that supports WASM with low startup times.
Yeah, yeah, yeah, it wasn't good enough for you so let's pretend your use case is all that matters and so let's delay the book until AI replaced every developer anyway...
What? I was addressing a specific part of the post which tends to depend on async. If anything, it would be prudent to write about Chronos in the book in that case since the language is in production doing networked stuff with async.
Also, I don't think AI will be replacing most developers anytime soon.
Sorry, I missed your message somehow.
To be brief, Nim's stdlib async is slow and allocates a lot of memory. It also includes reference cycles which makes it unfit for use with plain ARC, and it also doesn't play nicely with threads. There are also some difficulties with timers in it. Chronos, which is what Status uses for its Ethereum product, is a fork of the stdlib async with many issues fixed, but last I looked into it, it's mostly only tested on refc. I was briefly involved in a coroutine project lead by the people at NimWorks, which I think is the best way forward, but they decided to go off and fork Nim as their own project called NimSkull and I don't know what the status of that is. The Nim networking libraries in production are either using Chronos (fairly niche outside of Status) or working directly with the underlying selectors interface of the OS, as is the case with httpx/httpbeast and Gildenstern and Mummy.
This isn't to shit on anyone. It's just why microservices and networked applications that use async have few good options and they all exist outside of the stdlib's async/await, which I consider to be unfit for production use.
What? I was addressing a specific part of the post which tends to depend on async.
Mea culpa, I misunderstood you then.
BTW async on Nim devel now works without producing reference cycles.
It's quite ergonomic for writing high level code, and if you need performant code, you still just write Nim
You can't have both. You can't reduce that complexity no matter what you do.
If you want simple high level code, for example - operations on collections - had to use array-like structures. If you want performance - you need to introduce things like iterators, etc. And you can't completely abstract it away. And you need to optimise standard libraries to other way or another, - for performance or for simplicity. Or duplicate each function in STD to work with both (which is also increasing complexity). No matter what you choose, you can't have both. It's not about Nim, it's just not possible (unless some day AI or VM would rewrite the code and replace arrays with iterators on the fly etc.).
Another examples - object/ref (copy on write), destructors, and so on. - You can't hide it, and have both high level simplicity and micro-management control and performance. Choose one, or choose some balance in between, but you won't get both.
You can't have both.
I disagree.
You can't hide it, and have both high level simplicity and micro-management control and performance
Well that's Nim's thing though, it gives you exactly that. Sure, it's not perfect, so with every iteration (Nim 3) we will get closer to this ideal.
Abstractions that collapse down to zero overhead are in reality everywhere: C does that really well for addressing modes, for example. It's completely regular in this aspect and the typical CPU isn't and yet it works so well that you have never read a blog post about it. Same thing about mapping structured control flow to gotos without losing anything. Same thing for parser generators, they can produce code that is indistinguishable from manually written code.
One thing that can be done much better is data structures and how to elide intermediate results via deforestation. That is not "impossible", Haskell does that all the time but the eager languages still need to catch up.
it, it's mostly only tested on refc.
We test chronos with both orc and refc and it works fine with both - that said, orc is not yet usable for larger applications such as ours, ie we still recommend refc that itself is more battle-tested.