I think we’re going off topic… 
- can we move the latest part of this thread to a new section in this forum?
Sorry, not clear enough here: RoR vs Ecto, for example field/attribute: Elixir/Ecto: DB-migration + schema + n changesets cast + validations vs. Ruby: migration + 1 x security for the assignments (depending on the RoR version), even the validations can be handled automatically from the DB definition. Even with 1 reused changeset a lot of typing the same stuff. And using :string in the schema and :text in the migration isn’t making maintenance easier.
Sorry, wasn’t clear enough about the second point either, I thought more of: [1,3,2].uniq.sort.count vs Enum.count(Enum.sort(Enum.dedup([1, 3, 2]))) (and no, [1, 3, 2] |> Enum.dedup() |> Enum.sort() |> Enum.count() does not make it better and yes - I know that you rarely find something like this, mostly in the introduction examples 
- so the first impression you get from the language is far worse than some “real” code later where you find out about the beauty of pattern matching, …
I know that some of this decisions are made on purpose and some imho make a lot of sense (no automatic preloading, …), but in some other places the implizit/explizit mixing in Phoenix puzzles me too. controller → view directory name = convention over configuration → template name = configuration over convention… things like this let me put Elixir always somewhere between RoR (everything = convention) and old school Java stuff (everything was configured) - I’m just glad that the template name is not defined in an XML file 
- for me it would be a lot easier if I know the idea behind such decisions (like the original question with UTF8). I don’t want to learn what is convention and what not, I want to understand why a decision has been made.
Will definitively not argue about conciseness, clarity, expressiveness, resilience, fault-tolerance and quoted expressions 
- at least not against Elixir in this areas…
I hope (and I’m confident) that the community here will stay like it is now: very friendly & helpful and I hope that Phoenix and Ecto will continue to improve (and hopefully 3rd party libraries will follow, really miss some basic stuff - but on the other hand you learn more about ltree in postgres and other things when you have to solve such things by yourself).
