Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir and Phoenix after two years

nts.strzibny.name

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Elixir and Phoenix after two years

#101

Post by joelbluminator »

cageface wrote: post #68
blunte wrote: post #3

To add to the author's experience, I spent 18 months of production time with Elixir and Phoenix. As he says, the templates are compiled and are blindingly fast compared to Rails. Pattern matching is really really nice when used in the right places (and you'll miss it if you go back to Ruby); but it can be overused. There's a faction of Elixir folks who attempt to avoid all conditionals and instead seem to prefer mult…

The problem for a new technology like Phoenix that wants to dethrone an established player like Rails is that it's not good enough to be 50% better. It has to be 2x or 3x as productive to offset the smaller ecosystem and pool of developers. And I'm not convinced for most of the things that Rails is used for it's that big of a productivity boost.

> And I'm not convinced for most of the things that Rails is used for it's that big of a productivity boost

It could be a big productivity hit actually...

Re: Elixir and Phoenix after two years

#102

Post by nickjj »

techpression wrote: post #100
nickjj wrote: post #95

Earlier quoted context omitted.

> Ecto prevents N+1 queries by default, which I think is clearly better. To be fair... If you want to protect yourself from these with Rails you can install Bullet[0] and get protection through in your face notifications, and you have the option to let it slide because you're taking advantage of caching with Rails and in this case you know what you're getting into and the N+1 query with caching ends up being better b…

For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem, just the general mindset in the Ruby and JS world (although Ruby is a lot better) to just go and depend on the work of others for core functionality.

> For a lot of people and teams, having to know about and rely on a bunch of third party dependencies (not seldom the effort of one or a few developers without financial support) is not a positive thing. Not saying these specific gems are a problem.

I think this is a really great discussion point btw because depending on a ton of 3rd party libraries that come and go can be an issue for sure.

But at some point you need to live in the moment and align your expectations with the current reality and think about what happens to your code base if the library stops being maintained.

For example, strong migrations has a 5+ year track record and shows no signs of dying. It doesn't make sense to live your life in fear and avoid 3rd party libraries because one of them might go away in the future because the maintainers get bored or stop using it. Because what happens if that doesn't happen and it ends up being wildly popular and maintained for years?

The reality is a lot of people develop libraries, use it for a while time and then move on. This happens in Elixir too. The ExAWS package comes to mind (the most popular AWS package for Elixir). Similar things happened with Arc (file uploads) too. Eventually those tools got replacements or new maintainers.

If you're developing an application it makes sense to weigh the pros and cons on using certain libraries but it's not like these libraries immediately go away. Usually there's a huge amount of notice before a library becomes officially dead. There's also tons of opportunities to talk with the authors and collaborate with the community to keep it going. And in this case, the outcome is likely a lot better than you trying to develop a custom solution in total isolation that's not open source.

So yeah, there's really no downside to using most 3rd party libraries. Either it fits your app well enough and continues to be maintained while you happily use it (and maybe contribute back changes), or it fizzles out and you got some value out of it and now you have a great head start in implementing a custom solution from it for your unique use case.

Re: Elixir and Phoenix after two years

#103

Post by toolz »

TylerE wrote: post #72
toolz wrote: post #10

Earlier quoted context omitted.

sqlalchemy is an ORM - I'm not sure it can be compared against a web framework, but my experience with phoenix vs python web frameworks is that phoenix is easily faster even for single-threaded web requests (which of course will utilize many threads for things like DB thread pooling etc.)

sqlalchemy contains an ORM. You can do a ton with it without ever importing sqlalchemy.orm.

Sure, but you're missing the whole point - it's not a web framework and it's never marketed itself as one to my knowledge.

Re: Elixir and Phoenix after two years

#104

Post by ch4s3 »

nickjj wrote: post #95
ch4s3 wrote: post #44

Earlier quoted context omitted.

Having done both, I think Rails has a ton of baggage around ActiveSupport and ActiveRecord that are full of gotchas. Ecto prevents N+1 queries by default, which I think is clearly better. I also think that the lack of lifecycle hooks in Ecto is a better decision than the pile of foot guns in ActiveRecord hooks. I would also argue that Plug is a large improvement over Rack, and the idea of explicitly passing a single…

