(McKenna tangent). I like this version of that talk. https://www.youtube.com/watch?v=hL0yfxDe6jE. It's about 12 minutes and animated with some hand-drawn whiteboard drawings. Good stuff.
> In my last performance review, my manager was actually surprised when I told him that I am now more a manager of my own work than actually doing the work.
I think this is very telling. Unless you have a good manager who is paying attention, a lot of them are clueless and just see the hype of 10x ing your developers and don't care about the nuance of (as they say) all the surrounding bits to writing code. And unfortunately, they just repeat this to the people above them, who also read the hype and just see $$ of reducing headcount. (sorry, venting a little)
Great link. I've always been drawn to sqlite3 just from a simplicity and operational point of view. And with tools like "make it easy to replcate" Litestream and "make it easy to use" sqlite-utils, it just becomes easier.
And one of the first patterns I wanted to use was this. Just a read-only event log that's replicated, that is very easy to understand and operate. Kafka is a beast to manage and run. We picked it at my last company -- and it was a mistake, when a simple DB would have sufficed.
I love the idea of SQLite, but I actually really dislike using it.
I think part of my issue is that a lot of uses of it end up having a big global lock on the database file (see: older versions of Emby/Jellyfin) so you can't use it with multiple threads or processes, but I also haven't really ever find a case to use it over other options. I've never really felt the need to do anything like a JOIN or a UNION when doing local configurations, and for anything more complicated than a local configuration, I likely have access to Postgres or something. I mean, the executable for Postgres is only ten megs or twenty on Linux, so it's not even that much bigger than SQLite for modern computers.
I've been through a Vista Equity acquisition. It was not pretty -- they slashed, consolidated and basically ran their one-size-fits-all playbook. The brought in their crew -- which is totally expected -- and then bought other companies in the same vertical. Of course, they all had different tech stacks.
(like ya said, operators is the right word. it felt icky)
At least for the first year, the acquired teams were able to run more or less the same but with new hyped-up-overly-aggressive Vista hotshot managers and then the sh*t-from-above just started raining down.
Also, they hired the worst sw architect / person I've ever had to work with. He wasted so much time and money.
We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc, ie `:erpc.call` underneath rather than FLAME where we are managing a pool of elastic nodes, then rpc'ing them.
Thanks for the reply. Summary: Here's this really cool thing we're doing! Oh, are you wrote something exotic for it? Nope, just regular Erlang goodness that's been around 20 years.
If you look at Elixir keynote for Phoenix.new -- a cool agentic coding tool -- you'll see some hints about a browser control using a API tool call. It's called "web" in the video.
Interesting project. I'm glad Vue is getting the same attention as the Svelte one. And props for digging in to optimize the payloads, and making it diff-able.
Can you just drop existing Vue components in there? Or are their LiveVue specific things you need to add?
You may want to consider Elixir instead. It has an easier syntax and is (don't quote me on this) equivalent in function and purpose with Erlang. Plus you get lots of other goodies like LiveView (notebooks) and a good web stack (Phoenix).
I prefer Erlang because it makes the uniqueness of its paradigm clear. Tail recursion, function matching and, bang, everything is a message!
Elixir makes everything seem like Ruby code and many of those Erlang concepts are hidden away, which is also ok but also takes much away.
My aim with ErlangRED is that both are supported, there is a repository for Elixir code[1] that is included in ErlangRED - so I don't take sides, rather I would like to take advantage of both paradigms.
reply