NaN === NaN; // -> false
This is actually correct, in any language. As per the floating point spec NaN equals nothing, not even itself. To return anything else would be failing the spec, so this is correct, not a javascript’ism (which has plenty of broken things to choose from).
As much as I want to agree with most of the article, it comes off a bit… high and mighty, and there are definitely some issues, like the fact it’s trying to go back to the ol’ RPC style calls from the long past.
And you don’t need immutability, you need either safe or no aliasing, which yes means you need immutability in most languages, but in languages like Rust you don’t, it has safe aliasing, even mutably, which means you can have both performance and safety of code where pure immutability has overhead you can’t get rid of. Pure functions are good though, to make a function impure in rust means you have to touch unsafe or something wrapping unsafe, lol, and of course without the aliasing issues then it’s safe to do as long as the unsafe code is written safe.
The Erlang VM is awesome though, especially as an orchestrational glue between parts written in native fast languages like rust. Rust can do what the Erlang VM does for its actor stuff, but it doesn’t have a great pattern for Erlang VM’s multi-node, not to say you can’t do it, just takes a lot more work.
Phoenix LiveView is just the old made new again, definitely harkens back to my Wt and N2o and such days, useful style to program pages in for server-driven code. ^.^
Phoenix channels are such a fascinating abstraction that even Rocket.rs is copying it, same names and terminology, lol.
SPA’s do still have their place however, especially if the client need to do a lot of its own calculations or little to no server communication or if it needs to run offline. It would be awesome to support both static, server side dynamic, (LiveView) and client-side dynamic (SPA) all in the same codebase though.