Hacker News Reader

Comment by klabb3 | Hacker News Reader

Generally speaking this is the model I’ve always been wanted to build apps in. Event oriented, bidirectional realtime updates with server, ordered events, local and remote state...

I didn’t know about LiveView and never used erlang-family languages, but definitely they’re onto something. The traditional request-response model is many times causing a lot of subtle problems with consistency and staleness.

A wishful (probably also controversial) thought: if the last decade was about integrating FP concepts into mainstream languages, then I hope the next decade will be oriented around integrating stateful message-oriented (reactive?) programming into the mainstream full stack.

View on HN

There are LiveView backends written in Javascript (http://liveviewjs.com), Go (https://github.com/canopyclimate/golive), Java (https://github.com/floodfx/undead), and Python (https://github.com/ogrodnek/pyview).

Disclaimer: I wrote or helped write the first three.

You can use asdf to install erlang/BEAM/OTP and elixir, takes a few minutes if you have some previous experience with the tool.

Either way it'll probably take about two hours to have your first rudimentary Phoenix chat application loaded in a browser if you follow some guides and tinker around a bit.

I would strongly recommend using mise instead of asdf. It's a drop in replacement that is just flat out better for most people.

curious, what makes it better? asdf has always just worked for me, but this is the first time i’ve heard of mise, so i’m wondering what i’m potentially missing out on

Maybe it works better with tmux?

The mise docs have a great comparison page: https://mise.jdx.dev/dev-tools/comparison-to-asdf.html

In personal experience, all of these have held true. Mise is just easier to use than asdf and I don't have to `asdf -h` every time I have to use it. The performance is significantly better and I can use mise exec in shebangs without sacrificing too much startup time. And it's easier to install because it's a SLSE. I wouldn't say it's worth deliberately switching from asdf (though I would, because asdf's CLI is an endless annoyance to me), but if you're on a new machine I don't think there is a reason to use asdf over mise.

Anyone who wants "nodejs latest:20" in their .tool-versions file is probably confused. The point of .tool-versions is to pin a particular version in your source control so you know your whole team is on the same version in that branch. Getting the latest revision whenever you install means pointless drift.

Are you really sensitive to the minor/patch versions of node? I don't think it should make a difference whether you're using 20.9 or 20.12, and to me to that would be a bigger red flag.

Either way, I don't think many people are checking in tool-versions files. Most JS templates specify a range of node versions they work on and leave it to you to specify which one. I don't think this is unusual for most other languages I use, like ruby.

No, I’m not generally sensitive to a point release but it’s pointless to allow drift anyway. I have had point revisions of docker containers break CI pipelines before and it’s unpleasant.

> I hope the next decade will be oriented around integrating stateful message-oriented (reactive?) programming into the mainstream full stack

Also known as MVC before Rails decided to redefine the term.

Java redefined the term MVC a long time after Smalltalk originally defined the term in the 70's. Rails didn't redefine the term, it much later copied the (poorly) redefined term from Java and tweaked it a little. Smalltalk MVC and Java/Rails MVC are EXTREMELY different. Java and Ruby's MVC are quite similar (and loosely based on a superficial misunderstanding Smalltalk's MVC).

Maybe? Most good ideas have been out there for decades. Getting the execution right is what’s hard.

No, MVC is at best orthogonal to message-passing.

Reply on news.ycombinator.com