Companies with 25 employees generally don't have money to pay a dozen SaaS vendors $2k each every month.

Maybe certain niche products that are critical to the business might be worth that much. But a time tracking & invoicing tool? Definitely not. Source: am actively moving away from Harvest due to this ridiculous price hike.

In most of the applications we build or maintain we use PostgreSQL + cloud storage. That's it. And it works very well, also for: storing JSON, full text search, as a queue, as a vector database. Other software may be better at providing those features, but I'm extremely happy we only need to understand & manage PostgreSQL.

About ESO [1]

> We are an intergovernmental organisation established in 1962 supported by 16 Member States (Austria, Belgium, Czechia, Denmark, Finland, France, Germany, Ireland, Italy, the Netherlands, Poland, Portugal, Spain, Sweden, Switzerland and the United Kingdom), our host country Chile and strategic partners.

So Chile has a distinct status, hence the margin...?

[1]: https://www.eso.org/public/about-eso/

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

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

https://playground.react.dev/

- 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/...

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

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

> 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.

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.

Comments URL: https://news.ycombinator.com/item?id=48468500

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48421940

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48410380

Points: 1

# Comments: 0

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

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

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

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.

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

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

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
    }