simonklee

It’s simply a lot of grunt work to do these which is why many are unsolved.

Nice, used a similar approach for another one of these this week

https://simonklee.dk/farnese-letter

Exactly, i think this product is solving an airport problem and not a user problem. Whenever i park at an airport i always look for the shortest distance to terminal / price, then chose an option that lands within an acceptable range. Unless i'm way for very long shuttle-bus isn't really on the table.

It's a ~1d old experiment. Not sure why posted on hackernews.

Say what you want, but for people building products on Bun, this is bad news for the foreseeable future.

Not really, except that they have a bunch of weird things in the source code and people like to make fun of it. OpenCode/Codex generally doesn't have this since these are open-source projects from the get go.

(I work on OpenCode)

I agree with you. After reading a couple of the chapters I'd be surprised if this wasn't written by an LLM.

It's just an odd claim to make when it feels very much like AI generated content + publish the text anonymously. It's obviously possible to write like this without AI, but I can't remember reading something like this that wasn't written by AI.

It doesn't take away from the fact that someone used a bunch of time and effort on this project.

java.util.Date and java.util.Calendar are the two packages I remember struggling with as a new programmer. Which I guess is solved with java.time after Java 8.

And it's obviously expensive use this approach.

Performance benefits of the approach seem nice, with SPDK reducing kernel context switches, and direct NVMe to reduce latency in the storage path. This does require a more specialized setup, than Neon's tiered architecture (Safekeepers → Pageservers → cloud storage), at the expense of storage cost obviously.

Is this the first model that has a 10M context length?

Some comments by the author: https://x.com/axboe/status/1854244924633252074

There is a nice TLDR at the top of the post:

  - 17rc1 looks great - there are no big regressions and several big improvements
  - There might be small regressions (~2%) from Postgres 15 and 16 to 17 but this benchmark was not setup to diagnose that.

I like tokenizers and parsers because they have a certain rhythm to them, and Zig's new labeled switch simplifies state transitions by allowing continue statements to target specific switch cases. Like computed-gotos in C.

- Zig issue: https://github.com/ziglang/zig/issues/8220 - Release notes: https://github.com/ziglang/zig/pull/21257#issuecomment-23368...