It is nice with a lot of innovation now in the ahead-of-time compiled languages camp.
What worries me is the fragmentation, and the fact that no one language seems to check all of the (subjective set of) boxes for a general purpose high-speed, ahead-of-time compiled language [0].
E.g, Crystal seems to be the only one supporting a modern concurrency story (similar to Go), but has a huge problem with compile times.
Nim looks nice in many respects, but last I checked, they don't have anything like Go-like concurrency. Maybe not on everyone's wishlist, but as the world move toward flow everything/everywhere[1], I personally find this to be a problem.
Thanks! This is interesting, although I'd be worried about how stable this is for the long term. Would be happy to have my worries annihilated of course :)
It depends how good/low level a programmer you are, but it's really not that hard to spin up your own impl. I did an (incomplete) Python multiprocessing like dealio in like 100 lines of code (https://github.com/c-blake/cligen/blob/master/cligen/procpoo...) just to make my `only.nim` run faster because libmagic/file are so CPU intensive. So, one way to annihilate your worries is to just roll your own.
What worries me is the fragmentation, and the fact that no one language seems to check all of the (subjective set of) boxes for a general purpose high-speed, ahead-of-time compiled language [0].
E.g, Crystal seems to be the only one supporting a modern concurrency story (similar to Go), but has a huge problem with compile times.
Nim looks nice in many respects, but last I checked, they don't have anything like Go-like concurrency. Maybe not on everyone's wishlist, but as the world move toward flow everything/everywhere[1], I personally find this to be a problem.
[0] https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...
[1] https://www.amazon.com/Flow-Architectures-Streaming-Event-Dr...