Speaking from my user experience with nim (~1 yr), you don't have to worry
about the stability of async related things, they are quite robust.
The things that is not very mature is the GC. I am not talking about the arc
one, but the current default one refc. I have a single threaded project
> Not really. What you can achieve is something similar to what I created with
> httpbeast: each thread running its own Async event loop and allowing the
> system to load balance the socket connections. For clients that will likely
> be trickier.
This _event-loop per thread_ is only required
I didn't use ARC because when I started evaluating multithreading options (July
2019) and implementing Weave (November 2019) it was not ready at all.
Now at the moment, I'm ready to run my batteries of tests on arc:
> Read mratsim's post from the same thread then,
> [https://forum.nim-lang.org/t/6352#39200](https://forum.nim-lang.org/t/6352#39200)
@mratsim shows no examples of what ARC can do, but I assume that ARC can help
with the third scenario that he describes...
> You need a shared state, for
Adding to that
[https://github.com/nim-lang/Nim/issues/14429](https://github.com/nim-lang/Nim/issues/14429)
:)
> I may very well be missing something, ...
Read mratsim's post from the same thread then,
[https://forum.nim-lang.org/t/6352#39200](https://forum.nim-lang.org/t/6352#39200)
> I have limited experience with nim mobile apps. But knowing what I know don't
> think I would use async on the client. Async is great if you are doing tons
> of http style requests. But really a mobile client? Just regular threads are
> probably better if you are just writing and reading from
All this talk of `--gc:arc` makes me a little bit frustrated, I feel like
@andrea has a similar reaction. The fact is that I have so far seen no evidence
that `--gc:arc` makes mixing concurrency and parallelism in Nim easier (I may
very well be missing something, so please educate me with
I've tried to summarize the state of Nim's concurrency and parallelism in this
blog post:
[https://onlinetechinfo.com/concurrency-and-parallelism-in-nim/](https://onlinetechinfo.com/concurrency-and-parallelism-in-nim/).
Some of it was based on this discussion.
Regarding multithreading it really depends on your workload but here are 2
kinds of code architectures that would allow mixing async on threads:
1\. If the part of your code that you want threaded is stateless and only
allows the following types to crossover threads:
* plain old
> which GC is the default
The _\--gc:refc_ (deferred reference counting/heap per thread) is the default
right now. The _\--gc:arc_ (immediate reference counting/shared heap) or
_\--gc:orc_ (immediate reference counting/shared heap + cycle detector) is set
to replace it.
The _async_ stuff
> how does your C++ architecture share data between threads?
Carefully ;-) The Actor library doesn't restrict what parameters you can pass,
but by convention we're careful to limit it to primitives, pass-by-copy objects
(like std::string), immutable ref-counted objects, and Actor references. Or
> Again, I'm considering porting a large existing project, not writing
> something from scratch. I already know the requirements and the architecture.
> Nim is different from C++ but that doesn't mean I'm going to change the
> design to single-threaded. I definitely need multiple threads
> Threads are just kind of hard to use with gc:refc, that is why gc:arc is
> getting worked on.
I'm still confused as to which GC is the default. I thought it was ARC, but
what I'm reading recently makes it sound like ARC isn't quite stable enough yet.
> Just regular threads are probably
> Could you explain why not?
Current current gc:refc does not allow refs object to be passed between threads
willy nilly. Async creates a reactor ref object per thread. So you can't really
share the async corutines between threads. Threads are just kind of hard to use
with gc:refc, that is why
Are you using Jester or another web framework?
> it requires an introduction that explains to users what ARC is, how to make
> use of it
+1 The existing documentation is **great** (I’ve read the tutorial, manual,
and “Nim In Action” cover to cover), but in some areas seems to lag behind.
Which is understandable since the language is
> Async does not mesh well with threds.
Could you explain why not? My understanding is that it’s thread-agnostic; an
unfinished async call is just a sort of lightweight continuation that can be
restarted in any context.
> Multiprocessing is more scalable anyways.
This project is a library for
> for new projects I wouldn't use anything else because the tooling is so much
> better
That would be great, but it requires an introduction that explains to users
what ARC is, how to make use of it, how it impacts multithreading, the new sync
and lent parameters, how to design collections and
> At this point I'm unclear on how much of this stuff is solid and
> enabled-by-default (in particular, what's the difference between "arc" and
> "orc"?)
ARC is in version 1.2 with significant stability improvements around the corner
in 1.2.2. Many Nimble packages already work with `--gc:arc`.
Parallelism/concurrency and async are some of the few pain points of the
language. ARC/ORC together with
[https://github.com/mratsim/weave](https://github.com/mratsim/weave) might be
very promising.
I use async/await in production, but only server side on Linux. It's pretty
mature for a simple web application. My app runs on multiple servers instead of
threds. Async does not mesh well with threds. Multiprocessing is more scalable
anyways.
ORC is ARC with a cycle collector to deal with cycles (and collect them so they
won't leak)
Right after posting that (how often this happens!) I came across [the big ARC
thread](https://forum.nim-lang.org/t/5734) here from last December. It sounds
like ARC means a lot of (positive) changes to the things I've read earlier,
like:
> The heap is now shared as it's done in C++, C#, Rust,
The project for which I'm evaluating Nim does a lot of concurrent network I/O
(over WebSockets) and database access. It needs to run on most mainstream
platforms (iOS, Android, Mac, Windows, Linux.) The current implementation is in
C++17, using a homemade Actor library. The other language I'm
25 matches
Mail list logo
