Live data from Hacker News

Viewing profile — sorentwo

sorentwo

HN member
Joined
Thu, Apr 19, 2012, 2:05 AM UTC
HN karma
1,167
Public activity
314 items

About sorentwo

Creator and maintainer of Oban, the robust background job processor for Elixir

https://oban.pro

Recent public activity

  1. comment
    Comment #49114728

    They certainly do, and I don't think it's a controversial take at this point. Shameless link to an older article about throughput with Oban ( https://oban.pro/articles/one-million-…

  2. story
  3. comment
    Comment #48330682

    As a library maintainer, skill and taste are almost equally important. If I can’t recognize inefficiencies, difficult to maintain code, or generally unpleasant code smells, then pe…

  4. comment
    Comment #48313824

    The efforts we've undergone to make Oban (and Pro) work with CRDB have been ridiculous. Feature detection all over because of a lack of common operators and functions that can't be…

  5. story
  6. comment
    Comment #47464989

    The moment that OpenCode, after helping fix a Dockerfile issue, decided it was time to deploy to prod without asking for consent , I was out.

  7. story
  8. story
  9. comment
    Comment #47017350

    Nearly this, but using ghostty instead of tmux. You don’t get the remote connection aspect of tmux, but for splitting/zooming/preserving windows it is fantastic. The best part is y…

  10. comment
    Comment #46803679

    There is one for elixir that is _mostly_ compatible with oban-py. Full compatibility, and potentially native hosting, are goals before 1.0 https://github.com/oban-bg/oban_web

  11. comment
    Comment #46801257

    With a typical Redis or RabbitMQ backed durable queue you’re not guaranteed to get the job back at all after an unexpected shutdown. That quote is also a little incorrect—producer …

  12. comment
    Comment #46801204

    You can have jobs that run as long as you like. The difference is purely in how quickly they are restored after a crash or a shutdown that doesn’t wait long enough.

  13. comment
    Comment #46800840

    This is absolutely true (except we went OSS + Web initially, Pro came later). You were an inspiration, always helpful in discussion, and definitely paved the way for this business …

  14. comment
    Comment #46800516

    > The vast, vast majority of Python libraries are not async-friendly and most still rely on the GIL. On the other hand, Celery has absolutely no asyncio support at all, which sets …

  15. comment
    Comment #46800443

    Transactions around fetching/updating aren't trivial, that's true. However, the work that you're doing _is_ regular activity because it's part of your application logic. That's dat…

  16. comment
    Comment #46800294

    There are other projects that implement the ideas in OSS, but that's the same in Elixir. Not that we necessarily invented DAGs/workflows, but our durable implementation on the Elix…

  17. comment
    Comment #46800010

    > It supports workflows, rate limiting, unique jobs, bulk operations, transactional enqueuing, etc. Why not move these things to the OSS version to be competitive with existing opt…

  18. comment
    Comment #46743243

    > Oban has been a lifesaver for me and it is the tool I miss the most from the Elixir ecosystem when doing work in Python That's wonderful to hear! Hopefully you can make use of Ob…

  19. story
  20. comment
    Comment #46704832

    Pleased to see this posted! A lot of design time and effort behind this project (something we'll be speaking about this year). Happy to answer any questions people may have.

  21. comment
    Comment #46492080

    Seconded. I was going to say the exact same thing. Brilliant thought exercise that I still think about on a weekly basis 20 years later.

  22. comment
    Comment #46488168

    Before looking at the zoo I figured there would be a dozen or so engines compared. Seeing the actual comparison is astounding! The amount of work just to aggregate and compare is a…

  23. story
  24. story
  25. comment
    Comment #45645991

    It is an old US military term that means “F*ked Up Beyond All Recognition”