<xet7>
Hmm, trying to figure out how to add Gujarati language to Wekan...
koo6 has joined #sandstorm
<kentonv>
apparently, fibers are no longer supported in Node 16. We (and Meteor) have quite a rewrite ahead of us. :(
<ocdtrekkie>
oh wow
<Corbin>
That's a lot of fun.
koo6 has quit [Ping timeout: 240 seconds]
<isd>
Oof.
<isd>
...This is one of those things that a type system would make actually kindof easy, if tedious -- we mostly just need to swap out calls to fibers with async/await, but then also bubble it up to anything that uses that, transitively. As it is, I'm much more worried about introducing bugs.
<isd>
IIRC a while back I looked at maybe weaning ourselves off of fibers, and I think the fact that the DB query API is blocking was what deterred me from getting started. I should look a bit more to see if there is an async variant of it.
<xet7>
kentonv: how big effort is it? what is included in doing it?
<isd>
unrelaedly, kentonv, what distro were you using when running the tests? I want to see if I can reproduce your lack of failure.
<kentonv>
xet7, everyplace where you do a Mongo query on the server side today, you're going to have to add `await` in front of it, which means you have to make the function async, which means you have to add `await` wherever it is called, which means you have to make those functions async, and so on
<kentonv>
it may ultimately be fairly mechanical, but without type-safety, it'll be annoying to find everything that needs to change
<isd>
Can you actually do that with the current mongo API? the docs make it sound like things like forEach are just blocking, period. I don't see promises in the API anywhere...
<isd>
(presumably, if meteor itself moves away from fibers, it will have to introduce a non-blocking API if there isn't one already...)
<kentonv>
yeah I don't know what Meteor's plan is exactly, but they mentioned they will be moving away from fibers since Node is
<kentonv>
I'm not sure if they have added new async/await APIs yet or if that's still coming
<isd>
Where was the announcement on their end? I'd like to attempt to engage/dig in more to understand their plans.
<kentonv>
I would *assume* the plan is that Meteor will begin offering parallel async versions of all their API calls, then ask apps to transition to them, then remove the sync versions when they upgrade to Node 16.