Metaprogramming is so much easier in an sexp type syntax than in any other language, I really do wish it was more common
Metaprogramming in Elixir
11–20 of 39 posts
Re: Metaprogramming in Elixir
#12I don't like the operators' logic in elixir. There should be one for assigning variables, one for pattern matching and there is no rebinding of variables. Could be like that: // assigning x = 1 // pattern matching x ^ 1 // pattern matching and assigning x =^ 1 And they should remove the rebinding that is useless. But I find it very difficult for that to happen at that time. Automatically translated.
Re: Metaprogramming in Elixir
#13I really love Elixir but our company had to drop it and rewrite a few projects in Go and Ruby, was too hard hiring and the existing team preferred not to continue with it. I think the learning curve is also quite harder than it initially seems, might be why some people give up on Elixir. But nothing but respect for Elixir.
Is there a public blog post about this with specific issues? Or is this just trolling?
Re: Metaprogramming in Elixir
#14I really love Elixir but our company had to drop it and rewrite a few projects in Go and Ruby, was too hard hiring and the existing team preferred not to continue with it. I think the learning curve is also quite harder than it initially seems, might be why some people give up on Elixir. But nothing but respect for Elixir.
Which concepts did you find that the team struggled with?
[deleted]
Re: Metaprogramming in Elixir
#15I think that the metaprogramming situation is a little problematic in Elixir. Elixir makes heavy use of macros in basic libraries like the Phoenix or Ecto frameworks that are used by more or less everybody.
I understand that macros are useful to build a DSL for a specific project but using macros in basic libraries like this leads to "way too much magic": Trying to understand (or somehow extend) Ecto is not really possible for all practical purposes and following the control flow in Phoenix is like a maze because of all the macro substitutions. This also leads to cryptic errors where you get an error in non existant lines of code.
This heavy of macros is my main complain about Elixir and I think it's one of the main problems that new people face when trying the language resulting in either not using it at all (or if they start it they will abandon it).
Finally, I understand that using macros in these libs allows for much more compact (and maybe beautiful) code, however I will always pick a more verbose (but less magic) version of this if I had the choice. I think this is the case for most programmers that want to use a language as a tool to do their job.
Re: Metaprogramming in Elixir
#16I think that the metaprogramming situation is a little problematic in Elixir. Elixir makes heavy use of macros in basic libraries like the Phoenix or Ecto frameworks that are used by more or less everybody. I understand that macros are useful to build a DSL for a specific project but using macros in basic libraries like this leads to "way too much magic": Trying to understand (or somehow extend) Ecto is not really po…
I agree. I was trying to learn Phoenix but had a hard time with the DSL because it was so non-functional in appearance.
Re: Metaprogramming in Elixir
#17I think that the metaprogramming situation is a little problematic in Elixir. Elixir makes heavy use of macros in basic libraries like the Phoenix or Ecto frameworks that are used by more or less everybody. I understand that macros are useful to build a DSL for a specific project but using macros in basic libraries like this leads to "way too much magic": Trying to understand (or somehow extend) Ecto is not really po…
Not sure if I would consider Phoenix basic. As far as I know, it's a wrapper around (and configurator for) Cowboy and Plug. I would consider Cowboy basic and Phoenix advanced.
Re: Metaprogramming in Elixir
#18I think that the metaprogramming situation is a little problematic in Elixir. Elixir makes heavy use of macros in basic libraries like the Phoenix or Ecto frameworks that are used by more or less everybody. I understand that macros are useful to build a DSL for a specific project but using macros in basic libraries like this leads to "way too much magic": Trying to understand (or somehow extend) Ecto is not really po…
It depends on what you mean by extending Ecto.
I've read bits of the source code to better understand what commands are doing, and you're right you can't use an IDE to jump from the public api to the internal implementation. However, the project has put a lot of work into an extremely clear internal naming convention, so you can just go to the implementation directory and grep for the public api name.
If you mean writing your own command that composes like the builtin ones, that's extremely easy. Often you can do it with just a plain function, and rarely you need a macro. Suppose you have something like this (haven't written elixir in a while, syntax may be slightly wrong)
def where_admin_over(q, age) do:
where(q, [u], u.age > ^age and u.is_admin)
end
def foo do
from(User)
|> where_admin_over(18)
|> where([u], u.country == "de")
|> Repo.all()
end
Re: Metaprogramming in Elixir
#19I really love Elixir but our company had to drop it and rewrite a few projects in Go and Ruby, was too hard hiring and the existing team preferred not to continue with it. I think the learning curve is also quite harder than it initially seems, might be why some people give up on Elixir. But nothing but respect for Elixir.
As a counter, I built an elixir team from 0-15 people and the devs love it.
No particular problems hiring - finding fantastic devs is always hard, but lots of people we hired were attracted by the language.
Re: Metaprogramming in Elixir
#20I really love Elixir but our company had to drop it and rewrite a few projects in Go and Ruby, was too hard hiring and the existing team preferred not to continue with it. I think the learning curve is also quite harder than it initially seems, might be why some people give up on Elixir. But nothing but respect for Elixir.
> was too hard hiring and the existing team preferred not to continue with it.
The second problem is bigger than the first.
For hiring, I worked at a company running Erlang for our main server app; very few people were hired with Erlang knowledge, almost everyone had to learn it on the job. As an earlyish hire, I had the most experience before being hired because I sort of remembered seeing a Slashdot post when Ericsson open sourced it; but I didn't do anything with it until I was hired. The couple of big issues this lead to is we never really did anything useful with the OTP application concept, no releases and what not, just hotloading with l/1 in the shell; and maybe it took us a bit longer to figure out how to scale BEAM because we didn't have anyone with that experience... But BEAM is written so nicely that people with experience optimizing C stuff can dig in and optimize BEAM without a huge learning curve, and most of the bottlenecks fit the same pattern of something simple that works fine at reasonable volume, but blows up consistently and clearly when you run it at large volume, so pretty soon you learn the pattern and know what to look for... And of course 24 has a lot less of these bottlenecks than r14 did.