The bad part of the setup is: you still have to tell it to ssh into your dev container and make changes there (since that's where the linux running dev server is). Most work still via cli, which is faster and much more lightweight in token usage.

This way we keep querying without changing the query language (use same postgres syntax), but switch connection port for analytics query. Experience so far: made 3 PRs to pg_clickhouse (1 merged), otherwise works pretty well.

If something like pgrust would work even better/easier – would definitely check it out instead.

I didn't understand that, and after 5 months of usage caught my backblaze to be using 40TB, and nightly restores taking forever for other reasons. So: not ideal, and be careful to check!

The biggest thing for me from practical perspective was to "freeze" some pieces of DOM to be guaranteed to not change/re-created, so that it plays well with some external JS libraries expecting some nodes to not change and stay vanilla.

Another is ability to extend Elm's debugger to filter out big noisy data to keep it usable for our project.

Third is when your data is too big -- it just sometimes fails with "recursion limit" that's hard to debug due to the nature of the langauge.

Otherwise – it's a very beautiful little language that still feels quite modern and easy to work with IMO.

In my current setup I was thinking on doing both: upgrading postgresql to timescaledb (to archive old data etc.), and to deploy ClickHouse in parallel. I'm still considering whether to go big on PeerDB to get ClickHouse mirror or just deploy it separately without additional fragility layer.

Would you not recommend using timescaledb at all? I definitely want to avoid alpha-quality software pain, since PostgreSQL is one of the most rock-solid parts of the stack at the moment.

I would really love if apple could give inexpensive way to run amd64 containers for situations when dev wants to use their own hardware. We've used LIMA for now, was too much of a hussle. But if there's a more native experience – would give it another try.

Curious if Google plans to allow other browsers doing that too.

In principle the more developed the type system is – the closer it to not distinct between types and values. Caviat is that its "type inference" gets worse.

So, in those more developed languages, you could have type-level proofs (guarantees) that your calculator produces correct results, as a proof, as theorems. That 2+3 will be 5, not as runtime test assertion, but as a theorem, that no other result is possible no matter what happens. Or that your parser will never fail on valid JSON etc. but nobody guarantees it's going to be a pleasant thing to write, maintain, and debug. And compile times will probably be terrible.

> The rank-2 type (that is, the type s is scoped within the parenthesis and can't escape) of runST ensures that the mutable references created inside the computation cannot escape due to being tagged with the type s. Internally, all sorts of imperative nonsense may occur. Externally, the function is pure. The world outside the boundary gets none of the mutation, only the result.

C does not have parametric polymorphism, nor rank-2 quantifications, so no, this cannot be done in C.

I disagree about "tough". Emacs has changed for the better in new releases quite drastically in the last years in my experience.