Hacker News Reader

Comment by jfabre | Hacker News Reader

You should try phoenix and elixir, only been playing with them for less than a week and as a long time rails/ruby developer this is what it feels like again.

View on HN

I bounced from Rails to Phoenix and couldn't be happier. I've done lots of functional programming before my Ruby days but never saw it coordinated in such a way that made sense to me. And since I only do web dev it was a perfect fit.

That said, I'm _really_ excited to get into all the goodness that Rails 7 has to offer. I really thought they lost their way with the whole webpacker debacle. I recently installed a fresh Rails 7 app and the word webpack doesn't even exist anymore! It's like a breath of fresh air to be done with that. Those were some dark days. (I'm exaggerating only a little)

Currently using Jumpstart Rails ( https://jumpstartrails.com/ ) with esbuild for a personal project and it's so fast..

I'm also a Rails dev, currently doing Advent of Code in Elixir, I haven't tried Phoenix yet, but writing Elixir feels a lot like writing Ruby for the first time. It's the same kind of sexy, of-course-you-can-do-that feeling.

That's really funny, my perception of Elixir is generally the sentiment "of course you can't do that". (that's a good thing).

Funny, you're also right. Of course you can't do that weird hacky thing you could totally do in Ruby but maybe shouldn't.

I meant something more like "of course there's a function for that with the name you'd expect".

For me Elixir didn't feel too much like Ruby, but Phoenix sure felt a lot like Rails. YMMV since Phoenix has gradually become more and more of its own thing than it felt like in 2016 when I learned it.

There's really nothing I miss about Ruby for web dev and Elixir feels like a complete win to me these days. Ruby is still far nicer for unix-y scripting, though.

Elixir and Ruby have nothing in common as languages and ecosystems, I really don't get why the 2 keep being brought up together. Oh I do get it - whenever someone mentions Ruby some Elixir user will say - hey have u tried Elixir?

Ruby and Elixir do have surface syntax in common, and Rails and Phoenix are clearly from the same conceptual direction. They're more similar than, say, Rails and Spring Boot.

This is not surprising: the Elixir folks were fairly high-visibility in the Ruby community before they did Elixir and Phoenix.

I'll give you surface syntax in common, other than that not much. I think a Rails dev would have a much easier time picking up Django or Laravel than Phoenix. How hard is the switch from Rails to Django? Probably trivial. But Ruby to Elixir is a mind shift.

Ruby to Elixir is a mind shift. Rails to Phoenix...I don't think so.

But most Rails programmers write Rails, not Ruby, and it's important to differentiate them. Ruby is a big playground. Rails is...not, by design. (This is why I do not like Rails, personally--if I am choosing to write code in Ruby, it's because I expect to need to get weird with it.)

Rails->Phoenix omits a lot of the stuff that makes Elixir cool, both in itself and in OTP, but that's not a bad thing and I do think the transfer isn't too onerous for somebody coming purely from Rails.

> But most Rails programmers write Rails, not Ruby

You're really exaggerating.

I'm really not. I've built tools and systems around Rails for a long time. Most Rails programmers I've worked with live in the controller and the view. Absolutely there are those who do not--and they're often building libraries and tooling for those who do. IME, at the hireable junior/mid levels, Rails driving is pretty tightly coupled to the framework--this is often a positive, to be clear, and not a dunk on anybody. This is the baseline way to get a web application out the door.

Roughly equivalent interfaces exist in Phoenix, and the mapping isn't quite 1:1 but it's close enough that the adjustment is an adjustment, I think, and not a re-learning.

I partly agree with what you're saying but still - you're exaggerating. Doing Rails without a decent knowledge in Ruby is exactly what you said - it's being a junior. You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry. That's what being a junior is like in any language.

I don't think we can compare languages based solely on the experience of juniors. I'm not saying it's irrelevant, it is, but it's only a part of what writing software is. In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction.

But I do agree that Rails is a kind of dialect of Ruby and that you can get pretty far with Rails without being great in Ruby (you still need to be decent though, no way of getting around that).

