When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
Phoenix 1.0
31–40 of 228 posts
Re: Phoenix 1.0
#32When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
Re: Phoenix 1.0
#33By the way, in case core team is reading, what's the motivation behind removing infer_model_view from the render functions?
Re: Phoenix 1.0
#34When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
The latter. The virtues of Elixir is that it is a functional language with immutable data structures, and that it does not support object oriented programming (which I consider a feature).
Re: Phoenix 1.0
#35Re: Phoenix 1.0
#36When people choose to build on a more esoteric language such as Elixir (and to lesser extent Erlang) is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant, productive, etc?
Re: Phoenix 1.0
#37Congrats to the whole team! It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like package, also hit v1 earlier this week and has backends for dealing with: PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB. [1] https://github.com/elixir-lang/ecto
Can you talk about your experiences with Ecto? How does it compare to ORM's in other langs, like Python's SQLAlchemy or Node's Sequelize?
Very exciting that they are branching out to support MongoDB as well. I'd love if they could support more untraditional Postgres operators for arrays and json (I guess there's always a tension between least common denominator and using the specialized features of each DB). You can get around it with partials, but it makes the code more messy.
Re: Phoenix 1.0
#38Congrats to the whole team! It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like package, also hit v1 earlier this week and has backends for dealing with: PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB. [1] https://github.com/elixir-lang/ecto
Can you talk about your experiences with Ecto? How does it compare to ORM's in other langs, like Python's SQLAlchemy or Node's Sequelize?
Unfortunately, I don't have experience with using the ORMs you listed in anger so I can't make a direct comparison. Anecdotally, I have found it much nicer to use than Django's.
Re: Phoenix 1.0
#39Earlier quoted context omitted.
Can you talk about your experiences with Ecto? How does it compare to ORM's in other langs, like Python's SQLAlchemy or Node's Sequelize?
Ecto isn't an ORM since Elixir isn't OO. Terminology aside, Ecto identifies more as an Integrated Query Language in a similar vein as LINQ does in the .NET ecosystem. As someone who has used lots of ORMs I find the switch to a libary like Ecto very refreshing. It has an intuitive and very composable querying API and friendly DSLs for defining schemas and validations. These are the baseline features of any database/mo…
Re: Phoenix 1.0
#40http://www.phoenixframework.org/blog seems to point to the most recent post.