LewisJEllis's comments

thanks, helpful read!

can anyone point to the "Durable" part?

looking at the docs and examples, I see Workflows and Steps and Retries, but I don't see any Durable yet. none of the examples really make it clear how or where anything gets stored

The interface in question is the second link in the post. To get to the interface without any of the other relevant context, you would have to:

- skip reading the post (which explains all of this)

- skip the first link in the post (which explains all of this)

- go straight to the second link in the post, to the interface

- skip the "about" link in the interface (which explains all of this)

I would recommend reading more of the pricing page. You'll learn that:

- $312/year and $960/year are for unlimited users, not per seat

- Additional error/event volume is priced separately from the base plan

- You can pay for error volume, either prepaid or on-demand, without a custom enterprise deal:

> Each of our plans comes with a defined quota, with the option to process additional events by setting a pay-as-you-go budget. You can also plan ahead and save 20% over the pay-as-you-go rates by reserving events.

> FWIW, if Sentry had stayed GPL

Sentry has never been GPL. https://blog.sentry.io/lets-talk-about-open-source/

> pretending it's an OSS license

They are not pretending it's an OSS license. The article states:

> “Just don’t call it Open Source.” Point taken. Fair Source is our new term.

Sentry's been around for ~15 years, and has been using a license fitting the Fair Source definition for ~5 years. This is not a "hastily preparing ourselves to be acquired" sort of move. What makes you think this is a sign of some impending change?

Sentry's pricing plan has never gone from 10k errors straight to "negotiated enterprise deal"; you must have missed something. I say this having been a Sentry customer for the past 7 years across multiple companies, always with a paid plan beyond 10k errors and never with an enterprise deal.

"they have seemingly just ignored the better option...obviously much nicer"

This comes off a bit presumptuous. I would assume that they are aware this is a possibility.

"having to use a web service to view you stack trace"

This is just not a downside that matters for this usage scenario. It's almost the same story as minifying your frontend JS bundle, uploading source maps to Sentry, then using Sentry to view an unminified stack trace from a user's browser. The user was never going to view that stack trace anyway, and I am not bothered by having to use Sentry to view it - I never would have seen it at all otherwise.

As an Airplane customer, Ben was the man, always super helpful when we had questions.

When we heard Airplane was shutting down, everyone's first thought was "can we hire that Yolken guy?"

I used to work for a bot mitigation vendor 8-10 years ago, researching / implementing signals for this cat and mouse game.

This will get you past some very mundane bot detections, but really this is like, the very first baby step of a long rabbit hole.

The people who are taking this game seriously are 5-10 years ahead of this step. Good luck ¯\_(ツ)_/¯

APoSD is a relatively quick high-signal read, and not really a source of additional chaos. You can get through it in a weekend or less.

It mostly gives you vocabulary and labels and explanations for things that you may already intuitively understand, and teaches you to notice small things that matter. It will probably make it easier for you to discuss and dissect some of the chaos you're already dealing with.

Love Kysely, been rooting for it ever since it was first released. Paired with kysely-codegen, it's my favorite TS <> SQL interface. Does just enough, but not too much.

Had lots of good experiences working with Knex.js over the years, and Kysely is the TS-native spiritual successor to Knex.

Yea, DuckDB is a slam dunk when you have a relatively static dataset - object storage is your durable primary SSOT, and ephemeral VMs running duckdb pointed at the object storage parquet files are your scalable stateless replicas - but the story gets trickier in the face of frequent ongoing writes / inserts. ClickHouse handles that scenario well, but I suspect the MotherDuck folks have answers for that in mind :)

I recently read his book, “A Philosophy of Software Design”, and loved it.

It’s 175 pages of well-refined, to-the-point, applicable wisdom; highly recommended.

I think https://github.com/RobinBlomberg/kysely-codegen does roughly the same thing?

I see a kysely + kysely-codegen (generates types from DB schema) setup as comparable to Prisma in TS integration, with the added flexibility/closeness-to-SQL of the querybuilder.

If you:

- have used/liked Knex (or similar querybuilders) before

- like the TS integration + type safety of Prisma

- but find Prisma to be a bit too magic/heavy with its query engine and schema management

- and/or just want to be closer to SQL

then Kysely is what you're looking for.

No, he's stated somewhere in the issue tracker that he has no plans to ever do this.

edit: here - https://github.com/koskimas/kysely/issues/162#issuecomment-1...

You sound like you're trying to have it both ways: "OTel solves a problem that is irrelevant unless you're massive" but also "well of COURSE it can work if you're not massive, how massive are you?"

There are tons of startups and other not-fortune-x00 orgs benefitting from what OTel provides. Your claim that OTel is irrelevant outside fortune-x00 cos is very clearly not true.

most or all of the observability domain experts i'm familiar with either stopped talking about "pillars" several years ago, or have been actively speaking against the "3 pillars" framing for several years

most of your takes here sound like they're from somewhere around 2016-2018

Hadoop isn't a database, they don't do anything close to the same thing. Nobody is cross-shopping PlanetScale vs Hadoop.

The cross-shop is PlanetScale vs Amazon RDS, Amazon Aurora, Google Cloud SQL, Firebase, Supabase, self-hosting Vitess or MySQL, etc.

The idea of slope vs y-intercept as applied to people/hiring is not some random unknown made-up theory; it's quite commonly discussed/repeated among founders, VCs, etc. I think it may've originated with John Ousterhout.

https://twitter.com/search?q=slope%20y-intercept