> Use ARC/ORC.
[amd] 14 Thu Jun 24 10:29:47 |/mnt/sde1/storage/nimbus-eth2|
stefan$ rm -rf nimcache; make -j8 NIMFLAGS="--gc:orc" nimbus_beacon_node
Building: build/nimbus_beacon_node
/mnt/sde1/storage/nimbus-eth2/vendor/nim-metrics/metrics.nim(254, 14)
template/generic instantiation of `withLock` from here
/mnt/sde1/storage/nimbus-eth2/vendor/nim-metrics/metrics.nim(257, 18)
template/generic instantiation of `withLock` from here
/mnt/sde1/storage/nimbus-eth2/vendor/nim-metrics/metrics.nim(258, 11)
Error: undeclared identifier: 'deepCopy'
make: *** [Makefile:311: nimbus_beacon_node] Error 1
Run
> I think the thread-based GC was always buggy
It's the most usable, so far.
> the reference-counted GC is much better in that application
Is it? Reference counting has been known to be suboptimal for decades. This is
the state of the art in the Java world:
<https://en.wikipedia.org/wiki/Garbage-first_collector>
I think we're going in the wrong direction with RC.
> The global threadpool was an architectural mistake
Not necessarily. It makes sense from the point of view of functionality - i.e.:
you want to limit the number of CPU-bound threads in your application, so you
can use your CPU cores efficiently.
> simply prefer <https://github.com/yglukhov/threadpools>
Is it used in production, or am I going to be the first to test it properly?
> Pony
Very young, very small user base, depends on a LLVM fork (that's actually
expected, since all projects relying heavily on LLVM end up forking it) and the
latest version doesn't build on my system because of
<https://github.com/ponylang/ponyc/issues/3708>
> Crystal
Much buggier than Nim
> Swift
Wouldn't touch it with a three metre pole. Apple is the anti-Midas.
> Zig
Too young for production. Also dragged down by the huge LLVM dependency.
> Rust
Too big. I don't want another C++.
> There's really nothing to compete with [Nim].
I know. Maybe we should return to monke^H^H^H^H^H C.
