> You shouldn't be blocking the main event loop for 30 seconds! The main event loop is not intended to be used for heavy processing.

This article is talking about an SDK that runs in users' apps. Users can run whatever code they want, so the SDK has to find a way to keep sending the outgoing heartbeats

> Reading the article, I didn’t see this answered: why not scale to more nodes if your workload is CPU bound?

It's an SDK that runs in users' apps. So userland code blocks the event loop, preventing outgoing heartbeats from the SDK

We'll release an Upstash Workflows adapter soon! StepKit is ultimately just an in-code API that lets you define workflows in a backend agnostic way. We want you to define workflows that can run in Upstash, Inngest, Cloudflare... really anywhere!

Vercel Workflow Kit takes a very different approach. Lack of step IDs (which makes them worse at handling code changes), compilation step, more opinionated about backends ("worlds", as they call them). Vercel Workflow Kit has magic that admittedly makes it a little easier to get started, but that magic causes problems when you want a mature product.

Cloudflare Workflows are actually complementary to StepKit! We'll soon release an adapter that lets you define StepKit workflows that run as Cloudflare Workflows. We have a POC in `packages/cloudflare` in our repo

Inngest engineer here! For a little extra context, the `@stepkit/core` package is basically just an API for defining a workflow. There isn't much to it because we don't want to be overly opinionated on backend implementations!

The `@stepkit/sdk-tools` package is a set of tools for building your own StepKit SDK. The vast vast majority of stuff in there is optional, but highly valuable if you want to avoid reinventing the wheel when building your own SDK.

Why is nominal typing desirable?

example:

  type FireNuke = boolean;
  type DontFireNuke = boolean;
  function perhapsFireNuke(action: FireNuke);

you wouldn't want to call perhapsFireNuke with DontFireNuke, even though the types are compatible

To be fair, this is a better example of booleans being a poor fit for modeling many problems. And it’s solvable without even addressing either issue (eg how this is modeled in the real world with multiple affirmatives).

unless... you know

PEPs are often great documentation. They definitely don't cover everything, but they can be helpful

I find a bit infuriating that the official docs for pattern matching are the PEPs. Maybe that will change at the next pattern matching lang change, and I think PEPs and language docs each have their separate purposes, but on the other hand it's nice that the PEP is good (and current) enough as usage documentation.

how sad it is that the documents that described the changes exist as the reference for them, though.

Because I get rewards when I use it. I always pay at the end of the month so I never pay interest

Exactly, I have 3 cards and choose the one that offers the highest rewards for each transaction. Then pay it off at the end of the month.

I use Cursor and I get a lot of benefit from its autocomplete suggestions, but its composer is horrible so I never use it. The dream of telling AI to make changes on its own hasn’t arrived

I always make sure recover is used in all goroutines I start. I don’t want a panic in a random goroutine to crash my whole server