<FromGitter>
<stronny> you don't need lua for that
<FromGitter>
<j8r> I know HAProxy, but that's not only that
<FromGitter>
<j8r> it's a OAuth proxy
<FromGitter>
<dscottboggs_gitlab> but.... @stronny .... haproxy isn't *_written in Crysal_*
<FromGitter>
<j8r> I will launch the project, and will optimize this later - I think this would be a good optimization
<FromGitter>
<stronny> joking aside I would be very careful with production daemons in Crystal
<FromGitter>
<stronny> in my opinion the language is ill suited for this usecase
<FromGitter>
<j8r> production daemons?
<FromGitter>
<dscottboggs_gitlab> what makes you say that?
<FromGitter>
<stronny> first and foremost broken concurrency
<FromGitter>
<j8r> broken? I let `HTTP::Server` handler this
<FromGitter>
<stronny> good luck debugging then
<FromGitter>
<dscottboggs_gitlab> yeah Idk what the advantage is of shipping a super broken and honestly unsound concurrency implementation over just not having it and occasionally using `fork` when you need it
<FromGitter>
<stronny> I'm not talking preview_mt, that's a separate can of worms
_ht has quit [Quit: _ht]
<FromGitter>
<dscottboggs_gitlab> (I'm basing this off the blog post that came out when the concurrency release happened like 3 versions ago so feel free to tell me I'm wrong)
<FromGitter>
<dscottboggs_gitlab> oh?
<FromGitter>
<stronny> I'm talking harebrained half cooked CSP just because G O L A N G
<FromGitter>
<j8r> I'll see, that's a simple project with no money involved - for now
<FromGitter>
<j8r> golang is also kind of broken too, not thread safe - as I know
<FromGitter>
<stronny> nevermind threads
<FromGitter>
<stronny> you can't control fibers
<FromGitter>
<dscottboggs_gitlab> are you referring to the `select` macros or...?
tdc has quit [Ping timeout: 260 seconds]
<FromGitter>
<stronny> select is not enough
<FromGitter>
<dscottboggs_gitlab> like what's so half-cooked about crystal's CSP?
<FromGitter>
<j8r> have you an example @stronny ?
<FromGitter>
<stronny> yes I do
<FromGitter>
<stronny> basically you need something like a `kill` to work with async events
<FromGitter>
<stronny> you also need a parent-child structure and a way to control the spawn-exit events
<FromGitter>
<stronny> vanilla Crystal does not have this
<FromGitter>
<stronny> no amount of channels will help, that's my conclusion
<FromGitter>
<j8r> Anyway, I doubt it will be a big deal for me
<FromGitter>
<stronny> hey, don't let me stop you. I'm just sharing my thoughts, not a universal thruth
<FromGitter>
<stronny> it's a mess, so you would need to make an effort to sort through =)
<FromGitter>
<stronny> I would be glad to comment though
<FromGitter>
<dscottboggs_gitlab> looking through the examples....
<FromGitter>
<stronny> tcp-latency is the meaningful one
<FromGitter>
<stronny> others may not even work
<FromGitter>
<dscottboggs_gitlab> I'm sorry dude I'm too tired to get this right now. I'll take another look tomorrow.
<FromGitter>
<stronny> yeah, it's complex
ur5us has quit [Ping timeout: 240 seconds]
<FromGitter>
<stronny> basically it offers some hints along those lines: ⏎ ⏎ 1) no shared state: a job exists only in a fiber's stack by default ⏎ 2) trap/kill-like event processing ⏎ 3) parent-child relationships and wait-like behaviours [https://gitter.im/crystal-lang/crystal?at=5e6d59119f25f2238b8138f1]