LewisJEllis

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

Hi, I work for Pave (but I don't speak for Pave, etc etc).

> If I remember correctly, because they have your name, they also scrape LinkedIn data about you and try to get as much information about you as possible like job titles, etc.

I am not aware of Pave doing anything like this.

> I would not want my entire salary history to be shared with prospective employers so that they could definitively say "Well, this person got paid X in their previous position, we shouldn't pay more than 5% above that."

Pave does not share specific identifiable data like "John Doe got paid $X at EmployerCo".

Pave only shares aggregations like "people in San Francisco, with the title Senior Software Engineer, at companies between 100 and 500 employees, typically get paid $X at the 50th percentile, $Y at the 75th, and $Z at the 90th".

From Pave's website, https://www.pave.com/products/compensation-benchmarking-data:

> Benchmarking can never be traced back to an individual or employee.

I am not aware of any of these things having changed at any point.

Yes. Some folks who variously:

a) didn't know how to recognize a cheeky straw man proposal

b) didn't know how to take a joke

c) didn't agree with (or understand the importance of) the never-break-the-web imperative that TC39 operates under (turns out this is a lot of people)

tried to do exactly this to "prevent smoosh":

- https://github.com/staltz/prevent-smoosh

- https://twitter.com/andrestaltz/status/971500672620351494

Mostly, though, they just taught TC39 to have less fun and to ignore the "just break the web it's okay!" crowd.

Why TC39 operates under this never-break-the-web imperative: because if they didn't, every proposal they consider might devolve into an unresolvable discussion of "well is THIS thing important enough to break the web over? how much usage would this change break? how valuable do we think this is?". The easiest, and only, way to resolve all possible such discussions is to just not have them.

Have you ever considered that solutions to your perceived problem might exist?

I’ve done multiple different takehomes with some kind of time limit in place to avoid that sort of thing. Tools have this built in.

Also, there are definitely candidates who would prefer a takehome. If you’re worried that a takehome might be unfair, you can offer folks a choice to either do the exercise on their own async, or to do it live pairing with you. You might be surprised by how many will choose the former.

I've also been following Kysely and am a big fan, having used Objection.js and Knex a lot in the past. I consider Kysely to be the TypeScript-native spiritual successor to Knex.

For a theoretical new Node + TypeScript + SQL project, the three options I would consider are, from most-ORMy to least:

- Prisma

- Kysely + kysely-codegen (query builder)

- slonik + @slonik/typegen (raw postgres driver with good types; not sure if there's a good MySQL equivalent)

huge +1 here! pairing and debugging put focus on easy mode

I’ve also personally found focus more easily in framings along the lines of “survey the thoughts and options around X, then drive discussion toward picking a direction” or “here’s a numeric measure of how fast the thing currently is, iterate on making that number smaller”

Uh, what? All else equal, a heavier vehicle will emit more brake dust. Basic physics says so. If you want to claim otherwise, bring a source.

It may be the case that electric cars, thanks to regenerative braking, do not emit more brake dust than a lighter non-electric car, but that's not what the parent comment here was saying.

From the pricing page:

> How are rows read and rows written calculated? > Every time a query retrieves a row from the database, it is counted as a row read. Every time a row is written to the database, it is counted as a row written.

From the billing docs:

> our paid Scaler plan comes with 25 GB storage, 100 billion row reads, and 50 million row writes

> Every row read from a table during execution adds to the rows read count, regardless of how many rows are returned.

> You can test a query for approximate rows read using the EXPLAIN statement. Running EXPLAIN with your query will return information about the query execution plan.

> To see the exact rows read, you will need to run the query. You can use the EXPLAIN ANALYZE statement to do this. It will return the estimated information about how it will run the query, run the query, and then return the actual impact from running the query.

> Another useful way to check rows read is using innodb_rows_read. This server status variable will show you the number of rows read across all tables. You can run it before and after queries to calculate how many rows were read.

These bits are extremely specific, down to the storage engine level. I don't know what more you could be looking for as to what "rows read" means than `innodb_rows_read`.

Your comment used to read:

> C'mon guys, this is super basic.

which came off as demanding, until you edited it after my response to instead read "This is standard stuff".

It's bad form to make substantial edits an hour later after you've been replied to, especially if you then refute the reply based in part on that edit.

I agree with you that more examples would be helpful, and you have some good questions which are left unanswered, but "is it rows?" was answered very clearly by the pricing page and billing docs.

The comment by truetraveller is complaining about the pricing and docs, not the blog post:

> The pricing page/docs leaves so many questions unanswered:

The pricing page and docs make "rows" very clear. I was never referring to the blog post, nor was truetraveller.

I agree with you that there are some simple questions left unanswered, but "is it row reads?" is not one of them.