@alexeypetrushin I just don't get the push to bring OOP to Nim. Nim doesn't need constructors - you can easily initialize instances of user defined types, and if there's too much verbosity there you can eliminate it via metaprogramming.
Every time I see someone try to code in Nim using object oriented principles, their code ends up being an order of magnitude more complex and more verbose than without. It also usually has poorer performance characteristics than if one were to have written the program procedurally. > What about object construction requires some dedicated construct to handle > it? Just initialize the instance or create a ref and initialize the instance > it points to. Essentially what you get out of the box with Nim, is designated initializers. You could of course remove the designation and have argument position dependent initialization. You could also write a macro to do something similar to what C does in regards to the usage of compound literals for struct initialization. If someone has only ever coded in object oriented languages, maybe they're more dependent on this concept of a constructor, but I have yet to feel like I really need one. @GordonBGood \- there have been issues with thread pool, parallel and spawn for years. I'm not sure what shape these modules are in now... In my experience with Nim, all of these new features and abstractions around concurrency, never really end up paying off. They're either too poorly documented to grok, or they have significant edge cases they can't solve for. Being able to move isolated subgraphs between threads is great, but can't we already do this with move semantics? Allocations on a shared heap, pointers, and synchronization primitives are the best way I've found to address this style of programming in Nim. Maybe the new iteration of channels will synergize well with the existing thread pool implementation, and will offer a safer, easier to implement alternative. I'm not surprised you were able to achieve similar performance to running green threads over a thread pool (and passing messages between them). Context switching is the power in green threads, and their ability to be paused and resumed on different system threads. I'm making some assumptions here, but if one is simply running coroutines over a thread pool without any kind of cooperative multitasking, you're probably just fighting contention issues and the performance characteristics of your implementation will be poor.
