(no title)
fxn | 2 years ago
.exs files are compiled just like .ex files are. The only difference between `elixirc` and `elixir` is that the former creates an artifact on disk, and the latter does not. See https://medium.com/@fxn/how-does-elixir-compile-execute-code....
Also, Ruby is as compiled as Elixir is.
Compiled vs interpreted is blurred the moment you compile to bytecode run by a VM. An artifact is not a fundamental difference.
josevalim|2 years ago
This leads to differences such as Ruby meta-programming happening at runtime, Elixir’s at compile time. The Elixir compiler (the Erlang compiler really) can also afford to do more work at compile-time which then leads to different approaches at the JIT level too.
larksimian|2 years ago
You could also be defining methods pretty much whenever, for instance in response to user input, mutating the state of the process from that call onwards.
The former is much, much more common than the latter.
e. A blurring of the 2 is something like ActiveRecord defining field accessors dynamically once a DB connection is eatablished. You connect to the db and now your User model has email, first_name etc methods, unless you'd defined them already.
I'm guessing nothing quite like this could exist for Ecto(I vaguely know this isn't a super good comparison, Ecto is quite different from AR from what I remember).
That being said even that would still happen as part of a prod app's 'loading' phase so to speak rathet than during a request cycle.
atonse|2 years ago
So if you had different behavior for ex and exs that would cause developer confusion.
benatkin|2 years ago
And it would be the same as in another language if you run a program that has no side effects. For instance "python abc.py" will gladly run a abc.py that is empty or has "class ABC: pass" in it.
arrowsmith|2 years ago
Thanks for keeping me factual.