Comments URL: https://news.ycombinator.com/item?id=46928001

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46910830

Points: 4

# Comments: 1

I'm not really sure why you'd say that OpenAPI isn't a JSON Schema document: there are published JSON Schema files on the official OpenAPI website. See for example:

One using the draft-04 of JSON schema: https://spec.openapis.org/oas/3.0/schema/2024-10-18.html One using the 2020-12 version of JSON schema: https://spec.openapis.org/oas/3.2/schema/2025-09-17.html

Comments URL: https://news.ycombinator.com/item?id=46077439

Points: 2

# Comments: 0

I set up spec-kit first, then updated its templates to tell it to use beads to track features and all that instead of writing markdown files. If nothing else, this is a quality-of-life improvement for me, because recent LLMs seem to have an intense penchant to try to write one or more markdown files per large task. Ending up with loads of markdown poop feels like the new `.DS_Store`, but harder to `.gitignore` because they'll name files whatever floats their boat.

Comments URL: https://news.ycombinator.com/item?id=45937016

Points: 1

# Comments: 0

The closest that you can get on this front is basically seasonal route switches for cruise liners. The thing is, cruise lines price gouge on WiFi, so I'm not really able to work while taking the slow route, and I'm also having to pay food, lodging, etc.

The latency itself / limited freedom for a week or two, I don't mind. But it's the other expenditures and tradeoffs that are rather hard to stomach.

I think it'd be useful to focus on this more:

> Voiden turns your API definitions and docs into dynamic, purpose-built interfaces — no fixed UI, no rigid templates. Everything is composed in one place and rendered down to Markdown, tailored to the API it serves.

One of the things you'll often hear as a critique levelled against Haskell developers is that we tend to overcomplicate things, but as an organization we skew very heavily towards favoring simple Haskell, at least at the interface level that other developers need to use to interact with a system.

So yeah, basically: Web Request -> Handler -> Do some DB queries -> Fire off some async work.

We also have risk analysis, cron jobs, batch processing systems that use the same DB and so forth.

We're starting to feel a little more pain around maybe not having enough abstraction though. Right now pretty much any developer can write SQL queries against any tables in the system, so it makes it harder for other teams to evolve the schema sometimes.

For SQL, we use a library called esqueleto, which lets us write SQL in a typesafe way, and we can export fragments of SQL for other developers to join across tables in a way that's reusable:

select $ from $ \(p1 `InnerJoin` f `InnerJoin` p2) -> do on (p2 ^. PersonId ==. f ^. FollowFollowed) on (p1 ^. PersonId ==. f ^. FollowFollower) return (p1, f, p2)

which generates this SQL:

SELECT P1., Follow., P2.* FROM Person AS P1 INNER JOIN Follow ON P1.id = Follow.follower INNER JOIN Person AS P2 ON P2.id = Follow.followed

^ It's totally possible to make subqueries, join predicates, etc. reusable with esqueleto so that other teams get at data in a blessed way, but the struggle is mostly just that the other developers don't always know where to look for the utility so they end up reinventing it.

In the end, I guess I'd assert that discoverability is the trickier component for developers currently.

I can't really speak to your problem domain, but I feel like we do a lot with what we have. Most of our pain comes from compile times / linking taking longer than we'd prefer, but we invest a lot of energy and money improving that in a way that benefits the whole Haskell ecosystem.

Not sure what abstractions you are wondering about, though.

As you figure out how to live life from here– may you find a path forward that is healthy, loving, and beneficial for you and those you care about.