[pmontra]

I used both Rails and Phoenix.

ActiveRecord is more pleasant to work with than the ORM of Phoenix IMHO, but not everyone shares the same feeling.

Despite having built in concurrency my team ended up building a version of Sidekiq because supervisors don't cover all use cases of job control.

I prefer deploying with Capistrano than with Elixir builds. Another matter of taste.

Structural pattern matching is the only feature I dearly miss, but that's a feature of the language.

We never used Liveview. We had a backend for a JSON API so I can't compare that feature.

[sph]

> ActiveRecord is more pleasant to work with than the ORM of Phoenix IMHO

A stateful mechanism vs a data mapper? Absolutely not. Being able to write `user.save()` is such a lunacy, thank god we have functional languages that (necessarily) decouple storage from data models.

I cringe every time I have to use imperative, stateful languages.

[out_of_protocol]

> ActiveRecord is more pleasant to work with than the ORM of Phoenix IMHO, but not everyone shares the same feeling.

Well, depends on what you do. Ecto is closely follows SQL logic and allows to translate weird sql queries into code directly. All queries are explicit, e.g. you either do preload(...) or can't access nested records at all, no chance of N+1 by design.

Changesets are also different and are just functions you can define as needed.

    defmodule MyApp.User do
    ...
    def changeset(user, attrs) do
        user
        |> cast(attrs, [:email])
        |> validate_required([:email])
        # This matches the error from the DB uniq index to the :email field
        |> unique_constraint(:email)
    end

[hparadiz]

It's fun watching other languages orms be 10 years behind in design.

Your example is a common anti pattern from PHP orms 15 years ago.

[out_of_protocol]

1) that's not an ORM

2) after ~8 years of using it, i find it ergonomic, light on congitive load and good for long term support

[hparadiz]

Calling it not an ORM just cause it implements a DTO is splitting hairs. It's an ORM. If you are hydrating an object that saves to storage and you are manipulating it's life cycle and then casting types between your storage primitives and your language primitives from memory to disk you are writing code that every other ORM is writing and it's not special.

As soon as you add use Ecto.Schema to your model it's an ORM.

> But it doesn't require a database and queries have to be explicit!

yea yea that's a feature of every ORM

[worthless-trash]

Could be wrong, but i dont think thats an orm.