> Most Rails programmers I've worked with live in the controller and the view

Where is the business logic at? They also write services or something similar or stick it in the Model. Whatever isn't ActiveRecord will be pure Ruby - Rails has no opinions there.

> You'll rely on the existing codebase without any ability to provide your own ideas, only shifting code from here to there without fully understanding what you're doing and will always need a senior whenever things go awry.

Absolutely, and I would submit that this is most developers' experience up until a senior-ish role. Not title, you can have juniors doing this, but the pyramid of tool-users versus tool-makers.

> In the end of the day you need the seniors and people who really get it to maintain the code and steer the ship in the right direction.

Again agreed--but jeez, there are just so many fewer tool-makers at most places I've found myself. (This worked out great for me early in my career because there were tons of vacuums to start doing that work even in my first year out of college--building systems that other people could rely on to go faster, because nobody else was doing it!) Thinking about it, this impression perhaps sticks more because of the businesses I consulted for, which is perhaps where my perspective comes from--hiring uncritically 'til you're in a pit where you're paying the medium bucks to get somebody to come dig you out.

> Where is the business logic at? They also write services or something similar or stick it in the Model.

Found the guy who hasn't seen too many 10KLOC controllers in his time out there. ;)

You may be right that I am grim about this, but at the same time, reading your description makes me go "I haven't seen too many places that actually do-it-right". The truth's probably somewhere in the middle, and outliers exist on both sides. But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of. They make a lot of money, too. (Fortunately for me, they brought me in for devops stuff, not "please save our megamonolith".)

> But yeah, I've absolutely been consulting for more than one company whose primary product was thin models, gargantuan controllers, and no service abstraction to speak of.

I don't get why this is still happening. It's kinda common wisdom now to not let your controllers get fat. I"m not saying that fat models are great but as a community we kinda agree that most business logic stuff is easier tested on the model/service and should be placed there. CTO's/team leaders have to be real sloppy to let teams build code as you describe At the same time - being a consultant, don't you more often than not see codebases in bad state? I mean those are the ones that usually need consulting. So maybe you have an overly negative view on how Rails projects usually look.

> Rails->Phoenix omits a lot of the stuff that makes Elixir cool, both in itself and in OTP

How do you think Phoenix could better take advantage of Elixir and OTP? IMO, it already is doing plenty to take advantage of what's cool about OTP, through channels and especially LiveView. I suppose Phoenix apps could use Mnesia instead of relational databases. But would the benefits actually outweigh the costs?

> Rails->Phoenix omits a lot of the stuff that makes Elixir cool, both in itself and in OTP, but that's not a bad thing and I do think the transfer isn't too onerous for somebody coming purely from Rails.

I'm not following you here. Could you please explain your position a bit more?

The reason I'm confused by your commentary is that Phoenix makes extensive use of OTP and since it is just Elixir + macros, there is nothing at all limiting you from employing every Elixir (and Erlang, for that matter) feature you want to in your Phoenix apps.

Sorry - omits is the wrong word, because of course Phoenix uses that stuff. More that in my experience, for the kind of "in the framework" developer that I've run into in the Rails space, the mapping to using Phoenix is very simple and doesn't demand of the end user the conscious use of processes, genservers, etc. -- it can, and from POV often seems to be used as, plug-and-chug. This totally isn't a criticism either, I want to stress; it's the mark of a good framework, that you don't necessarily have to care about that stuff to ship a thing.

At my current company, we use Phoenix and we use a lot of its bells and whistles. But we also have a lot of people who understand OTP--definitely way more than I do. I also see people ship Phoenix apps without getting deep into that when their needs are relatively small.

I have extensive experience with Elixir/Phoenix, Ruby on Rails, Laravel, and Django and I have to say I disagree. Rails and Phoenix are both opinionated in similar ways, both have similar generators, both have excellent/similar tooling, and many of the same ideas exist in both (e.g., Channels and Action Cable). I view Elixir/Phoenix as a natural evolution of Ruby/Rails.

