HackerLangs
TopNewTrendsCommentsPastAskShowJobs

brandur

3,354 karmajoined 15 lat temu
APIs + engineering @ Snowflake. Ex-Stripe. Ex-Heroku.

Twitter: https://twitter.com/brandur

GitHub: https://github.com/brandur

Website: https://brandur.org

Email: [email protected]

Submissions

The minimum viable unit of saleable software

brandur.org
217 points·by brandur·20 dni temu·80 comments

The fourth law (on AI-generated supercustomized email marketing)

robinsloan.com
3 points·by brandur·w zeszłym miesiącu·1 comments

comments

brandur
·4 dni temu·discuss
Thanks, this is neat. Goodreads seems to be get so little development attention these days that it's a miracle it still runs.

Interesting choice by BookWyrm to hide review ratings by default. I like it — I always felt that on Goodreads literature that's a little more challenging to tackle is reviewed very unfairly compared to easy-to-digest-but-content-light popular books or pulp fantasy. Making the default to have users read the contents of a review instead of glancing at an aggregate number seems like the right answer.
brandur
·19 dni temu·discuss
Blake wrote a nice page on the benefits of using transactional-based enqueuing here:

https://riverqueue.com/docs/transactional-enqueueing

It's true that it's not distributed, but there are a lot of benefits to not going distributed immediately, like extremely predictable data consistency. I would hazard to guess that the _vast_ majority of apps that are not built by the superscalers are already using a database like Postgres or SQLite to store their data, and River merely suggests that you hook your job queue into the database that you already have.
brandur
·19 dni temu·discuss
There's some similarities with DBOS for sure like using Postgres as a backend. Here's some differences based on my browsing of their docs for a little while:

* River's built around an entirely open core with its bread and butter being background jobs rather than workflows, with basic background jobs being good enough for most apps in most situations. It's true that workflows are gated behind Pro, but a lot of users will find they won't even need them, or won't need them until much later.

* River's aimed more solidly at Go, especially for the running of the background jobs themselves. Blake and I are both experienced Go developers, and we've gone through great pains to make the API as elegant as possible and as easy-to-use as possible, aiming for things like consistency and predictable + well-documented APIs. DBOS supports Go as well, but I believe our API compares very favorably [1], though you can be the judge.

* I might be missing something in the DBOS docs, but especially pertaining to background jobs, I believe River's feature set is quite a lot more comprehensive. e.g. Bulk insertion, unique jobs, periodic/cron jobs, job snoozing, job scheduling, unique jobs, test helpers, etc. We've tried to include everything that people would need when building out with background jobs, including all the edge cases.

Lastly, to be fair, DBOS is price-gated as well [2], and pricing is based on usage whereas River's is not.

[1] https://docs.dbos.dev/golang/programming-guide [2] https://dbos.dev/dbos-pricing
brandur
·19 dni temu·discuss
Yes, if one of the admins/mods could correct this, it'd be amazing! The rest of the title is fine.
brandur
·19 dni temu·discuss
Yes, I roughly agree with all of this. In fact, for most of my existence, I'm been one of those cheap programmers.

The circumstances that led to me trying to push River for the next few months were somewhat accidental, and it felt like a good moment to at least make a go of trying to make it work. I'm not committing the rest of my career/life to any particular decision one way or the other.

I'll reiterate too that I believe we're still quite early in the LLM age and are still waiting for the other shoe to drop. All LLM-generated software feels free at the moment because it's still novel and the exhilaration of accomplishment when you build something complex inside of a few hours is addictive beyond words. However, within a year or two I think we're going to have a lot more software, all of which needs maintaining to some degree, and we're going to become a little more reluctant to generate new projects to add to the heap. This'll cause an adjustment back to a more compromise position.

(Also, could be completely wrong about all of that, so take it for what it is.)
brandur
·20 dni temu·discuss
Thanks dzonga!
brandur
·10 miesięcy temu·discuss
To be fair I guess, the way the article is titled goes out of its way to mislead.

It would be quite easy to say "Added 911,000 fewer jobs from March 2024 to March 2025" or "the year starting in March 2024", but they are clearly aiming to deflect from the Biden admin by implying last year's revisions are the fault of the administration inaugurated in January 2025.

Judging by the comments here, it worked marvelously.
brandur
·5 lat temu·discuss
Totally irrelevant, but a related fact in this vein: I recently learned "尻" via WaniKani (a popular SRS system to help learn kanji), and the mnemonic they used to help you remember the reading of this kanji/vocabulary (お尻) is now inspired on Apple's Siri:

https://www.wanikani.com/kanji/%E5%B0%BB

> Now that you have nine flags inside your butt, you have to get them out. But, you don't know how to. So you ask Siri (しり — shi-ri), "how do I get nine flags out of my butt?"

(Note: The kanji is composed of the radicals "nine" and "flag", which is how they get to "nine flags".)

(Note: WaniKani's mnemonics are very often somewhat non-sensical slightly entertaining stories in the same style as this one. Very normal.)
brandur
·9 lat temu·discuss
I'd also be interested in an answer. I'm guessing the answer is "no" based on my reading of the docs, but it'd be nice to confirm that.