HackerTrans
トップ新着トレンドコメント過去質問紹介求人

darwin67

no profile record

コメント

darwin67
·2 年前·議論
it depends on your load really. there are background job frameworks in other languages like Oban in Elixir that utilizes postgres.

if scale is low, it's not an issue. but once you have high usage, what typically people do is they move it to a separate database, otherwise you're saturating the resources and it starts impacting the application itself.

at that point, that's not much different from external state stored else where.

also another thing about databases is their ACID transactions can only handle up to certain amount of load. again, if you don't hit that limit, it's totally fine. once you do, which usually means outages, severe delays, etc, and it'll be a shit show.

disclaimer: I do work at Inngest, but also this is speaking from experience. :)
darwin67
·2 年前·議論
How are you going to do that over network boundaries? Especially the ones you might have less control over.
darwin67
·2 年前·議論
Which part of BEAM are you talking about? I know some cases can be solved by it already, but not almost every need.

The fairness of the BEAM scheduler is not the same as multi-tenant fairness. I'm aware of lcnt in Erlang that helps with contention, but that will have a hit in throughput like any other locks.

Unless I'm missing something?
darwin67
·3 年前·議論
FYI: there's an Elixir SDK for Inngest as well. Haven't fully announced it yet, but plan to post it in ElixirForum some time soon.

https://github.com/inngest/ex_inngest
darwin67
·3 年前·議論
Thanks for the note, it's changed to underscore now. Regarding the "ex" prefix, it's a common pattern for Elixir libraries. https://github.com/h4cc/awesome-elixir
darwin67
·3 年前·議論
no promises here but I'd love to look into Rust in the future. there're essentially no background job systems for Rust iirc.