The creator of Elixir was on the Rails core team and involved in the Ruby community, even for a little while after Elixir was released (until about the time Phoenix came around). The Ruby community is where Elixir gained a big chunk of its initial attention from.

That doesn't mean much. He came from Rails and then switched direction to a functional, Erlang based new language. The historical "initial traction" also doesn't mean much. The two languages aren't similar at all.

In terms of ease of hosting?

I'm considering migrating to Phoenix and my biggest concern is ease of deployment

I hear fly.io is good.

It's great

It's excellent, and a pretty generous free-tier i think.

I've just tried heroku so far and took me about 30 min to deploy my prototype, but I read there are limitations. Go take a look at fly.io and I think there's also another one that specialize in elixir hosting. Once I understand elixir/erlang better, I will probably want to host there.

https://www.gigalixir.com/ is likely what you're referencing. Since they're focused on Elixir first it supports a buncha the nice things the BEAM supports, such as native clustering, hot upgrades, and opening a REPL to a running cluster.

I got around to trying https://render.com/ recently, it's also pretty easy and cheaper than Heroku, I think they support Phoenix/Elixir but I've never used it or tried. Also side note Heroku seems to have just stalled and atrophied as a product since the Salesforce acquisition, still one of the easiest hosts though.

Yes, they support Elixir (including clustered apps) and it's very easy. I wrote a tutorial and did a 6 minute screencast on that a while back: https://alchemist.camp/articles/elixir-releases-deployment-r...

I generally use a VPS, but Render is a top-notch host if you want something managed. In many ways, I think it's like Heroku was before Salesforce bought them.

You can deploy pretty much anything on Render, AFAIK it’s all container based.

Here’s the docs for Phoenix deployments: https://render.com/docs/deploy-phoenix

what a horrible name for a site, I can't imagine googling for how to add x extension to postgres with render.

what type of results do you imagine you'd get for that kind of query rather than what you'd want to get? especially given the context of postgres extension, i'd assume if there was content out there that google would find it with that query.

A friend of mine who worked at an SEO agency once had a client who's company name was a misspelling of some noun that google would automatically fix which i found hilarious.

Query + render.com seems to do the trick.

On the topic of render there was a really nice podcast on Software Engineering Daily from the founder talking about their product.

https://softwareengineeringdaily.com/2021/12/07/render-with-...

(Render founder) Lots of Phoenix/Elixir apps are hosted natively (no Docker) on Render, and of course we support Dockerized apps as well.

https://render.com/docs/deploy-phoenix

at a base, you can use heroku. That said, you won't be able to have your nodes communicate with each other. This restricts you from some of the more advanced featues. For Example, at my startup, we use horde to dynamically spin up individual websocket connections per customer for a integration partner. This was easy to do using horde and simply connecting the nodes together. Additionally, we can use the built in key store which is global to the cluster.

I would take a look at render.com. they support connected nodes and autodiscovery

I've deployed Rails at a few different companies. I wouldn't quantify it has hard by any means, there's just a lot of configurations to read through and verify every time. Realistically, the defaults are complete sane and could be deployed as is without much change.

It's ridiculously easy.

Even 6 years ago when I started, you could just run it in production with `mix phx.server`, much like running `rails server` and use the exact same deployment patterns. Or you could build a release and copy it up to the server however you saw fit. At that time it was painful for some coming from different habits that involved pulling in config at run-time rather than compile time, but those patterns have also been supported since at least 2019.

Since then, the team has been continually making it easier.

Now there's a single command line to do a deploy to Fly and also one to build a docker container for you if that's what you want: https://twitter.com/chris_mccord/status/1468998944009166849

Agreed. Immutable functional Elixir is the very opposite programming model of mutable state Ruby OOP.

It really is a nice experience. The BEAM family of languages was the first for me where doing multiple things at once came natural. It doesn’t require pulling in a library or adding redis or having to worry about shared state. You just add a process to a supervisor.

