molf

Double? Rookie numbers.

We went from $1k to $21k per year.

A few emails later and we have a hefty discount, but we will still move away.

molf

先月議論

If you’re interested in what a specific piece of code compiles to, it’s worth checking out the online compiler playground [1]

https://playground.react.dev/

molf

先月議論

It really does work very well in practice. A few things really help:

- Lints [1] that flag code that cannot be (correctly) optimised. Usually this is obscure code that is too smart for its own good. But the compiler leaves it alone and flags it for review, so most things just keep working.

- Lints that flag code that violate the rules of hooks. These rules became more critical to follow: failure to do so may break rendering. But non-compliant code can be easily be excluded from compilation [2], so you do not have to fix everything at once.

- Popular libraries that are not compatible (yet) are flagged and excluded automatically [3].

The compiler is better than manual memoization, because 1) it is hard not to forget memoizations, and 2) the compiler's output memoizes more granularly than manual memoization realistically could.

I have not found performance regressions. Not saying they're not possible; but we haven't encountered them.

We have a very performance-sensitive project that used preact (chosen for performance) via its compatibility layer, that we switched to React + React compiler. Performance is noticeably better than with preact. Whereas previously the React-only version was incredibly slow even with carefully placed memoizations, because they were very hard to get right.

[1]: https://react.dev/learn/react-compiler/installation#eslint-i...

[2]: https://react.dev/learn/react-compiler/incremental-adoption

[3]: https://react.dev/reference/eslint-plugin-react-hooks/lints/...

molf

先月議論

After bun [1] this is another high-profile project that was ported to Rust by extensively using LLMs.

Very curious to see how these rewrites play out. Is the LLM foundation solid enough to build upon and iterate on? Or does this cause projects to become unmaintainable because no person understands the implementation anymore?

[1]: https://news.ycombinator.com/item?id=48132488

molf

先月議論

So isn't not changing more sensible than changing to an arbitrary alternative?

The current developers surely are more familiar with the Babel representation than OXC, so why switch?

molf

先月議論

OXC is not the only consumer, so using the OXC AST wouldn't particularly make sense? I thought it was pretty well explained in the PR:

> Note that the conversion from any AST into our HIR is complex, and we can only maintain one version. Hence we've aligned on using a Babel-like AST as our public API. Another key point is that we don't yet implement our own scope analysis (since the TS version of the compiler relied on Babel's scope analysis), so for now we require that the scope data be serialized. It's a denormalized graph, and some metadata has to be stored to associate nodes with scopes. We're open to feedback about the AST and scope representation - we iterated a bit just to get things to work, but it can be more optimal.

molf

先月議論

Yes absolutely.

It's brilliant: all useMemo and useCallback can be removed and you get the same runtime performance and then some, at the cost of only a slight increase in code size.

A small downside at the moment is the build time. This change will hopefully help address that because it will no longer depend on babel.

molf

先月議論

There is no SQL successor: SQL is here to stay.

Applying the Lindy effect [1]: after half a century of SQL we can expect it to survive for at least as long.

Disruption/displacement of SQL is like attempting to replace email. It's not going to happen. At best an alternative technology can carve out a small niche (and there's nothing wrong with that).

[1]: https://en.wikipedia.org/wiki/Lindy_effect

molf

先月議論

I have no idea; but I presume they don't, given that ZJIT today is still much slower than YJIT? [1]

[1]: https://rubybench.github.io

molf

2 か月前議論

Were there 1M line diffs in the past, before LLMs? That seems (seemed?) legitimately insane.

Simultaneously a very good example of how Github needs to adapt to the changing software development landscape?

molf

2 か月前議論

This specific painting was reinterpreted based on specific descriptions of the colours in a letter from the painter.

As far as I'm aware there is no way to know for sure what colours originally looked like, especially if the information is limited. There are so many variables, we can only guess.

molf

2 か月前議論

Agreed. I absolutely adore the idea of it! But all the brownish colours tell the same story.

For some additional context; many old pigments were not stable at all.

https://www.vangoghstudio.com/what-were-the-original-colors-...

molf

2 か月前議論

> Most useful async blocks are big enough that the overhead for the error cases disappears.

Is it really though?

In my experience many Rust applications/libraries can be quite heavy on the indirection. One of the points from the article is that contrary to sync Rust, in async Rust each indirection has a runtime cost. Example from the article:

    async fn bar(blah: SomeType) -> OtherType {
       foo(blah).await
    }

I would naively expect the above to be a 'free' indirection, paying only a compile-time cost for the compiler to inline the code. But after reading the article I understand this is not true, and it has a runtime cost as well.

molf

2 か月前議論

It's not possible to learn anything about other elements when performing binary search, _except_ the only thing there is to learn: if the target is before or after the recently compared element.

If we would guess that there is a bias in the distribution based on recently seen elements, the guess is at least as likely to be wrong as it is to be right. And if we guess incorrectly, in the worst case, the algorithm degrades to a linear scan.

Unless we have prior knowledge. For example: if there is a particular distribution, or if we know we're dealing with integers without any repetition (i.e. each element is strictly greater than the previous one), etc.

molf

2 か月前議論

Just tried it out and it works great and is really fast! It's a breath of fresh air compared to VS Code. Lots of other editors are fast, but this seems feature complete as well as fast.

Migrating from VS Code was also super simple and integrations with AI assistant seem to just work.

I can definitely appreciate the engineering work that went into it. Loving it so far! Thanks!

molf

3 か月前議論

That sounds terrible! Glad you made it out alive and hopefully recovered well! Out of curiosity: how much did you take per day?

molf

3 か月前議論

It's only a matter of time before laptops get 5G. Macbooks have been rumoured for a while to get cellular modems. [1]

This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.

[1]: https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...

molf

6 か月前議論

That's very interesting! It links to:

https://daniel.haxx.se/blog/2025/10/10/a-new-breed-of-analyz...

and its HN discussion:

https://news.ycombinator.com/item?id=45449348

molf

7 か月前議論

> Every company out there is using the cloud and yet still employs infrastructure engineers

Every company beyond a particular size surely? For many small and medium sized companies hiring an infrastructure team makes just as little sense as hiring kitchen staff to make lunch.

molf

7 か月前議論

Interesting. Is this an issue with RDS?

I use Google Cloud SQL for PostgreSQL and it's been rock solid. No issues; troubleshooting works fine; all extensions we need already installed; can adjust settings where needed.

投稿

Port React compiler to Rust (merged)

PostgreSQL 19 Beta 1 Released

Doctors file complaint against Philip Morris over 'misleading AI tool'

コメント