I'd like to throw in Phoenix LiveView here.

Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO.

LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-to-no-DIY-JS, and one of the finest VMs there is (BEAM).

If nothing else, I'm happy that these projects all fight the "let's take a step back"-fight. At $DAYJOB I write React with Relay and the amount of hoops one needs to jump through is exhausting, even though I've been writing frontend JS for many years now and consider myself half decent in it.

Other than learning for fun. Is there enough of a benefit to learning Elixir if you would already consider yourself an expert at PHP/Laravel and JS/Vue ?

At a glance it's hard to see the value or believe that it has the same longevity or $$$ value.

Elixir is like an alien shiny flying soucer. It can do all types of technical marvels with a simplicity that is not possible without disfiguring more traditional frameworks. So I'd say having a cursory glance at it is a must.

In terms of $$$ value, it is extremely efficient --including all the "alien" stuff, and that's why it's so cool. An Elixir team will generally create things cheaper to build and operate.

Now, the question is how many Elixir shops you are going to find a job with, but the answer to that depends on the type of career trajectory you are choosing. For example, Rails is not an industry standard by any means if you think in terms of classical IT consulting jobs but has a stronger dev mindshare in startups, so there you go.

It's a tough market for Elixir devs at the moment - there seem to be a lot more people who want to work with Elixir than there are companies hiring for it. But on the flipside, that means if you're a company who wants to take a chance on Elixir, there are lots of available devs to hire!

Personally, I'm comfortable betting my career on Elixir at the moment. It's too goddamn good to remain a niche language - I expect it to get a lot bigger in the years ahead as more companies and devs fall in love with it. It'll happen slowly, and it's never going to reach the level of saturation that that, say, Javascript has, but I think it has a bright future.

Phoenix and LiveView are a joy to work with, much more so than any previous technology I've used. I haven't yet looked at any of the exciting new ML stuff that's happening in the Elixir world (Nx etc.) but hopefully they'll drive adoption too. I'm never going back to my old ways.

The craziest thing with Elixir is that you can do things all by yourself in the same time that would normally take a big team and consequent infrastructure to do.

As someone who's spent the bulk of his career in Rails and then Phoenix, to me it's the other way around: everything else is just so goddamn slow and unproductive. Don't people realise that it doesn't have to be like this?

Wait, are you saying that you are more productive in Rails than in Phoenix? That seems to be the opposite of what the consensus view in this thread is.

No, I'm saying that I'm more productive in either Rails or Phoenix than I am in anything else.

(And of the two, I'm more productive in Phoenix, but I didn't mention that in the comment you're replying to.)

I'm reading it as "Rails and Phoenix is more productive than other technologies".

Yes.

You are more productive on the thing you know the most. Shocking

Allow me to disagree. Finding good engineers that are knowledgeable with Elixir has been difficult to the point that we’ve hired people that never professionally used the language to senior positions. That’s not a problem on its own, since the language is mostly easy to learn, but there definitely is no abundance.

Try posting your job ad on the Elixir Slack (elixir-lang.slack.com) - there's a lot of jobseekers in there.

(I think the only way to join the Slack atm is to be manually invited because the signup app got broken by Heroku's pricing changes - but if you email the address in my profile then I'll ask someone to invite you.)

Its biggest strength is that it is good at almost everything (normal CRUD, websockets, distributed systems, easy to deploy as a single binary). Elixir/Erlang could be your entire stack

Just gave it a look. Dynamically typed. IMO if scalability is on the table, having types is a huge benefit.

It saddens me that ruby, python, elixir, JS... many of the best and most productive backend frameworks have types as an afterthought only.

Rust is cool, but it's also hard to write(did last year's AoC using it, and it was fast to run, slow to write).

Anyone have any recommendations for me? Should I look at go/gin perhaps? No Java please - I need type inference because I'm a spoiled baby.

Edit: anyone tried crystal? Looks promising, but doesn't seem popular...

Typing is coming!

Java already has type inference...

If you search Crystal on HN, there are a few user who are happy with it. Unfortunately most of them are only using it for personal projects.

> Laravel is creeping in, but it's not there yet IMO.

Could you elaborate on this?

I love rails. Hardly anyone is using it in my country, and the companies that do are looking for absolute wizards. Because I can’t find jobs using it, I do t get enough experience and lose out to said wizards (after the jobs stay open for 12+ months). Instead, I’m spewing yet more JS into the world because that’s where the demand is :/

What’s limiting you to taking jobs in just your country? I’ve got a gal working for me in Nepal out of all places. Previously had a guy in Jamaica.

I live in a very HCOL country, companies abroad can’t match local market pay.

What is HCOL?

High cost of living

This is great to hear. <3

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

I'm using both on two different customers. I have a preference for Rails.

The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that.

That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports. I hated that in Java even if the inevitable Java IDE added them for me.

The ORMs are more or less equivalent. I have a dislike for having to actually type the default scope (not the Django term) in Django as in

  Model.objects.filter(...)

when Rails lets me type

  Model.where(...)

The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python. It's something else much less powerful so you have to either prepare all the data in the controller (which is called a view in Django) exactly as they'll be displayed in the page, or write a templatetag and use it to transform the data inside the page. That loses an unbelievable amount of time. If I count the cumulative hours, days, weeks spent at writing templatetags instead of a couple of Python statements I don't know whether to thank Django developers for the easy money or to roll my eyes because that time is useless.

To recap, Django wastes developer time. It's death by a thousand cuts. I'll never use it for one of my personal free time projects.

Edit: don't be too smart in Rails, that is don't build too much magic and waste the time of the next developer into a quest for finding where something really happens. Write straightforward code and if some method name is created automatically, put a comment hinting at the source.

I've worked with both for years and one thing that always bother me is implicit over explicit in RoR. It can seems easy to write code and it's faster because of that, but reading code is harder, there is too much magic. Given that we spent more time reading code than writing code I prefer the python way.

I could agree with this but I think we're comparing here Django with Rails (the frameworks) not the languages.

But yeah, if I had an option I'd prefer things to be more explicit.

I've been a Rails dev for almost 10 years and the magic is the worst part. When something just works but I expected another hour of work, I feel like I've fallen into a trap. So, instead of just moving on, I look in the documentation for what just happened.

When you find yourself interacting with the magic parts, it is imperative that you comment what is going on so the next dev, which will probably be you, isn't also surprised.

Thanks for the reply. Agreed on the templating side of things - it certainly makes building sophisticated UXs harder.

Great point around project structure and ability to move between codebases - I think the lack of enforced structure in Django absolutely helps increase codebase entropy over time.

> If I count the cumulative hours, days, weeks spent at writing templatetags

Django has support for Jinja templates so you could just use that and call methods in your templates, which negates the need for most template tags.

> That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports.

Although its been a while, I do remember struggling a lot with autoloading in rails for two reasons: you can't find your dependencies from the code itself and when it breaks down its quite hard to debug. Maybe things are better now with rails and when you get really proficient you know how to find where things are - however that increase the learning curve which is supposed to be a benefit with rails. With django, I can generally look at the imports to see what this module is using. With the help of the right tools I can:

- 'go to definition' of any symbol and 99% of the time land in the source, even of django itself - automatically add imports so you don't have to write them - automatically sort and format imports and see the unused ones

With the optional static typing that is being greatly improved with recent releases, things get even easier.

I prefer this a lot above the rails 'magic', for me it is a huge time saver because my memory is not so good, there is minimal friction moving around between code and is various dependencies to see exactly how its done. With rails I'm more often looking at the docs (not so great) or examples, with django I'm most of the time looking at the source code itself or running the shell (which is very, very good).

> Model.objects.filter(...)

Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

> The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python.

I hate both but prefer the django template language. I'm surprised this is such a time waster for you. I think its good practice to not put too much logic in the templates so the division of labor in django is much better imo. But then again, I'm not a good frontend person and have problems with the deeply nested structures in html. Everything can help me simplify the template is a huge timesaver for me, bugs in the frontend code are terribly annoying. Honestly I hate frontend.

> > Model.objects.filter(...)

> Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

The point it that the objects method adds zero information to the statement. However it's an opportunity to add a soon to be discovered bug when Django crashes because one forgets to type .objects

They should have made filter a method of all model classes and of the models.Manager class. Same thing for all its sibling methods.

> Unfortunately that means that you have to waste time by writing those imports

This is time well spent in my opinion. Everyone, including future you, benefit from it.

One of my biggest gripes in Rails is not being able to do this.

Django is great (and comparable) if you're doing just backend, or have a separate frontend/SPA.

The frontend situation in Django is terribly outdated. Just the templating system is the worst thing I've ever seen, and it doesn't even have an asset pipeline.

Agreed. I’ve had to create dedicated SPAs for several projects recently which is a huge shame. I’d be interested to understand the architectural goals of the Django project moving ahead to see if they’re even interested in solving for this type of problem.

I've worked with them both, although Rails has been a while. Some things that stand out to me:

Rails has pretty good code generation. If I want just want to get started and add a birthday field to the settings page, I can run a short one sentence command and it will go off: it will know how to do schema migration, routing, views, controller, etc. This is possible because everything is so straightfoward and consistent. I'm not saying generators are a good way to write your code, its just one example of how rails has very a high level of abstractions.

Django however has the admin. Once you have a model, it will generate a fully functional cms for it and its very tweakable. For a lot of businesses, the admin is quite servicable as a cms or administation tool, and it is a _huge_ timesaver.

I generally prefer django over rails, it just seems all much more explicit and easier to discover to me, however I do agree you can be a lot faster with rails once you learn how things fit together.

I second you on the admin and I'm sorry I forgot about it.

Rails has the optional ActiveAdmin gem but it has basically no automatic integration with the Rails app and it's not included. That means that any Django app has a basic admin and most Rails app don't have one.

To be fair, it's easy to hit the limits of those admins but by baking a user hierarchy in the main web app with a super user, you can use the standard web app for many administration tasks. If you can impersonate users (handy for debugging and you have all their data anyway) you can do a lot of things without an admin interface.

What do you consider harder than rails? Something like Remix Run makes things very straightforward.

Those frameworks (Remix, Next, etc) give you like 5% of what you get with Rails or Laravel. There’s no point of comparison.

There is a comparison though. So there's 95% of things for you to give an example from but your comment is missing any useful examples

A lot of rails devs I know have switched to ember.js [1], because it's also a framework based on conventions rather than having a million third-party plugins that break all the time.

Architecture-wise I really like the ember-data approach because it allows a lot of automations when it comes to left join/right joins of datasets, with an integrated mockup server etc.

But it's not as cool as the other ones I guess, because it just works too well enough!?

[1] https://emberjs.com/

I thought Ember was a front end framework or am I missing something?

The idea behind ember-data [2] is that the models and their relationships are defined on the frontend side, which implies that the models are the single source of truth for both the frontend and the backend, including the APIs themselves. Ember adheres to json api specification, but there is lots of adapters for other database query languageds and/or storage types [1]

As I said in my previous post, it's a framework based on conventions, so it'd a batteries-included approach to both frontend and backend.

[1] https://emberobserver.com/categories/ember-data-adapters

[2] https://guides.emberjs.com/release/models/

Did you ever try Jump Start Rails or Bullet Train?

I’m thinking of building a side project with Rails and I’m wondering if they are worth it?

I am on JumpStartPro and quite happy about it. It has all the common gems already included and ready to configure. It also has a lot of excellent code that shows me how to do things.