This isn't particularly convincing, as the pattern -- loosely: keep a websocket open and keep the formerly clientside app state serverside while passing events and pushing diffs -- seems to appear successfully outside of the BEAM vm. For example, blazor serverside (.net) and laravel livewire (php).
I haven't checked but I'm sure there will be a python one too
You are not convinced because you don't know the details. But I am not paid to advocate or to even try to convince. You've been informed now -- from here on it's on you as to whether to remain biased or to expand your horizons.
No need to get defensive. Your comment came across as curmudgeon-y and biased, I called you out for it, you could have agreed to disagree which I would respect. But no, you had to go out of your way to try and strike.
Well, OK. But HN is not the place for that and I refuse to engage further.
It's your right to delude yourself that the runtime does not matter. That's not a discussion I am willing to have though, especially when exactly 100% of my 22+ years of programming experience have demonstrated, time and again, that the runtime inevitably ends up making a lot of difference (sometimes all the difference even).
Or, when you don't have a runtime -- as is the case with Rust, kinda sorta I mean because technically `tokio` can be classified as a runtime -- then you rely on a stricter compiler.
Both strategies work pretty well.
I am not shitting on C# / .NET, they are solid as hell. But some things the BEAM VM just does better and everyone who worked with old-school VMs (in my case the JVM) and the BEAM VM can tell you that.
But again, you do you, think what you will. ¯\_(ツ)_/¯
I haven't checked but I'm sure there will be a python one too