stephen (u/stephen) - Readit News

stephen commented on We rewrote the Ghostty GTK application mitchellh.com/writing/gho... · Posted by u/tosh

stephen · 9 days ago

I've been using Ghostty, and other GPU-based apps like Alacritty / WezTerm / Zed, because they're ofc better/faster...

Ironically they've all made my DX worse, by highlighting how terrible the nvidia drivers actually worked on both my old Regolith i3wm/compositor-less or new sway/wayland setup.

Like it's ridiculously terrible.

I've tried every magical env flag that Claude can think of, and 4 of the various 550/560/575/580 driver versions--they all suck at screensharing, or resume from sleep, or just out-right buginess/crashes/segfaults in the nvidia drivers.

It must have always been this bad, but I just didn't notice, b/c I never actually used my GPU? lol

stephen commented on Show HN: I've been building an ERP for manufacturing for the last 3 years github.com/crbnos/carbon... · Posted by u/barbinbrad

vindin · 19 days ago

I really recommend you do more reading on DDD. This codebase is looking like a ticking time bomb. Biggest red flag I’m seeing right now is your supabase/functions/create/index.js. You have 2000 lines of code that contain what I see is your domain logic mixed with database queries and http concerns. In some places there are 8+ levels of conditionals, promises, and error handling. For an ERP system, this is not good. Ideally the domain logic (accounting, rules, core erp stuff) should be isolated by itself, with solid test coverage, free of any external communications/concerns, etc. The reason being that this is not something you want to fuck up. Business rules are tough as I’m sure you know, and this is going to be a pain to maintain in its current state

stephen · 19 days ago

I was wondering the same, about their backend domain model (or lack of it).

Fwiw in the TypeScript space, we built Joist (https://joist-orm.io/) to do exactly this.

Granted, we went with a Rails/ActiveRecord minimalist take on DDD instead of some of the more elaborate (overkill imo) implementations that are common i.e. in the .NET space.

stephen commented on Microservices are a tax your startup probably can't afford nexo.sh/posts/microservic... · Posted by u/nexo-v1

asim · 4 months ago

> Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value.

Basically this. Microservices are a design pattern for organisations as opposed to technology. Sounds wrong but the technology change should follow the organisational breakout into multiple teams delivering separate products or features. And this isn't a first step. You'll have a monolith, it might break out into frontend, backend and a separate service for async background jobs e.g pdf creation is often a background task because of how long it takes to produce. Anyway after that you might end up with more services and then you have this sprawl of things where you start to think about standardisation, architecture patterns, etc. Before that it's a death sentence and if your business survives I'd argue it didn't because of microservices but inspite of them. The dev time lost in the beginning, say sub 200 engineers is significant.

stephen · 3 months ago

> Microservices are a design pattern for organisations as opposed > to technology ... breakout into multiple teams

I agree, but just saying "multiple teams" has led many eng directors to think "I have two squads now --> omg they cannot both be in the same monolith".

When both squads are 5 people each.

And the squads re-org (or "right size") every 9 months to re-prioritize on the latest features.

Five years go by, 7 team/re-org changes, all of which made sense, but thank god we didn't microservice on the 2nd/3rd/4th/5th/6th team boundaries. :grimmacing:

We should stay "stable, long-lived teams" -- like you need to have a team that exists with the same ownership and mandate for ~18 months to prove its a stable entity worth forming your architecture around.

stephen commented on We fell out of love with Next.js and back in love with Ruby on Rails hardcover.app/blog/part-1... · Posted by u/mike1o1

mattgreenrocks · 4 months ago

Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM.

My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shape because that’s too magical. Instead the Right Way is to learn a DSL (such as Zod) to describe the shape of the input, then manually write the code to check it. Every single time. Oh and you can’t write a TS type to do that because Reasons. It all comes off as willful ignorance of literally a decade or more of established platforms such as Rails/Spring/ASP.NET. All they had to do was steal the good ideas. But I suspect the cardinal sin of those frameworks was that they were no longer cool.

I have a hard time relaying this without sounding too negative. I tried to get into SSR webdev with TS and kept an open mind about it. But the necessary ingredients for me weren’t there. It’s a shame because Vite is such a pleasure to develop with.

stephen · 4 months ago

Well, we're not the "go to" yet :-) but if you want an entity-based ORM that isn't just a query builder, Joist has several amazing features (no N+1s) and great ergonomics https://joist-orm.io/

stephen commented on Show HN: Hatchet v1 – A task orchestration platform built on Postgres github.com/hatchet-dev/ha... · Posted by u/abelanger

stephen · 5 months ago

Do queue operations (enqueue a job & mark this job as complete) happen in the same transaction as my business logic?

Imo that's the killer feature of database-based queues, because it dramatically simplifies reasoning about retries, i.e. "did my endpoint logic commit _and_ my background operation enqueue both atomically commit, or atomically fail"?

Same thing for performing jobs, if my worker's business logic commits, but the job later retries (b/c marking the job as committed is a separate transaction), then oof, that's annoying.

And I might as well be using SQS at that point.

stephen commented on Ask HN: What are you working on? (March 2025) · Posted by u/david927

stephen · 5 months ago

Working on v2 of our n+1-proof/reactive TypeScript ORM, Joist (https://joist-orm.io/), that moves to using the new-ish postgres.js driver (instead of knex/node-pg), so that we can leverage postgres.js's statement pipelining within transactions.

I'm anticipating a really sweet perf increase (as shown by some proof-of-concepts), but now that everything is actually working on the v2 branch, I'm putting together benchmarks that show the benefit in practice.

Love to have anyone poke around/ask questions/hang out on discord.

stephen commented on JavaScript Temporal is coming developer.mozilla.org/en-... · Posted by u/SigmundurM

phiresky · 7 months ago

Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot).

It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use.

Yes, it is a bit more complex to handle since it separates time into naive time, instant and zoned time. But by experience, developers only confront complexity when they are forced to, and time _is_ complex.

If you want to do the operation "add one day to this timestamp", you _must_ decide whether that timestamp is local to a specific timezone and which one. Otherwise you'll get a bug twice per year due to DST, or when the user switches time zones, or when you deploy on a server with a different timezone.

It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris).

