hbrundage

Joined 17 years ago

Karma
1,194
Submissions
83
Member since
Jan 8
meet.hn/city/ca-Ottawa

Socials: - github.com/airhorns - x.com/harrybrundage - linkedin.com/in/harrybrundage ---

[ my public key: https://keybase.io/airhorns; my proof: https://keybase.io/airhorns/sigs/AXj6aLh5mTy-27JAxXYyvnvxuFMkc8_xuya5IkE1wWE ]

View on Hacker News

Recent submissions

Comment · 10 months ago
I think your definition of heavy is different than lots of other folks I know -- I'm at $1500 / mo and am actively holding back.
Comment · 1 year ago
Comment · 1 year ago
Comment · 2 years ago
The move is now to sample it and make new music!
Comment · 2 years ago
Isn't 63% => 54% regression on MMLU-Pro a huge issue? They said that it excels at advanced reasoning but that seems like a big drawback there.
Comment · 3 years ago
Makes sense!

I was just talking with a Temporal solutions engineer this week and this metric is their recommended one for autoscaling on. Instead of autoscaling on queue depth, you scale on queue latency! Specifically for them they split up the time from enqueue to start, and then the time from start to done, and you scale on the former, not the total ("ScheduleToStart" in their terms).

Comment · 3 years ago
Its interesting to see how the Rails world still thinks in terms of the number of processes listening to a queue, instead of thinking in the cloud-native, elastic, serverless terms.

There's always an autoscaling delay, but Rails itself (and the community) don't seem to fit into the serverless paradigm well such that these questions around how to design your queues come up.

I think a lot of Lambda developers or Cloud Run developers would instead say "well my max instances is set to 500, I am pretty sure I'm going to break something else before I hit that", you know? Especially when using the cloud's nice integrations between their queues and their event-driven serverless products its super easy to get exactly as much compute as you need to keep your latency really low.

Comment · 3 years ago
Comment · 4 years ago
Practical dichotomy — that’s why this thread exists. You either platform it or you don’t, and you’re either legislated to do so or not. What middle ground do you see that allows this degree of free speech without platforming hate?
Comment · 4 years ago
It’s a fundamental issue though — there’s no “figuring it out” that a government can do that won’t either censor or facilitate. 25 years has been long enough to find tactical policy changes that make it easier, but there aren’t any, which is why nothing has happened. The choice we have to make is either de-shrine free speech above all else or entrench hatred, and it’s bogus that we haven’t picked the thing that doesn’t kill people yet.
Comment · 4 years ago
A new paradigm for building web apps: a framework integrated with a runtime integrated with an IDE! https://gadget.dev

We think that so much of software development is still the same stuff repeated over and over: auth, hosting, CRUD, search, tables, forms, etc etc. Each app always has some juicy special something about it, but that core is wrapped in layers of stuff you don’t need to redo every time. Our mission is to make the first and only lines of code you write super pertinent to the specific problem you’re solving.

We’re starting with Shopify apps cause we can give developers a one click, fully managed, code-extensible API integration which is a lot of work with the Shopify API otherwise. Would love to know what y’all think!

Comment · 4 years ago
Postgres materialized views have to be manually refreshed on a schedule, and so are always out of date, whereas ReadySet keeps your results up to date automatically as the input changes. For PG materialized views, the compute required proportional to the size of the input data, and is paid every time, whereas with ReadySet the computation is incremental, so it's proportional to the size of the change in the data over time.

And finally, ReadySet's (Noria's) big innovation is that the result set can be only partial, storing only the elements of the result set (and underlying data flow graph) that are frequently accessed, instead of the whole result set like a materialized view would.

Comment · 4 years ago
This system doesn’t support interactive transactions does it? In that the whole read / write set needs to be known up front before a transaction can start being processed? I know that systems like FoundationDB and Calvin/Fauna work similarly and get incredible performance because sequencing is so much easier / lock free. I think those two systems couldn’t be adapted for interactive transactions really (without client side retries) but maybe warp could be which is cool!
Comment · 4 years ago
I mean, it’s also a bug with Resque? Resque predates the introduction of the new command in Redis and hasn’t really been maintained since. “My software is as buggy as 10 year old software unless you pay” seems pretty sketchy to me!

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton