I avoid rails-style megaframeworks like the plague. I'm fine writing the glue code if it means I understand more of the stack, or it doesn't refuse to budge if I occasionally have to go "off the rails".
Really? I miss it sometimes. I haven't kept up with it in over 5 years (switched to .Net now).
I am just curious, why would I use Rails over something like .Net in today's time? I am no apologist for .Net or anything, I am just genuinely curious.
Because you or a team knows it, because it's still a hell of a lot more of a batteries included ecosystem than the last Scala or node projects I was involved in which had to reinvent a shocking number of wheels that are table stakes in Rails-land (can't speak to .net, never been an MS stack dev), because you're working with some other Ruby or Rails thing and its easiest to stay compatible, because there's a lot of mature, profitable projects out there hiring in it with high salaries ;), etc
It's an engineering decision with tradeoffs, like every engineering decision.
My gut feel is that the .Net ecosystem is probably more complete than the Rails ecosystem, but part of that is because there's a larger market for commercial components. Like you say, tradeoffs.
Hot take: Phoenix does almost everything Rails does but better. Ruby is still superior for scripting, but OTP gives you so much flexibility for integrating your backend (supervision is built in, process abstraction is built in, rpc is built in, microservice architecture is built in). The only other thing I don’t care for with Phoenix is the amount of metaprogramming which I think is even worse than Rails
Hot take: Everyone now uses k8s, I don't get why forcing our devops team to learn OTP and understand how to integrate Elixir with k8s is a benefit, it will only be harder for them. So you get most of the benefits like scalablity/reliability etc even if you're on the Rails - but you don't have to expose junior devs to a complicated and obscure stack like Elixir.
All those people using k8s don't include any of my customers. Current projects are Django sites running on VMs, Rails sites on a kind of Heroku service and a Phoenix app running on VMs plus some Elixir services running on Google Cloud serverless services.
Actually the latter is a candidate to k8s because the team knows less and less of server management. I think they are going to replace complexity with complexity for something that fits well in a small VM. We will see.
No offense taken. Small contractor, small customers. The long tail doesn't need fancy technologies devised by companies that have to serve billions of users and yet a lot of people live there.
About Elixir, I don't think it's an overkill. I find its pattern matching much better than anything similar in Python and Ruby. Running a background job without having to use Celery or Sidekiq is great. The deploy story is worse than Ruby's (IMHO) in part because it's compiled (I prefer to deploy with Capistrano than having to build and deploy.) Python's deploy story just doesn't exist. According to the project I'm using a self made Capistrano equivalent, git pull or sending git patches to the server.
I'm sure you serve them well with Elixir. All these technologies are good enough. You wouldn't be able to build stuff for them in PHP/Ruby/Java? You would, but you prefer Elixir because you think it's superior and thats fine. But even if its superior you have to agree equivalent stuff is being built in 15 other stacks.
Technology choice is a bit overrated imo.
Actually the customer chose Elixir. They found me because there weren't many Elixir developers in my country when the project started years ago. I prefer Ruby for my own stuff which of course is way smaller than customers projects.
I don't think there is any particular "reason". Majority of the languages and tools are really good enough to achieve 90% of business use cases out there.
Unless you have some specific requirements for you app like high concurrency or memory safety and so on, then you can pick whatever you (or your team) are most comfortable with: Django, Rails, Symphony, .. are all excellent.
It's more about solving business problems and building great systems than anything else. All tools have pros and cons of course, it's simply up to us to review the requirements and pick the right one for the job.
I imagine that one reason why you might want to use it is if you don't like the "let's reinvent the wheel incompatibly every three years" approach from the .NET world.
You are not wrong though, and it's quite annoying when hopping between multiple .Net versions. I feel like I have a bit of insight into what it would have been like to be developing in Python during the 2.x to 3.x schism years back.
Microsoft has a strong stance of backwards compatibility, but they achieve this by freezing the The Old Thing as much as possible and keeping it working as is.
Then, they come up with The New Thing every few years, which is not backwards compatible and only handles 20% of what the old thing did + a few new things, but they promise this is the future and will eventually have all the features. The Old Thing is always there if you want it, so there's no reason to revolt when this happens.
The New Thing will eventually be replaced by a Newer Thing, get frozen in its current status, and the Newer Thing will be promised to be the future.
A nice example is Windows GUI. The Old Thing is GDI. Then they invented WinForms in .NET, then WinForms was abandonned in favor of WPF, then WPF was abandonned in favor of Metro/Modern/Universal apps, and last I checked they had some new HTML+JS-based stack available. All of these frameworks still work - you can take an app built with any of them and run it on the latest Windows, and you can even build a new App based on any of them and still find resources for it etc. But none of the old ones are getting new features, and MS will steer you to one of the newer ones instead.
The same kind of thing happened with communication frameworks (COM, then WCF, then???), with ORMs (ADO.NET, LINQ to SQL, Entity Framework, Entity Framework Core) and I'm sure others.
And don't forget about silverlight and frameworks build on top of it (for enterprisy like form apps). That one was one hell of a swamp that almost drowned my friend's startup after MS decided to kill it.
Years of hard work went down the drain at a snap of a finger.
This is exactly why I got off the MS merry-go-round. The strategy seems to be to keep developers constantly chasing the Next Thing so they haven't got time to explore alternatives.
I detect a similar strategy with Apple and the app store: make it so that the long tail of small developers can't invest in more than one platform by moving goalposts so frequently you spend any spare cycles you have trying to keep up.
Rails has added a lot of cool built in stuff. SPA like stuff that is done over sockets but written in ruby (Hotwire is the name of it) is the most germane to this conversation.
But all t he other stuff common to popular libraries still applies, tons of community support, huge extensibility, large population of devs that have experience building large apps.
That means it's not likely to make huge breaking changes without lots of notice. Its development team isn't going to find something more interesting to do tomorrow. Lots of people know it. There are lots of libraries and tools that work with it. Its capabilities and limitations are well understood and predictable. Its future isn't tied to a single vendor. Lots of people know it.
I struggle with this a little. Or rather, I struggle with the counter corollary: “Because you don’t know it.”
I mean, I solve most of my problems with the hammers I have at hand. But I try not to fall exclusively in this trap of “I will use tech X because that’s what I know.”
But I see a majority of my programming peers who will avoid moving “forward” because it’s easier to “stay behind.” At first, this works, because the difference between what’s new and evolving versus what’s established and a “core competency” is trivial and easy to marginalize. As it persists over time though, the investment can become a real millstone.
I am pretty comfortable with Python. We use it some pretty key areas in our product. It’s an established technology and competency for us. Last year, I needed to construct a service that was going to involve spinning up LOTS of little long lived threads. I was concerned about doing this in Python. Doing so would be easy and straightforward. “Because I know it” would definitely have said “do this in Python right now, deal with scaling issues later.” Instead I looked around and deemed this a good reason to take Elixir for a spin. I’m glad I did. It turned out to be a good fit for this problem. “Because I don’t know it” caused others around me to raise their eyebrows and question my approach initially. Was it the 100% best choice? Who knows for sure. But it’s worked out well. Ironically, just the other day, a data serialization library I have in both systems, the Python one needed to run faster (new use case for it suddenly needed speed that we didn’t hitherto care about). After some profiling, I rearchitected the python algorithm to be more similar to the Elixir one and gained about 50% speed up.
A lot of places suffer from not believing they have the capacity to use the right tool for the job if it's not in the tech stack they already have. Similarly, people over-index on having a comfortable implementation path for feature X in technology Y, whereas technology Z, if they cared to look at it, would halve (or better) the implementation time.
There's so much more to this then Stack X runs faster or has better concurrency - there's development time, there's the team's ability to maintain the code, there's community size. Performance is overrated most of the time - it simply doesn't matter much to the business if you save some money on AWS bills compared to human cost.
Same for Laravel, although it hasn't grown as much as Rails, the amount of batteries included is amazing. There's very little I've had to reinvent, unlike my Node JS projects, where there's too much time wasted in finding and learning 3rd party packages that are outdated in a year or two.
Why make billions when you can make millions (not dealing with bad async primitives and type safety that doesn't need some third party project like sorbet)
Many start-ups (especially ones that aren't backed by millions of VC money) choose Rails because of the super high developer productivity and the broad availability of well tested packages.
You could just fade out rails as you could with any other monolith, but many companies aren't doing it because it offers legitimate advantages.
