mrkaye97

Out of curiosity, do you have any concerns about backups (especially for e.g. VaultWarden and Immich)? I've been pondering running them, but figure that I'd need to back up to The Cloud for me to feel less concerned about losing everything, at which point: what's the point? Curious what you're doing on that front!

This hit too close to home. After years of dentists (and orthopedic surgeons, and GI surgeons, and plumbers, and so on) selling me oodles of shit I don't need, I finally found one who strikes me as very honest. I had to stop going to her for one year when my insurance switched, and what do you know? The dentist I saw in the interim did a hard sell on Invisalign, which I happily turned down, and never went back.

I'm back at my One Trusted Dentist now, and the only way anyone's getting me out of that chair is in a body bag.

This has basically been the story for us at Hatchet too, and it’s been similarly challenging. A lot of the OSS PR reviews I’ve done lately from non-core contributors are basically just me going back and forth with Claude via someone else, which is frustrating when I feel like I could 1) just not or 2) do the back and forth with Claude myself and cut out the middle man.

I have a sneaking suspicion that people are having some agent check out 500 repos and just prompting with “find a bug in this repo and fix it” and submitting the results blindly.

Edit: typos, on mobile

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

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