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'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.
> 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).
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!
I just realized that `apt install emacs-nox` is a great editor in containers and VMs. I just have to disable it every damn time (for regular and root user). Defaults would be better.
I was proposing to make default where those files are not created, since Emacs is actually surprisingly great out of the box with no configuration, except for this "little" thing. Apparrently, some people believe it's perfect as it is
I do too, it’s just that I’ve realised that emacs-nox is awesome container / vm editor out of the box, this backup thing is the only most annoying part (and Ubuntu 22.04 emacs packages expired cert)
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.