k_bx

I love the future shaped by two things: Omarchy and Pop!_OS. Both give two different worlds, one serves classic Win/MacOS style users while another is new-age AI-native system.

For me the main one is in-app browser with feedback you can do that's native to its elements lika a network inspector. All "real" browsers felt too broken when I tried them.

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.

We went this path: pg -> peerdb -> clickhouse replica, then pg -> another pg with pg_clickhouse extension -> clickhouse

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.

It's great, but it's not incremental like git, e.g. you do need to make a full backup periodically, unfortunately.

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!

We're now migrating to React, but have some very large Elm projects still in prod.

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.

I was using TimescaleDB some very long time ago, things have changed quite a lot since (it's now even named differently).

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.

Pure by default, type classes (traits), no inheritance, type level lifetime computation. It's not only more functional it's much more type-safe and closer to Haskell in spirit

Most of my team's development happens on beefy desktop machine in incus containers per dev+project (so you run yourname-projname-dev). It has its own tailscale inside so you can open it like regular https website or give to another dev to check out – no need to deploy your branch somewhere, just run it. New dev onboard takes 10 minutes from zero to dev env with VSCode remote development.

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.

That's exactly what I do with Chrome, use it for Google Meet and some websites that work best in Chrome (heavy apps like Figma or whatever). 99% it's Firefox.

I use Chrome because at Google Meet it renders a nice separate window with mute/unmute controls as you switch to another tab and screen share.

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

I've spent long time writing Haskell and now write Rust professionally, so let me tell you something. The stuff where you really want to "program in types" lives beyond Haskell, in languages like Agda, Idris, some HoTT stuff etc. anyways.

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.

> runST :: (forall s. ST s a) -> a

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

What you cannot do is compile-time safety guarantees, and in languages like Rust type system isn't strong enough to do some advanced compile-time guarantees (via types). So no, you cannot do this in basically any language (unless you turn it into Haskell).

I was about to pay him, just maybe not this time, since sublime 2...

Never thought of Zed as Sublime replacement, but now that you've mentioned – why not? I use Sublime only as blazingly fast temp note taking that doesn't lose them on exit, but I see Zed fits the job perfectly. One less close product hopefully!