Phoenix 1.4.0 released (opens in new tab)

What does this built in failure recovery mean, functionally?

I mean consider e.g. some code in a standard Rails monolith raises an Exception. The exception bubbles up and is caught by a middleware that displays a status 500 page. Isn't that basically failure recovery too? Or for the same Rails monolith, one worker process hits bad code that eats memory until it is killed by an OOM-killer. Unicorn/puma notices that the worker process is missing and restarts it. Is that more analogous? In either case the request is failed but the server pretty much "recovers", ready to accept new requests.

So what is unique about the supervised processes with built-in failure recovery approach? Or am I viewing this at the wrong level of resolution or something?

Note that they use a pre 1.0 fork that they customized a lot.

At this point I kinda miss OP's traditional mentioning of Rust as a better alternative...

it's a legitimate concern. the only alternatives to cowboy for http2 are chatterbox and ace which are both single maintainer and, as far as i know, not in wide use (even by erlang standards). for http1 you have elli but it's also never been widely deployed and it's unmaintained as of years ago

> Go’s threading model uses a lot more memory than Erlang and Elixer

Interesting. Can you say why?

absolute unit

This is terrific work!!!

Make sure you're using RC of Dialyxir with the new pretty printed error messaging!

There's also Texas[1], which was presented on the same conference as LiveView.

[1] https://gitlab.com/dgmcguire/texas

Yes the book will probably be mostly relevant technically. But from a marketing point of view, it's dead. If I know nothing about phoenix, I check the website and see that the current version is 1.4, am I gonna buy the book that covers up to 1.3?

Re: my comment about release cycle, you're right. It was probably more applicable to elixir than phoenix.

There aren’t as many, true, but I’m not sure you necessarily need them most of the time. You aren’t going to end up tangling with ActiveRecord, upgrading for two months, or running into bizarre class load issues. These just less magic to worry about.

The book OP mentioned is not an official one. The official book [1] is being kept up-to-date

[1] https://pragprog.com/book/phoenix14/programming-phoenix-1-4

There's no panacea when it comes to front-end build tools, but the webpack 4 release vastly improved configuration and docs, which was a big reason for us to make the jump. We've maintained the old brunch workflow for non-js pros, where you place js in assets/js and css in assets/css and things Just Work™, so folks fond of the old brunch way can continue to handle assets exactly as before, but webpack will be used underneath. I also like to think we now strike a nice balance between zero hassle asset bundling and professional front-end engineers using phx.new and quickly getting to work.

> Not to take away from your excitement or the validity of the change, but non frontenders find webpack rather bloated. To be fair, I’ve met more than one front-end developer with the same perception.

Regardless it still seems to be the build system most major platforms and large orgs are choosing to integrate with (for better or worse). Which comes with its own benefits.

It might not be the best build system for a raw new js project but in terms of broad support, stability, adoption rates, 'no one ever got fired for choosing IBM', etc it seems to be the system of choice.

Those were two separate points, I should have used a linebreak there in retrospect.

My point was that if you look at the changes and new features, all of it seems to me as stuff that improves core functionality, there's no feature creep.

Yay webpack because that's what I use so less work for me next time I start a new phoenix project (:

I don't love Webpack by any means, but it's a helluva lot better than the disaster that was Brunch.

(but hey, I'm still stuck back whenever Gulp was popular, so don't take me too seriously!)

That story is kind of funny.

"Let's call it Phoenix!" gets sued

"Uh okay, a Phoenix is like a fire bird right? That sounds pretty cool, let's do that!" gets called out

"Okay well what's another animal we can use? How about fox?"

Hah, true. I completely forgot about it being called Firebird in between.

thanks for your effort, noted.

I’ve been using ECS and it’s been a good way to write stateful apps that can dump state on tear down ore crash and start back up and keep working.