Re: Time to stabilize the ecosystem

[mratsim]

> It's a bit unsettling that a lot of pkgs do not work with ARC at all. And 
> these are very essential things like parsers,db drivers etc.

ARC is new while the old GCs had years to mature.

That said, the main use-case for ARC beyond embedded, multithreading, doesn't 
work because of a regression in exception handling + Arc but fixes are in 
progress:

  * 
[https://github.com/nim-lang/Nim/issues/13983](https://github.com/nim-lang/Nim/issues/13983)
 (arc + threadpool.spawn, closed)
  * 
[https://github.com/nim-lang/Nim/issues/13935](https://github.com/nim-lang/Nim/issues/13935)
 (arc + createThread in loop + exception handling, WIP)
  * 
[https://github.com/nim-lang/Nim/issues/13936](https://github.com/nim-lang/Nim/issues/13936)
 (arc + one-way channel, WIP)

Re: Time to stabilize the ecosystem

[Yardanico]

Yes it's in the process AFAIK

Re: Time to stabilize the ecosystem

[Aiesha_Nazarothi]

Will you also backport threadpool lib for --gc:arc ? Was my main reason to 
avoid using it.

Re: Time to stabilize the ecosystem

[Araq]

For me it's certain and I want all the projects to work with ARC. ;-)

Re: Time to stabilize the ecosystem

[dom96]

> Memory management seems to be going in the right direction but I fear "ARC" 
> needlessly fractured the small community

A lot of implication here that ARC is going to be the new default. While this 
_may_ happen, it's far from certain, and even if it does it won't be until Nim 
2.0. So there is no ecosystem split here, unless you desperately need ARC for 
something.

Re: Time to stabilize the ecosystem

[dom96]

> 3\. I'd argue that Jester (and it's underlying httpbeast) are mostly 
> production-ready

Yeah. You're all using it right now through this forum, been running in prod 
for years.

Re: Time to stabilize the ecosystem

[Yardanico]

3\. I'd argue that Jester (and it's underlying httpbeast) are mostly 
production-ready

Re: Time to stabilize the ecosystem

[Araq]

1\. As I said elsewhere for now `--gc:arc` is the new `--gc:none` for embedded 
development, better interop with C/C++ and memory footprint. The split is 
unfortunate but it unavoidable and we're backporting `deepcopy`, for example, 
so the situation is improving.

2\. Well they don't, we ensure they keep compiling and running.

3\. Debatable. We have a httpserver in the stdlib and also several as external 
packages.

4\. That's what we did, see 
[https://nim-lang.org/docs/manual_experimental.html](https://nim-lang.org/docs/manual_experimental.html)

Time to stabilize the ecosystem

[gattomatto]

First of all thank you for all the hard work guys. Much appreciated.

I think Nim reaching 1.0 set many people's expectations very high and now it's 
time to consider how can the Nim ecosystem thrive.

Topic 1

Memory management seems to be going in the right direction but I fear "ARC" 
needlessly fractured the small community. It's a bit unsettling that a lot of 
pkgs do not work with ARC at all. And these are very essential things like 
parsers,db drivers etc.

eg 
[https://github.com/nim-lang/Nim/issues/14020](https://github.com/nim-lang/Nim/issues/14020)
 parsers relying on deep copy 
[https://github.com/nim-lang/Nim/issues/13997](https://github.com/nim-lang/Nim/issues/13997)

Topic 2

Important packages is a very good approach but it needs to be expanded. 
Important packages simply cannot break with every other release of Nim.

Topic 3

Missing / abandoned important packages. At the moment Nim does not really have 
a usable,production ready, http server package. I know it's hard I cant do it 
myself and therefore rely on others. This is I think important to get done.

Topic 4

This is maybe non technical but features that do not really "work" or are not 
really "maintained" should be marked as "experimental" or with some visible 
warning.