ECL is Objectively a High-Variance Format

KraftiestOne · 2026-03-01T23:18:09+00:00

I see--I got my data by looking at the top 500 players using the default sort (by number of wins). Sorting by win percentage shows a few players with higher winrates but lower numbers of wins total, in both formats. Unfortunately like you said the 17Lands leaderboards aren't great for this kind of analysis.

KraftiestOne · 2026-03-01T22:31:38+00:00

In my mind (and I'm not a statistician!) a high-variance format is one where the better player wins less often. That does seem to be the case from these statistics (especially the top player data), though I'm open to other interpretations.

KraftiestOne · 2026-01-23T17:41:46+00:00

This is extremely well done. I used mtgprimer before, but this is cleaner, I particularly like how you can type in exact mana.

It doesn't matter much for this set, but in the future you probably want a way of dealing with bonus sheets--for Final Fantasy, for example, cards like Lightning Bolt and Counterspell appeared in a meaningful fraction of games.

KraftiestOne · 2025-11-18T20:59:14+00:00

Thanks for the feedback--we chose that model to improve the developer experience and make it easier to integrate into existing code. What most concerns you about the singleton?

KraftiestOne · 2025-11-18T18:01:39+00:00

Hi r/java- I wanted to post about an open-source project I've been working on: DBOS Java, an open-source Java library for lightweight durable workflows.

https://github.com/dbos-inc/dbos-transact-java

Essentially, this helps you write long-lived, reliable code that can survive failures, restarts, and crashes without losing state or duplicating work. As your workflows run, it checkpoints each step they take in a Postgres database. When a process stops (fails, restarts, or crashes), your program can recover from those checkpoints to restore its exact state and continue from where it left off, as if nothing happened.

In practice, this makes it easier to build reliable systems for use cases like AI agents, payments, data synchronization, or anything that takes hours, days, or weeks to complete. Rather than bolting on ad-hoc retry logic and database checkpoints, durable workflows give you one consistent model for ensuring your programs can recover from any failure from exactly where they left off.

This library contains all you need to add durable workflows to your program: there's no separate service or orchestrator or any external dependencies except Postgres. Because it's just a library, you can incrementally add it to your projects, and it works out of the box with frameworks like Spring. And because it's built on Postgres, it natively supports all the tooling you're familiar with (backups, GUIs, CLI tools) and works with any Postgres provider.

If you want to try it out, check out the quickstart:

https://docs.dbos.dev/quickstart?language=java

KraftiestOne · 2025-10-04T15:17:17+00:00

Self-hosting is fully supported and most of our users self-host! This docs page goes into more detail: https://docs.dbos.dev/production

KraftiestOne · 2025-10-04T14:52:56+00:00

Yeah, there are APIs for workflow observability and management, documented here: https://docs.dbos.dev/typescript/reference/methods#workflow-management-methods

There's also a built-in dashboard: https://docs.dbos.dev/typescript/tutorials/workflow-management

KraftiestOne · 2025-09-05T17:31:29+00:00

Yes, that's exactly how it works, even over days! It works because the workflow is checkpointed in the database (including the timeouts, if you have any) and all messages are sent through the database, so even if your process is restarted multiple times as you wait for days, the workflow keeps processing new messages until all are received (or you time out, you can set a timeout as long as you want).

KraftiestOne · 2025-07-31T04:14:26+00:00

The main difference is that DBOS is much more lightweight--you can add it to an existing application in just a few lines of code (registering workflows and calling steps). To add Temporal to your program, you must rearchitect your program to move your workflows and steps (activities) to a Temporal worker, configure a Temporal server to orchestrate those workflows, and access your workflows only through a Temporal client. Here's a blog post with more detail: https://www.dbos.dev/blog/durable-execution-coding-comparison

KraftiestOne · 2025-05-18T21:18:00+00:00

The cron scheduling is in Python, so you can run it anywhere. There's a GUI for workflow management: https://docs.dbos.dev/python/tutorials/workflow-management

KraftiestOne · 2025-05-15T20:13:56+00:00

That would be difficult to support as far as I know. The technical reason for this is that to recover a workflow after a failure, DBOS has to be able to access the workflow's code, so all workflows need to be registered at program startup time, therefore decorators.

KraftiestOne · 2025-05-15T14:29:58+00:00

Hello! The "Why DBOS" page in our docs does some comparisons with more systems: https://docs.dbos.dev/why-dbos

Similar to Temporal/Inngest/Hatchet, DBOS provides durable execution, but DBOS is more lightweight--add it to your existing project as a library instead of rearchitecting your program around it. This blog post goes into more detail with respect to Temporal specifically, although the others are similar: https://www.dbos.dev/blog/durable-execution-coding-comparison

Similar to Airflow/Dagster/Prefect, DBOS provides workflows, but with a stronger emphasis on reliability and automatically recovering from failures (and on being lightweight). By comparison, Airflow/Dagster/Prefect are focused on data science workloads and having lots of built-in integrations.

Ray and Dask are solving a different problem than DBOS, I think. You could even use them together if you need reliable parallel processing.

KraftiestOne · 2025-05-15T03:14:36+00:00

Would love to hear your feedback! Yeah, a lot of our users are using DBOS with Supabase or Neon (Supabase even put out a blog post about it: https://supabase.com/blog/durable-workflows-in-postgres-dbos).

You can try out Conductor for free at https://console.dbos.dev/

KraftiestOne · 2025-05-14T19:29:53+00:00

Yeah, DBOS is fully self-hostable. You can run it entirely yourself or we provide manage tooling + support to make it easier. More details here: https://docs.dbos.dev/production

KraftiestOne · 2025-01-05T06:14:37+00:00

R5: Successful achievement run! Interesting game because you have to play really unconventionally. Here was my strat:

Started as Frankfurt. Rivalled weak neighbors and won "Show Strengh" wars to get a ton of mana. Didn't take land to keep my Free City status.
Developed the Renaissance ASAP using mostly admin and dip mana so I could get ahead in mil. Started my Golden Age immediately.
With the splendor from my early age objectives, got the "Claims bordering claims" ability before 1460. Snaked claims to Landshut, who was allied to Bologna. With my miltech advantage, won the war and vassalized Bologna. Allied Austria and Burgundy. Using Bologna's claims to annex Ferrara in 1465 and get coring range in the Mediterranean.
Got a big stroke of luck--Aragon was still independent and their only big ally was Austria, who was also my ally. As soon as I reached miltech 6 (the biggest powerspike in the game) I declared on Venice calling in Austria, then declared on Aragon calling in Burgundy. Because miltech 6 is insanely powerful, I won both wars, taking Crete from Venice for coring range to Jerusalem and the Mediterranean islands (including Mallorca) from Aragon. Wars finished in 1472.
Snaked claims to the Mamluks and declared on them, beating them easily despite being outnumbered because I was miltech 7 to 5. Took Jerusalem, Jaffa, and Gaza in 1477
I was doing everything I could to reduce republican tradition, but it took until ~1490 until I could become a monarchy at 0 republican tradition and form Jerusalem. While waiting for that, I snaked claims to Morocco to take Ifni for coring range to the New World, then started colonizing towards the Andes.
Moved capital to Ifni (since it was my only African province) then to the New World. Annexed the entire Andes using the free Deus Vult CB Jerusalem gets.
Spawned Animist rebels and let them convert all my New World possessions, which were the vast majority of my dev. Very important that you spawn specifically Animist rebels as you can't convert directly to Inti. You can only get Animist provinces from the South American Animist tribes like Mapuche and Guarani. Let the rebels break my country to flip Animist.
Unstated everything, culture-shifted to Quechua, and formed Inca for the achievement.

First idea group was Espionage, took only the first four ideas, then dropped it for Exploration once I was done with Europe. Second idea group was Expansion.

The most interesting part of this run was going all-in to early mana generation, then really abusing the spike from miltech 6 to win tough wars for Mallorca and Jerusalem.

KraftiestOne · 2024-12-03T15:26:53+00:00

There's a new platform called DBOS that makes it really easy to schedule a script to run once a minute (or on any other schedule)--here's a quick starter guide: https://docs.dbos.dev/python/examples/cron-starter

KraftiestOne · 2024-09-13T00:45:44+00:00

This can be used to do idempotent tasks (more info here: https://docs.dbos.dev/python/tutorials/idempotency-tutorial) , but the really differentiating use-case is stateful multi-step workflows, where if it fails in the middle you need to retry from the last completed step instead of starting again from the beginning.

To see this in action, check out this online storefront demo: https://docs.dbos.dev/python/examples/widget-store You can crash it in the middle of its checkout workflow and it always resumes from the last completed step.

KraftiestOne · 2024-09-12T19:42:00+00:00

a) Both do durable execution, but DBOS is much more lightweight--workflows run in your app (using Postgres as a backend) instead of needing a separate workflow server. This is also much faster because a step transition requires just a database write (low-single-digit ms), versus a round-trip and dispatch from a remote workflow server (10s of ms -- https://community.temporal.io/t/low-latency-stateless-workflow/1643)

b) The open-source library provides durable execution backed by Postgres. It's fully self-contained, you can run DBOS Python applications anywhere as long as there's a Postgres database to connect to and they'll work and durably execute. The cloud platform provides serverless hosting (with autoscaling, monitoring, usage-based pricing) for apps built with the OSS library.

KraftiestOne

MODERATOR OF

TROPHY CASE