Hi,

I use Nim at work in a smallish application whose sole purpose is to fire up 
quickly, start fetching items from a TCP/IP stream and write them down on a 
text file. There will be commands sent from the starting app to this Nim 
program. I used to use Windows named pipes, but now use TCP/IP, for this 
"server" to "client" communication. This program typically runs 5 to 10 
minutes, but can also run for hours and hours. It is in this last scenario 
where there has been a problem of the program crashing. This is due to a GC 
problem where it cannot handle GC:d memory as parameter in the createthread 
call.

Since this seems to be a known issue. Found a thread about it, I think the 
compiler should have refused this. I have spent quite a bit of time hunting 
this down.

The reasons the program is written in Nim are the following: 1) support for 
actor model, i.e., threads and channels, 2) python-like but still compiled, 3) 
the resulting file is self contained and easy to deploy. When the first version 
of the program was written several years ago, the actor model was sold quite 
heavily. Now it seems other buzzwordish features are sold instead, like async 
things. It seems it would be good to finish things before starting new 
developments. I'm actually regretting using Nim for this program. It would have 
been better to use C++ or C#, since the compilers and libraries are much more 
robust and mature.

Reply via email to