Or even worse, you own a Mac (say, through work), but aren't entirely in the Apple ecosystem and don't want to relearn everything and fight muscle memory every time you switch devices.
I have (but or course Apple make it hard to do so you need third party software). But that doesn't help with special mac only software that has it's own style, like Arc or Zed.
Most people who say “all editors have vim keybindings just use that” miss the fact that bindings or not, a lot of vim’s functionality is just not available on other editors.
And that Vim is more than its keybindings, despite the often repeated jokes.
Tabs, window splits, search and countless other details may work very differently, and usually not completely with the keyboard.
I think they mean compared to cross-platform apps that feel equally weird on every system.
There’s some talk in the Mac world about “Mac-assed Mac apps”. I use BBEdit as my main editor because it feels right. The default shortcuts are like every other Mac app. You can use standard Mac tools like AppleScript to automate it. It uses the same fonts, widgets, and menu systems as everything else. It’s made for that environment and it shows in a million ways.
VSCode is a marvel of engineering and I love that it exists. It also feels uncanny-valley “off” on my Mac in ways that make my brain itch, so I don’t use it. Same with Obsidian: it’s a brilliant app, but it bugs me. It’s not bad in any way, it’s just not the right choice for me.
Just to make it clear: you don't have to write stateful apps, just because you can. It's still possible to have the more traditional stateless model like Rails.
If you do write a stateful app, and run it in k8s, you can have state handover to a newly created pod. It works pretty well.
Well, let’s assume we are talking about a webshop. Every user is represented as an actor, a cart might be a state.
So cart as a state should be stored somewhere else, let’s say redis.
And every single read/write operation would be a network hop. What are the benefits of using actor model then ?
As for state handover between pods - what are the keywords to look for ?
What you describe sounds more like Orleans grains. Erlang's lightweight processes serve a different purpose than actors or objects, they're really about fault tolerance.
A typical Phoenix app spawns one process for every HTTP request, websocket channel, or DB connection, for example. All these things have a lifetime shorter or equal to the pod's.
The VM gives guarantees and tools to ensure one of these process crashing will not affect the others, unless you want it to. For instance, if a request crashes, its memory will be reclaimed, open files will be closed, DB connections will be re-opened, the exit reason will be logged, error metrics incremented, etc. This is possible with no defensive programming like try/catch and so on, because the processes are isolated. For example they don't share memory, so it's always safe to deallocate something if its owner process died.
This gives a two-layer safety net that allows for very reliable apps, where the VM protects you against bugs in your own code, and Kubernetes protects you against bugs in Erlang, or really catastrophic failures. There's a good blog post on this: http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-...
What i had in mind is some kind of gen_fsm or gen_statemachine.
For stateless applications it is pretty obvious how supervision trees can improve the reliability. Essentially the only ‘state’ there is request itself. Worst case scenario client would just retry.
But with some state involved it becomes not as simple.
Essentially the answer to my question probably would be like : “you should store the state in the external system, and design your system in such a way that stored state is always consistent. In case of failure supervisor will respawn the process and it will recreate what it needs from the saved state”
> you should store the state in the external system
Disk works too, but if you're multi-node this means you now have a distributed database embedded in your system, which may or may not be your goal :)
RabbitMQ does this, they developed a library for "persistent, fault-tolerant and replicated state machines" based on Raft: https://github.com/rabbitmq/ra.
Ahh great. “On Erlang, State and Crashes” is exactly answering my question.
As for disks - in good old times when servers were pets, not cattle that was a good idea. But now when the servers are as ephemeral as actors, we need to approach it differently, hence my original question.
Sidenote - i have a strange relationship with Erlang. I first learned it in 2006, liked the idea and was hoping it will eat the world as scale increases. I even contacted Joe Armstrong in hope to translate his thesis. Zero Erlang books in the world at the time. Then i did some load tests using Tsung in 2012.
Then i used akka.net in 2018. But till this day i never had a chance to properly use in production.
> you should store the state in the external system
It's an old talk, but this one has a strategy for robustly persisting state across ephemeral containers. The example here is running a multiplayer game server while doing code updates etc. using Horde and CRDTs
Thank you, i was not aware of the Horde package. Definitely worth looking.
I was also thinking what should happen in case of ‘electricity disappears’ scenario, but came to a conclusion that it is good old ‘save the state you care about’
Quite a lot of condemning, demanding and calling for actions from the western society. Yet, not once was the word "war" mentioned. Not once were the actions of the Russian government and Putin condemned.
How about you - Roskomsvoboda focus your energy on stopping the war, so Ukrainians can also enjoy the benefits of new technologies?
Agreed. I haven't been this excited and motivated by any technology since I got into rails 10 years ago. It's been a great cure for the jadedness I've been feeling about our field in the past couple of years.
Especially a well written and researched bug report. Many typical users lack the skill to do that, and a software developer would have an ample amount of it.