Yeah and then how do you deploy new version? In practice you still need Redis for most stuff. Also if anyway you have to deploy containers then value of BEAM is dimnished and provably better go with Go.

You don't need Redis if you learn the BEAM and OTP. Elixir runs on top of a distributed VM with builtin clustering. Use it.

And I see nothing wrong with having the BEAM run in Docker or K8s. There's some overlap in concepts, but they work at totally different layers. Using the BEAM is like having resilient microservices _inside_ your app with none of the downsides.

Could you be more specific about the issue you're having with deployments?

I've never used Redis in any of my Elixir/Phoenix apps. In cases where I might need something like Redis to store state, I'd reach for a GenServer or maybe Mnesia instead. I've never had an issue with deployments using this strategy. Also, K8s and BEAM work together just fine using libcluster. I'm not a fan of K8s or Docker and don't use either one, but you easily can.

The benefit of BEAM is that it can surgically handle a vast array of failures without restarting the node. K8s, on the other hand, will take the pod down and restart it. In many cases, solving a problem with BEAM is like using tweezers to remove a splinter whereas K8s is more like using a sledgehammer.

as someone on his 3rd year on a startup built on elixir, you're making the right choice. Our system is faster than an equivalent node setup while building features is almost as productive as rails. In some ways better. Plus, if you're goal is realtime or anything heavily websocket based, its going to easily outperform node or rails.

I simply cannot understand why people care about "fast" anymore with cheap containerization, CI/CD infra and no more dedicated servers. Who cares if its fast? Just add another box. I have this suspicion that anyone who still cares about backend speeds is stuck in the vertical scaling mindset where they need to keep adding cores and processes to a single machine

>I simply cannot understand why people care about "fast" anymore with cheap containerization, CI/CD infra and no more dedicated servers. Who cares if its fast?

People who pay for those extra boxes? Not everybody has your budget (especially when they're building things themselves, on the side, so they aren't even paid).

Getting to that scale on the side is a nice problem to have. Maybe it shouldn't be on the side anymore.

A cheap micro container is $5 a month. A cheap dedicated server can be had for $20 a month. Budget is not the issue here.

An expensive dedicated server can also be had for $1300 a month.

Scaling vertically can take you a long long way before you actually have to start separating services.

Ok? That's a non sequitur. No one is forcing you to buy a dedicated server for $1300 a month which probably has the same performance as $250 worth of separate boxes. And separating services isn't what we're talking about here. It's adding horizontal processes across machines instead of on one machine.

Not everything scales horizontally. Your database for instance is going to be scaled vertically to its max long before you think about using federated write servers. Sure you can use planetscale but that comes with its own considerations and tradeoffs.

Also, higher performance translates to lower machine costs. Our server costs would easily be 4x if we ran rails. given that elixir is 80-90% as productive for writing code in the short term, its a fair deal. Over the long term, we've found elixir to be more maintainable since there's very little magic and the immutable data structures and lack of magic make it super easy to debug.

Thanks to the performance of our system, we've also managed to get by without setting up caching. (we'll probably need it eventually but our performance gains have come mostly though fine tuning our sql queries. Ecto gives us way better control over the output sql than active record or sequalize)

A lot of engineers take great pride in improving performance even if it's mostly meaningless to the company. The users don't really care if the number of instances went down from 30 to 20. It is what it is, engineers will be engineers.

Doesn’t „fast“ directly translate into shorter page loading times? Static pages (JAMStack) load so fast it’s delightful everytime.

It doesn't. They mean "fast" as in one box can handle more load which in their opinion is cheaper because you don't need to containerize and horizontally scale. I find that unlikely.

What's Phoenix/Elixir like for deploying these days? When I last seriously played with it a few years ago the development was a lot of fun (and Elixir has influenced how I write and architecture on other platforms) but I remember deployment to production being a pain.

It's pretty easy if you use something like fly or render, anything dockerized really.

"mix release" makes it pretty much a breeze. I find myself spending more time setting up a Postgres server than mucking about launching my backend.

It's not harder to Dockerise than any other language.

Reply on news.ycombinator.com