> Ecto prevents N+1 queries by default, which I think is clearly better. To be fair... If you want to protect yourself from these with Rails you can install Bullet[0] and get protection through in your face notifications, and you have the option to let it slide because you're taking advantage of caching with Rails and in this case you know what you're getting into and the N+1 query with caching ends up being better b…

I will grant that strong_migrations is really cool, and data migrate is nice but not really that hard to implement yourself if you need that. Bullet however IMHO is a way overly complicated way to solve for N+1 queries. I would argue that eager loading associations by default is wrong and a thing ActiveRecord shouldn't do at all.

You can opt in to preloading with Ecto when you consciously want to make the tradeoff, which I think is a better default approach.

Re: Elixir and Phoenix after two years

#105

Post by aantix »

AlchemistCamp wrote: post #79
aantix wrote: post #77

Earlier quoted context omitted.

>Ecto prevents N+1 queries by default, which I think is clearly better How does it know what associations to eagerly load without knowing about the views? It can't eagerly load all of the data on complex objects.

It doesn't eagerly load anything. It preloads exactly what you tell it to. Ecto Repo vs Active Record: https://youtu.be/IFKG4Hgt-zM

So you have to be explicit in what to "preload"?

How does that differ from specifying an includes on associations for eager loading?

It's not saving you any mental energy; you still have to discern what should and shouldn't be loaded up front.

Re: Elixir and Phoenix after two years

#106

Post by connorlay »

At work I am building a new internal project in Phoenix Live View and the developer experience so far is sublime. The entire Elixir ecosystem is an absolute joy to use. In the early life of an application, you get the incredible productivity of Ruby on Rails, while building on the battle-tested OTP platform that can scale with your business. The language itself combines the best of Erlang, Clojure, and Ruby all under one roof.

Re: Elixir and Phoenix after two years

#107

Post by connorlay »

innocentoldguy wrote: post #70
datavirtue wrote: post #43

"Elixir is not an object-oriented language. We practically only write modules and functions. This helps tremendously in understanding code..." Sign me up. I hold hope that Elixer is the thing that starts pushing the knife into OOP. Microsoft has added a ton of features to make functional style a thing in C#, and nearly everyone hates Java...so maybe the stars are aligning.

Agreed. OOP is obnoxiously convoluted at times and—I feel anyway—never fully delivered on its promises of reuse. I've been using Elixir for about five years now and I never want to write another line of OOP code. I don't care what language it is in.

This has been my experience as well. I left Elixir for a brief stint with Kotlin, a modern OOP language, and it was jarring how many abstractions and incidental complexity I had to wrangle with to be productive and ship well-tested features.

Re: Elixir and Phoenix after two years

#109

Post by mercer »

danjac wrote: post #50
blunte wrote: post #11

Earlier quoted context omitted.

I fear it would be difficult to hire Elixir people as well, but now I realize it's actually also hard to hire decent Ruby/Rails people. Honestly I think we should just accept anyone who can demonstrate thinking and programming skills of any language and then plan for 2-3 months of ramp-up time to get them into our language of choice.

I'd be happy (if I were job-hunting) to be able to try out a different language/platform every so often. Now and again I'll play with, say, Ruby or Elixir or whatever. But I know that I'll never get a job working with these languages because I don't have the n years experience with them. The tech hiring process is gruelling enough with languages and frameworks we are familiar with, your resume won't even get a glance…

I've seen at least a few Elixir jobs where they explicitly specify that you don't need to have experience specifically with Elixir. Don't know how common it is though, and it's true that finding Elixir work can be difficult to begin with.

Re: Elixir and Phoenix after two years

#110

Post by strzibny »

mercer wrote: post #98
joelbluminator wrote: post #93

Earlier quoted context omitted.

As a Rails dev I have to say: Why trying to dethrone Rails? I don't get the Elixir obsession with Ruby/Rails (yes Jose Valim came from Ruby - so what?). Ruby is smallish enough, I don't get the obsesssion with going after that segment.

from my experience, Rails is not really much part of the general discussion in Elixir/Phoenix world. Sure, a number of us came from Rails, and lots of 'new to the community' discussions might hit on that, but that's a far cry from being 'obsessed' with dethroning Rails. If anything, my impression is that a significant portion of the community still uses Rails for many of their applications, and some occasional grumbl…

Exactly!
Post reply on HN