<FromGitter>
<moe:busyloop.net> i don't get the hype either. i can see how the safety is mighty useful for certain apps. but for >90% of my apps i really don't want to manually manage my memory or think about "borrows".
<FromGitter>
<moe:busyloop.net> in the same way that i don't want every second line to read `if err`. it just makes it hard to see what the code actually does...
<FromGitter>
<wwalker> crystal seems to be the best of all the worlds. Only if you need true parallelism does crystal seem to fall short. I've used it (`-Dpreview_mt`) with crystal, successfully, but most of the parallel CPU execution was being eaten by "system" so they must be making crazy amounts of context switching. I found it was actually better to just use 1 normal, single threaded process, than to use `mt`. That was back
<FromGitter>
... on 1.6.2, I've not retried it with 1.7.x yet.
<FromGitter>
<Blacksmoke16> My understanding it's best suited to IO versus CPU bottlenecks
straight-shoota has quit [Ping timeout: 252 seconds]
straight-shoota has joined #crystal-lang
<FromGitter>
<wwalker> yep, I use fibers for blocking IO stuff, and they work great. currently I have a few severely CPU bound processes, so I have a controller (lots of Fibers) spawning separate crystal processes to handle the CPU intensive stuff. the combination is working very close to 100% usage of all the CPUs with very little lost to "system"
alexherbo2 has joined #crystal-lang
_ht has joined #crystal-lang
jmdaemon has quit [Ping timeout: 255 seconds]
<FromGitter>
<moe:busyloop.net> yup, MT is hard when you don't bake it into the language from version 0
<FromGitter>
<moe:busyloop.net> but in most cases i'd still rather go multiprocess instead of moving an entire project to go or rust just for that. baby vs bathwater
alexherbo2 has quit [Remote host closed the connection]
<FromGitter>
<ober> especially M:N
<FromGitter>
<mjblack> It didnt work for me but I was able to get WinDbg to work