Additionally there are a number of features that make Ecto 3.0 a great release:
from foo in Foos,
select: foo.id |> filter(foo.bar > 3) |> count()
I'm super interested to see how liveview turns out. Can it be a game changer and free us from JS framework morass? Anyone know if there's a public liveview repo/work to look at somewhere?
This is terrific work!!!
Immutable language, blazing fast predictable performance, super quick test suite, real-time capabilities that don't require gigabytes of RAM... the list goes on.
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.
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 (:
(but hey, I'm still stuck back whenever Gulp was popular, so don't take me too seriously!)
Still a MEAP, and only covers up to 1.3
Elixir and Phoenix seem to have very fast release cycles. I don't know if it's a good or a bad thing. It's great to add a lot of features, or remove the ones that don't really work, but it also renders literature obsolete pretty quickly.
Re: my comment about release cycle, you're right. It was probably more applicable to elixir than phoenix.
EDIT: Oops. Didn't read bottom of post.
It's not any different from the Golang's process of the same nature.
Also there may be privacy concerns with sending every browser event to the server.
They first renamed it from Phoenix to Firebird due to a trademark dispute with Phoenix the BIOS company (which doesn't exist any more). They then promptly got called out by Firebird the Open Source database project and eventually had to change their name again to Firefox.
"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?"
I've written a few cowboy apps, but my professional Erlang experience has only been with chat servers that do not use HTTP. I'm not sure if I'd choose Erlang to build web services in. Cowboy is a single maintainer project, and Go has had HTTP2 support for ages now.
For other readers: you might choose Erlang or Elixir for web services if you want high scalability with distributed communication for free, which is super important for example when building any real-time web service. It's what allows Phoenix to support millions of channel connections on a single server:
Erlang and Elixir's concurrency model is also unique from what Go offers out of the box in that the way you build applications is via supervised processes with built-in failure recovery.
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?
Maybe this can help shed some light on it: http://blog.plataformatec.com.br/2018/04/elixir-processes-an...
cloudfront does not use cowboy
Interesting. Can you say why?