9 ms·
Phoenix 1.4.0 released
- ilovecaching 8y agoI wonder what the biggest deployment of Phoenix is at this point. 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.
- lostcolony 8y agoSingle maintainer in the sense of ownership, not in PRs. Look at github; 101 contributors.
- chrismccord 8y agoCowboy maintainership has not been an issue, but there are other options in the Erlang and Elixir ecosystem for webservers, ie elli, chatterbox, and Ace. And to be fair, chatterbox is an Erlang http2 server that has been around for 3 years now. Also please consider blatantly discounting the ecosystem and casting doubt on well-maintained projects isn't a very high value-add to this discussion :) 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: https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs... 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.
- bertjk 8y agoWhat 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?
- lobo_tuerto 8y agoYes you are. You'd need to take a look at what OTP brings to the table of supervised-processes and fault tolerance. Maybe this can help shed some light on it: http://blog.plataformatec.com.br/2018/04/elixir-processes-and-this-thing-called-otp/ http://blog.plataformatec.com.br/2018/04/elixir-processes-an...
- enraged_camel 8y agoPlease stop spreading FUD about Erlang/Elixir at every opportunity, thank you.
- mercer 8y agoAt this point I kinda miss OP's traditional mentioning of Rust as a better alternative...
- querulous 8y agoit'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
- brightball 8y agoNot really. As mentioned elsewhere, there are many contributors to Cowboy and major companies using it as well. Heroku, AWS uses it in Cloudfront last I checked, Incapsula too.
- querulous 8y agoheroku uses a fork of cowboy that diverged in 2013 and has less than 100 commits since then, including only 8 since 2014 cloudfront does not use cowboy
- innocentoldguy 8y agoPerhaps, but Go’s threading model uses a lot more memory than Erlang and Elixer and Go’s threading is handled in public memory, whereas Erlang and Elixir processes are all protected in private memory. Erlang and Elixir’s supervision tree is also pretty damn great. OTP is solid and has been thoroughly proven. Elixir also handles dependencies much better than Go, in my opinion. I’m sure Go is nice too, but I don’t think the backhanded compliment about Cowboy, Erlang, and Elixir is warranted.
- MaxBarraclough 8y ago> Go’s threading model uses a lot more memory than Erlang and Elixer Interesting. Can you say why?
- Exuma 8y agoAre you nuts? Elixir + Phx for web is downright awesome...
- mrinterweb 8y agoHeroku uses cowboy for their routing layer. If you inspect the headers in a response from an app served on Heroku, cowboy is the server. I would guess Heroku is the largest cowboy deployment. As for largest Phoenix deployment, I'm unsure.
- ch4s3 8y agoNote that they use a pre 1.0 fork that they customized a lot.
- whitepoplar 8y agoCongrats and a big thank you to the Phoenix team! Any word on the previously discussed metrics telemetry? EDIT: Oops. Didn't read bottom of post.
- lewapkon 8y agoIt's mentioned in the article. https://github.com/beam-telemetry/telemetry https://github.com/beam-telemetry/telemetry
- perishabledave 8y agoOne thing worth highlighting in the post is that Phoenix now uses Ecto 3.0. This latest version of Ecto separates Ecto's data mapping and validation from Ecto's SQL adapters. Practically this means you can use Ecto's changesets when you either don't need persistence or aren't using a SQL database. Additionally there are a number of features that make Ecto 3.0 a great release: http://blog.plataformatec.com.br/2018/10/a-sneak-peek-at-ecto-3-0-breaking-changes/ http://blog.plataformatec.com.br/2018/10/a-sneak-peek-at-ect...
- _asummers 8y agoThe best one is piping aggregate and other functions in queries! Something like: from foo in Foos, select: foo.id |> filter(foo.bar > 3) |> count()
- s0l1dsnak3123 8y agoI've used Ecto in the past to build API validation, so having Ecto and its DB adapters separated is a great move in my opinion.
- sergiotapia 8y agoThank you Phoenix team - changed my career for the better. My stress levels dropped drastically since moving to Elixir and Phoenix. Immutable language, blazing fast predictable performance, super quick test suite, real-time capabilities that don't require gigabytes of RAM... the list goes on.
- jbhatab 8y agoI can't wait for telemetry. Better monitoring will be a huge addition to the ecosystem!
- ch4s3 8y agoAgreed, I'm pretty excited to wire up some prod apps.
- dudul 8y agoKind of feel bad for this one: https://www.manning.com/books/phoenix-in-action https://www.manning.com/books/phoenix-in-action 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.
- flocial 8y agoIt's over 1 year for an albeit big point release. Not necessarily fast compared to Rails even in the early days [1]. I think the main problem is there aren't enough quality independent tech blogs like when Rails came onto the scene. 1. http://railsapps.github.io/rails-release-history.html http://railsapps.github.io/rails-release-history.html
- ch4s3 8y agoThere 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.
- flocial 8y agoLess releases with breaking changes definitely feels like a feature to me at this point. It's also nice that many of the libraries Phoenix depends on are decoupled from the core.
- chrismccord 8y agoThis book actually should be in great shape since Phoenix 1.3 included the larger re-org of project code. A book written for Phoenix 1.3 will be entirely relevant for Phoenix 1.4. I think we had a total of two deprecations, with no breaking changes. As another commenter said, our last major 1.3 release was 2017-07-28, so if anything, I would expect folks asking us to speed up the release cycle a bit :)
- ledgerdev 8y agoBeen waiting for this release to start playing with Phoenix. 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?
- ch4s3 8y agoI still usually use react or similar with Phoenix, but it’s pretty easy to sprinkle things like that across SSR pages. It’s a really great tool overall and I find that one I’m in a good groove I get a ton done in Elixir. The tooling is amazing as well. My team runs credo and dialyzer alongside tests in ci, and the whole thing finishes in 2 minutes, it’s really a pleasure to work with.
- chrismccord 8y agoThere's no public repo yet, but I'd like to open it up soon. I've been ironing out the details of the programming model before opening it up – namely nested live views and how the remote client spawns and reconnects to the server processes. I made solid progress last week, and posted a sneak peak of the nested views and error recovery: https://twitter.com/chris_mccord/status/1059273315666350080 https://twitter.com/chris_mccord/status/1059273315666350080
- sergiotapia 8y agoabsolute unit This is terrific work!!!
- erik14th 8y agoYay for webpack as default. My perception of phoenix is not only that it is the best in class but that it also keeps getting better instead of bloated.
- goliatone 8y agoNot 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.
- dmix 8y ago> 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.
- thrower123 8y agoI feel like webpack has "succeeded" to the same degree that make has succeeded. Enforce your shit, new tools
- chrismccord 8y agoThere'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.
- samgranieri 8y agoAnd now I can't wait for Phoenix LiveView!
- willyk 8y agoBig thanks and props to the team on this, very exciting! Looking forward to pitching in on the guides or other areas where some contrib help may be needed.
- sb8244 8y agoThe Phoenix team has been very accessible for help and growth of the language. Very happy to work with it every day and to be able to contribute back occasionally!
- bsaul 8y agoIs there any benchmark comparing two architectures , one using OTP, the other using containers + kubernetes ( let’s say in go or java) ? In terms of availability, performance, maintenance cost, etc.
- pg_bot 8y agoYou can use Docker + containers with OTP, they are not mutually exclusive. Daniel Azuma gave a talk at the most recent Elixirconf about this subject.[0] [0]: https://www.youtube.com/watch?v=nLApFANtkHs https://www.youtube.com/watch?v=nLApFANtkHs
- ch4s3 8y agoI’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.
- jillesvangurp 8y agoFun fact, Firefox used to be called phoenix. The rename happened over a trademark for another product called phoenix (a database if I recall correctly).
- dagw 8y agoThe rename happened over a trademark for another product called phoenix (a database if I recall correctly). 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.
- _asummers 8y agoThat 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?"
- dagw 8y agoYea, you'd think if you're forced to change the name of your product due to the name clashing with and existing software project/company, you'd take some time to make sure the new name you chose doesn't also clash with an existing software project/company.
- jillesvangurp 8y agoHah, true. I completely forgot about it being called Firebird in between.
- rishav_sharan 8y agoHave a question for phoenix veterans. The server performance in benchmarks like techempower have not been stellar, yet concurrency is one of its most touted features. If i wanted to build an app like hackernews and host it on digital ocean free drop, how many concurrent users can i hope to serve with request latency less than 100ms. A rough ballpark figure here will help me visualise phoenix's performance better.
- OoooooooO 8y agoHere's some benchmark for Phoenix + Digital Ocean drop - https://www.cogini.com/blog/benchmarking-phoenix-on-digital-ocean/ https://www.cogini.com/blog/benchmarking-phoenix-on-digital-.... But without database stuff. And here: https://elixirforum.com/t/7-5-second-average-page-load-speed-for-200-visitors-hitting-a-phoenix-driven-website-on-a-5-month-digital-ocean-droplet/15073/5 https://elixirforum.com/t/7-5-second-average-page-load-speed... "It’s my fault for the inline Markdown, really. The pages that don’t do that handle over 1k/second."
- conradfr 8y agoSadly this thread didn't pick up much but I found this https://www.cogini.com/blog/benchmarking-phoenix-on-digital-ocean/ https://www.cogini.com/blog/benchmarking-phoenix-on-digital-...
- fastbmk 8y agoIf BEAM/Erlang/Elixir is so great for web development, why the leading web company Google would bother to develop Golang?
- fastbmk 8y agoLiveView technology won't work well with high latency internet connection. In other words, on most mobile devices. Which is 50%+ part of the market. Also there may be privacy concerns with sending every browser event to the server.
- fastbmk 8y agoWhen you talk about BEAM supervision magic, you forget that in the end it's just a regular process of the OS. If the BEAM's process is killed, supervision magic won't work. It's not any different from the Golang's process of the same nature.