6 ms·

Anyone know if Phoenix/Elixir have something similar to Ruby's bettererror gem? I see Phoenix has a built-in error stack trace page which looks like a clone of

Anyone know if Phoenix/Elixir have something similar to Ruby's bettererror gem? I see Phoenix has a built-in error stack trace page which looks like a clone of bettererror but it doesn't have the real-time console inside of it. Also, I wish they had a ORM like Sequel. These two are really what is holding me back from going full in on Elixir. Anyone can care to comment on this?

themgt 9y ago
Just use IEx.pry if you want a debug console.
kornish 9y ago
Curious about your thoughts on Ecto: https://github.com/elixir-ecto/ecto https://github.com/elixir-ecto/ecto. Seems to be the most popular solution for database access.
lojack 9y ago
> Also, I wish they had a ORM like Sequel. These two are really what is holding me back from going full in on Elixir. Anyone can care to comment on this? May be a matter of semantics, but the concept of ORM simply can't exist in a functional language as there aren't objects. That said, Ecto is pretty much the go-to in Elixir. It's extremely powerful, and in my opinion provides the right amount of abstraction without going too far.
cschneid 9y ago
> like Sequel Ecto can do a reasonable impression with its DSL & direct use of tables. You don't need to go through the whole stack of schemas and such. What in particular do you like about Sequel (over what Ecto is providing)?
_asummers 9y ago
Ecto is hands down the best "ORM" I've used. At no point has it ever gotten in the way of us dynamically creating queries on the fly, just following the Ecto internals (not recommended, but totally doable) and has an extremely expressive syntax. The team behind it has been rolling out new features and are extremely responsive to requests on the mailing list. I encourage you to give it a chance. The mental shift is that "schemas" are not objects in an ORM sense, but instead are just data, or views over data. The functions come from taking in data or a Changeset and manipulating those, versus calling a function on a class. As far as errors, Elixir 1.4.5 has much better error messages, specifically printing the args to crashes and such, and OTP 20/ Elixir 1.5 should drastically improve Dialyzer error messages. I am not a Ruby guy, so perhaps you can say what you feel is missing from Elixir's messages and how the Ruby gem improves it. Also you can literally inspect running state on the fly with the BEAM tooling, so the need for things like debuggers goes down.
- denisw 9y ago
  Could you explain which changes to Elixir 1.5 and OTP 20 should result in better Dialyzer error messages? I didn't find anything relevant to that in the respective changelogs. (For context, Dialyzer is a static analysis tool detecting type errors which is part of the core Erlang distribution.)
  - _asummers 9y ago
    It's kind of cryptic, but the Erlang release notes say: OTP-14369 Application(s): compiler, dialyzer, stdlib Related Id(s): PR-1367 The format of debug information that is stored in BEAM files (when debug_info is used) has been changed. The purpose of the change is to better support other BEAM-based languages such as Elixir or LFE. All tools included in OTP (dialyzer, debugger, cover, and so on) will handle both the new format and the previous format. Tools that retrieve the debug information using beam_lib:chunk(Beam, [abstract_code]) will continue to work with both the new and old format. Tools that call beam_lib:chunk(Beam, ["Abst"]) will not work with the new format. For more information, see the description of debug_info in the documentation for beam_lib and the description of the {debug_info,{Backend,Data}} option in the documentation for compile. There aren't specific notes in the Elixir 1.5 release notes, but given that it is OTP20 compatible, I assume it would be able to leverage this, perhaps with some work by Dialyxir. http://erlang.org/download/otp_src_20.0-rc2.readme http://erlang.org/download/otp_src_20.0-rc2.readme
pmarreck 9y ago
Phoenix/Elixir will likely never have an ORM because, well, the O... But I think Ecto is pretty cool, working with it right now on my first Phoenix website, actually

themgt 9y ago

Just use IEx.pry if you want a debug console.

kornish 9y ago

Curious about your thoughts on Ecto: https://github.com/elixir-ecto/ecto https://github.com/elixir-ecto/ecto. Seems to be the most popular solution for database access.

lojack 9y ago

> Also, I wish they had a ORM like Sequel. These two are really what is holding me back from going full in on Elixir. Anyone can care to comment on this? May be a matter of semantics, but the concept of ORM simply can't exist in a functional language as there aren't objects. That said, Ecto is pretty much the go-to in Elixir. It's extremely powerful, and in my opinion provides the right amount of abstraction without going too far.

cschneid 9y ago

> like Sequel Ecto can do a reasonable impression with its DSL & direct use of tables. You don't need to go through the whole stack of schemas and such. What in particular do you like about Sequel (over what Ecto is providing)?

_asummers 9y ago

Ecto is hands down the best "ORM" I've used. At no point has it ever gotten in the way of us dynamically creating queries on the fly, just following the Ecto internals (not recommended, but totally doable) and has an extremely expressive syntax. The team behind it has been rolling out new features and are extremely responsive to requests on the mailing list. I encourage you to give it a chance. The mental shift is that "schemas" are not objects in an ORM sense, but instead are just data, or views over data. The functions come from taking in data or a Changeset and manipulating those, versus calling a function on a class. As far as errors, Elixir 1.4.5 has much better error messages, specifically printing the args to crashes and such, and OTP 20/ Elixir 1.5 should drastically improve Dialyzer error messages. I am not a Ruby guy, so perhaps you can say what you feel is missing from Elixir's messages and how the Ruby gem improves it. Also you can literally inspect running state on the fly with the BEAM tooling, so the need for things like debuggers goes down.

denisw 9y ago
Could you explain which changes to Elixir 1.5 and OTP 20 should result in better Dialyzer error messages? I didn't find anything relevant to that in the respective changelogs. (For context, Dialyzer is a static analysis tool detecting type errors which is part of the core Erlang distribution.)
- _asummers 9y ago
  It's kind of cryptic, but the Erlang release notes say: OTP-14369 Application(s): compiler, dialyzer, stdlib Related Id(s): PR-1367 The format of debug information that is stored in BEAM files (when debug_info is used) has been changed. The purpose of the change is to better support other BEAM-based languages such as Elixir or LFE. All tools included in OTP (dialyzer, debugger, cover, and so on) will handle both the new format and the previous format. Tools that retrieve the debug information using beam_lib:chunk(Beam, [abstract_code]) will continue to work with both the new and old format. Tools that call beam_lib:chunk(Beam, ["Abst"]) will not work with the new format. For more information, see the description of debug_info in the documentation for beam_lib and the description of the {debug_info,{Backend,Data}} option in the documentation for compile. There aren't specific notes in the Elixir 1.5 release notes, but given that it is OTP20 compatible, I assume it would be able to leverage this, perhaps with some work by Dialyxir. http://erlang.org/download/otp_src_20.0-rc2.readme http://erlang.org/download/otp_src_20.0-rc2.readme

pmarreck 9y ago

Phoenix/Elixir will likely never have an ORM because, well, the O... But I think Ecto is pretty cool, working with it right now on my first Phoenix website, actually