5 ms·
I realize many will say Ruby is fast enough. But if you're a web developer, why WOULDNT you just develop your next net new project in Phoenix/Erlang instead of
by alberth 9y ago
I realize many will say Ruby is fast enough.
But if you're a web developer, why WOULDNT you just develop your next net new project in Phoenix/Erlang instead of Rails/Ruby?
Phoenix has most of the development bedofits of Rails, yet way better performance and scalability.
Seems like a win-win. You get a Rails like development environment without any downside of perf.
- sergiotapia 9y agoI've dropped Rails for new projects and I'm using Elixir/Phoenix exclusively now. Too many benefits to list out here, but probably my favorite feature is Elixir's pattern matching. Also running my test suite in 1.4 seconds always makes me smile.
- Daishiman 9y agoBecause Phoenix's library ecosystem is probably 3% of the size of Rails'.
- weatherlight 9y agoyou also have 30 years of erlang libraries... OTP is the reason why you'd switch to elixir/otp
- Daishiman 9y agoThe number of Erlang users is a very, very small percentage of Rails users. OTP is great, but wiring up API connectors and auth systems and serializers and whatnot still takes up time.
- deleted 9y ago[deleted]
- goseeastarwar 9y agoYou answered your own question. There’s no need to switch, because ruby is fast enough (and requires no additional training to continue using it).
- slindz 9y agoNeed? No. Compelling and valid temptation? Yes.
- deleted 9y ago[deleted]
- intininit 9y agoI wrote https://affluentconfidante.com/ https://affluentconfidante.com/ (which may or may not have been commissioned by a wealthy client who wants to deliver an anonymous message to the world) in Clojure and deployed entirely on AWS infrastructure. By design it is simple, because in my experience, the biggest obstacle to scaling properly is over-engineered code, especially premature optimizations that have the wrong guesses about what will need to scale.
- latortuga 9y agoA really huge reason stands out above the rest and is relevant for development shops and tech teams alike: you already have an investment in your tech stack (team, existing code, training, etc). This has knock-on effects as well - teams can move between code bases easily, there's a single idiomatic way to do things, common code quality standards, and much more. This isn't a sunk cost either, if <x tech> can get the job done and "more performance / scalability" aren't requirements, then there is tremendous cost to choosing a new pet tech. Multiply "learn new language X and new framework Y and new idiomatic ways of doing things for Z" by the number of developers you work with. It's not a win-win and deserves consideration.
- badthingfactory 9y agoBecause you don't "just" develop your next project in some other language/framework. You and your team have to throw out domain knowledge and make a whole bunch of mistakes with the new language/framework before reaching the competency you "just" threw away. "Just" is a terrible word we use far too frequently in the software industry.
- bcassedy 9y agoProductivity. Functional programming is like ancient Latin to many programmers. The pool of people with prior experience that you can hire from is smaller and the learning curve for a new hire is going to be greater.
- flavio81 9y agoBut the ones who learn, will become better programmers. Functional programming has already been proven out in the field, since the late '60s. In fact, there is a recent trend to more use of functional programming, just as in the 90s, OOP was all the rage. What is hard, is to use a purely functional language.