[1]: https://www.npmjs.com/package/temporal-polyfill

stephen · 7 months ago

Same! We've also been using the polyfill in production for a ~year or so.

We recently configured the node-pg driver to leave the postgres DATE / TIMESTAMP / TIMESTAMPTZ dates as "just strings" (instead of its default parsing to JS dates), and then we go straight from strings -> temporals at our ORM layer, without the jank/hop of it first being a JS Date.

...shoot, we need to get the Temporal out-of-the-box support updated in our Joist (https://github.com/joist-orm/joist-orm/) docs. :-/

But it's been great, having `DATE` in the db => `PlainDate` in the TS backend => `Date` in GraphQL API => `PlainDate` again in the TS/React FE. Very clean.

stephen commented on Rails is better low code than low code radanskoric.com/articles/... · Posted by u/thunderbong

jitl · 9 months ago

I don’t want to build in a language without types, but low code is even less types than Rails. I’ve just never worked on a public app that was simple enough for Rails to feel good - Airbnb was rails but by the time I got there it was very much not simple. Internal tools in rails though, that is okay.

stephen · 9 months ago

> don't want to build in a language w/o types

Yep; that's the only reason I don't use Rails.

I'm building "ActiveRecord but with type(script)" at https://joist-orm.io/ and have our own internal "kinda Rails w/GraphQL" going internally--so far we're at ~450 tables and still "feeling good" (no n+1s ever!), but definitely a long way to go before AirBNB-sized problems.

stephen commented on Putting a full power search engine in Ecto moosie.us/parade_db_ecto... · Posted by u/philippemnoel

latch · 10 months ago

I don't understand why people use Ecto (or ActiveRecord, or...)

Back in the day, I'm pretty sure we were using Hibernate and friend because our software was shipped and we wanted it to work with whatever database the client was using.

But for a hosted software, what's the point? Not having to know SQL or details about PostgreSQL / the underlying DB ? Apps should be using SQL directly, and for cases where you need dynamic SQL (like, you're where clause is different based on some query string parameters), you can have a low-level query builder (1)

(1) I'm not affiliated with it and have never used it, but a good search came up with https://github.com/robconery/moebius which, at least from the readme, is roughly what I'm talking about.

stephen · 10 months ago

Using raw SQL directly is doable, but it means you're responsible for maintaining the business logic & validation rules of every single hand-written INSERT, UPDATE, and DELETE query in your codebase.

Personally I don't trust myself to remember to do that :-) hence preferring entity-based ORMs:

https://joist-orm.io/docs/modeling/why-entities

(That said, I definitely "know SQL" and use raw SQL queries for the ~5% of queries in a CRUD/SaaS app that are actually unique/non-boilerplate, instead of forcing them to go through an obtuse query builder DSL.)

stephen commented on Modular Monoliths Are a Good Idea materializedview.io/p/mod... · Posted by u/riccomini

stephen · a year ago

I mean, of course they are a good idea, what we need is more examples of actually doing them in practice. :-)

I.e. quoting from the post:

- monolithic databases need to be broken up - Tables must be grouped by module and isolated from other modules - Tables must then be migrated to separate schemas - I am not aware of any tools that help detect such boundaries

Exactly.

For as much press as "modular monoliths" have gotten, breaking up a large codebase is cool/fine/whatever--breaking up a large domain model is imo the "killer app" of modular monoliths, and what we're missing (basically the Rails of modular monoliths).