mrkaye97

I think “significantly dumber” might include traditional RL, and thus no tokens at all

Could be - I’d also argue the time cost to the engineers to switch is pretty significant too, regardless of the monetary cost

I think the clear reason is even with their unreliability, the cost of migrating off of GitHub for _most_ places is not worth it, and so companies don't / won't (yet)

Ah yep! I should’ve given a Go example. In Python we use decorators because it’s what’s in fashion, but in Go and TypeScript you just create a `NewTask()` e.g. where you pass a function (as well as other args), and it returns something with e.g. a `Result` method. And that result method, which is generic, is the thing that’s really nice to have typed.

Agreed codegen works fine here too by the way, but it feels kind of clunky to me (it’s something I don’t love about Go, although I know it’s also an important part of the ecosystem and is popular).

As a bit of a counterpoint, I help maintain SDKs for Hatchet in multiple languages (largely Python and TS, but also contribute to Go a bit too) that benefit heavily from generics. It's especially useful for things where users of the SDK provide e.g. return types from functions they register, and we want those to be strongly-typed elsewhere in the codebase. A simple Python example is:

  @hatchet.task()
  async def my_task(...) -> SomeOutputType:
    return SomeOutputType(...)

  ## imagine this is an API handler:
  @api_handler("/some/path")
  async def handle() -> ...:
    result = await my_task.run(...)

    # we now know `result` is of type `SomeOutputType` without any sort of type assertion, etc.

Admittedly, I'm not a Go expert, nor am I a programming languages expert. But I do feel that this type of behavior is really only possible (with nice ergonomics) with generics, and it's always been upsetting to me that somehow Python's type system feels more complete than Go's in this arena, or at least it has until more recently.

Maybe this falls into the 1% of cases, but I'd suspect this sort of thing is more common than that.

Edit: I should have mentioned - in the Python example above, `@hatchet.task` is generic with the output type of the task it wraps.

For what it's worth, Work at a Startup ostensibly does give you something like this on the hiring side, although it's been far from perfect in my experience. I suspect other "platforms" for job searching might have similar, but it'd be tougher in a dedicated ATS like Greenhouse or Lever or some such, since I imagine there are data privacy laws that limit their ability to "enrich" candidate data across companies, which LinkedIn, WaaS, etc. can bypass by having you make a profile

Indeed! Materialized views won't work here as PG doesn't support "always updated" / "auto-refreshing" materialized views natively (although you can get something similar with extensions like TimescaleDB). Left joins are the thing we're often trying to avoid though, especially when the join conditions are involved, as we've seen the planner just make poor decisions in the past at unpredictable times. That's exactly the sort of situation where you might reach for this sort of trick

+1 to this - I've griped pretty often that FastAPI's documentation implicitly recommends this (https://fastapi.tiangolo.com/tutorial/sql-databases/#create-...) by suggesting using dependency injection to manage database connections, only to start seeing connection pool exhausted errors as soon as the number of concurrent requests exceeds the number of allowed connections.

Thanks! I should have clarified - we haven't been using this pattern for selective joins. Strongly agreed that pulling down extra data into memory and then doing the filtering doesn't make much sense. We've found it useful in the case where it's hard to write a query where the planner _does_ make good decisions because of the complexity of the join conditions (e.g. joins using cases, a boolean "or", or something similar).

Also, to re-emphasize: we do this rarely, but it's been helpful the times we've done it

(Matt from Hatchet - Hi Ulysse :wave:)

I, at least, don't know of a perfect fix here. Re: the original comment - Postgres will also error on deadlocks after it detects them without setting your isolation level to Serializable, but I agree with you that often retrying doesn't help, and could even cause cascading / snowballing failures if you have a backlog of retries piling up because of deadlocks.

I don't know if there's a good solution, really. We've fixed deadlocks incrementally over time as we've found them, which has worked pretty well, but of course that means also needing to deal with the "finding" part, which has generally come in the form of lots of `deadlock detected` log lines and errors (and retries accompanying those).

One thing that might be worth auditing is why there are two different bits of application code that are updating the same rows in two different tables in different orders. I know it's a contrived example, but it seems like it could be a code smell to me. Maybe this is the kind of thing that arises when two different subteams are working on the same database and are largely siloed.

Alexander will likely have more thoughts here as well, just my two cents!

agreed :)

(Matt from Hatchet)

One small addendum here is we've had a lot of success performing joins in memory in a few very specific situations where the alternative is a single, often overcomplicated query. I've heard / seen advice many times in the past about performing fewer round trips to the database being something to optimize for (often good advice!). Sometimes this is taken too far, resulting in overly-complex queries requiring complicated JOIN or UNION logic, CASE logic, and so on.

We have a couple of places in our codebase where we perform two or more simpler queries independently instead, and then loop through their results and use maps to match the relevant rows. Conventional wisdom often suggests this path will hurt performance because of the extra database round trip in addition to the loops needed to perform the join, but it is actually beneficial in these cases because of more predictable query planning behavior. We use this trick sparingly, but it can be helpful in a pinch.

Note that some ORMs will also do this for you in the background, which we don't necessarily endorse, and we try to use this sparingly when writing a single query on its own is not realistic.

Gift link, if you'd like to use it: https://www.nytimes.com/2026/07/13/style/backyard-baseball-v...

I was just going to post this, and searched first and landed here. Not much to say beyond that reading this piece made me so happy, and brought back tons of nostalgia for days I'd long forgotten.

Hello! Hatchet engineer here - just thought I'd drop a link to some discussion on this topic from last year, which is here: https://news.ycombinator.com/item?id=43574767

Happy to answer more questions beyond this!

I've been using Elixir, which has been wonderful, mostly because of how amazing the built in `Enum` library is for working on lists and maps (since the majority of AoC problems are list / map processing problems, at least for the first while)

IMO this is very dependent on the risk of cutting once, so to speak. I'd imagine that at PostHog, the idea is there's little risk of cutting many times - iterating - and more damage is done by the measuring taking far too long.

I've been working on this little Splitwise clone type app I've been calling Medici: https://github.com/mrkaye97/medici

Mostly to learn some Rust and because I thought most of the features of Splitwise worth paying for would be fun to build. Been loving working in Axum and getting to implement some fun database things

Hey everyone! I built a little app I thought people in this community might like / find useful, so I thought I'd share here. It's pretty MVP so go easy on me ;) The app: https://jobcrawler.matthewrkaye.com/ A blog post about it: https://matthewrkaye.com/posts/2023-11-10-jobcrawler/jobcraw... The idea is to make it easier to find jobs at companies you're interested in (especially in tech) and track your search without the usual bullshit of LinkedIn, Indeed, etc. I also won't sell your data, it's free (for now at least until my hosting costs go up), etc. Give it a shot and lmk what you think!

I built an app for job searching with some features I've found useful, and I'm excited to share it with HN! The main features include: job recommendations, automated emails when relevant, new postings go up at companies you're interested in, and analytics.