HackerTrans
TopNewTrendsCommentsPastAskShowJobs

molf

1,796 karmajoined 14 anni fa
https://voormedia.com

https://zxcv.art

Submissions

Port React compiler to Rust (merged)

github.com
4 points·by molf·mese scorso·0 comments

PostgreSQL 19 Beta 1 Released

postgresql.org
3 points·by molf·mese scorso·0 comments

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

dutchnews.nl
1 points·by molf·mese scorso·0 comments

comments

molf
·l’altro ieri·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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
·mese scorso·discuss
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 mesi fa·discuss
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 mesi fa·discuss
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 mesi fa·discuss
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 mesi fa·discuss
> 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 mesi fa·discuss
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 mesi fa·discuss
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 mesi fa·discuss
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 mesi fa·discuss
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 mesi fa·discuss
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 mesi fa·discuss
> 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 mesi fa·discuss
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.