Live data from Hacker News

Metaprogramming in Elixir

serokell.io

31–39 of 39 posts

Re: Metaprogramming in Elixir

#31

I 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.

I’ve seen this a lot. The biggest reason for failure is people assume they already know everything about the VM and language. Erlang + BEAM are the most integrated pair of VM and language I know of. It’s the only VM that will preempt running processes. It’s also truly functional. A lot of really brilliant folks have written truly shit Elixir code because they underestimated the challenge. Oh you’re passing that blob…

We train people on Elixir where I work and it seems to go well. I think I was one of the only people with prior Elixir experience they've ever hired, and I am arguably a junior.

Re: Metaprogramming in Elixir

#32

I 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…

Completely disagree with ecto[0] and plug. (I have some issues with ecto, but it has nothing to do with macros). The use of macros in those two libraries is parsimonious and exactly what you want in a DSL. For that matter ExUnit, too, has exactly the 'right' amount of macro usage. Phoenix, on the other hand, drives me up the wall. I would not call Phoenix a "basic library". It's definitely a heavy framework. You can…

Yes I never got into Rails for perhaps the same reason. There were tiny source files with some very succinct and clever code that obviously caused a huge amount to go on behind the scenes but it was all magic and impossible to trace or diagnose anything - for me.

Also discoverability simply wasn’t there in Rails and I feel the same with Phoenix. I have no idea what pieces might fit in anywhere. Having to know that you have to create a file with a particular name in a particular place if you want something to happen is a bit of a pain if you can’t find a solid reference on that, but also knowing that this is even a possibility - that a feature exists - means reading and re-reading huge documentation on every release just to have some idea of what might actually exist.

It’s very likely that I really just haven’t ‘clicked’ with the right way to work with either, but I fear that the only real way to do so is to become an expert - and that would be a huge time investment.

Still, I do enjoy looking at the code of projects using Phoenix, even if I can’t fathom how they knew to create certain files and what to put in them.

Re: Metaprogramming in Elixir

#33

Earlier quoted context omitted.

Completely disagree with ecto[0] and plug. (I have some issues with ecto, but it has nothing to do with macros). The use of macros in those two libraries is parsimonious and exactly what you want in a DSL. For that matter ExUnit, too, has exactly the 'right' amount of macro usage. Phoenix, on the other hand, drives me up the wall. I would not call Phoenix a "basic library". It's definitely a heavy framework. You can…

Yes I never got into Rails for perhaps the same reason. There were tiny source files with some very succinct and clever code that obviously caused a huge amount to go on behind the scenes but it was all magic and impossible to trace or diagnose anything - for me. Also discoverability simply wasn’t there in Rails and I feel the same with Phoenix. I have no idea what pieces might fit in anywhere. Having to know that yo…

I'm about three years into using elixir professionally and I still kind of hate phoenix. There's a lot more to love in elixir than phoenix, and to be honest, especially if you're getting paid to work on a phoenix codebase, you can kind of grin and bear it, ask for help on slack/elixirforums, and it's mostly fine. There are truly only a handful of things where "you kind of have to know the magic incantations", and it's very easy to find someone who knows them. Often it's a generator. Typically you only need to be shown once per project at most (and everything else is a normal copy/paste away). And the debug lines making no sense is relatively rare. In the best sense of "being a framework", once you're past these problems, you're into pure elixir and all is good again.

Jose has stated that fixing internalized pain is a real priority for the elixir ecosystem moving forward, so it's entirely possible that these things will be fixed over time (or it's possible it won't!).

Re: Metaprogramming in Elixir

#34

I 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.

https://elixir-lang.org/getting-started/pattern-matching.htm...

Having had experience with Erlang, I still find it weird that you can update variables :)

Re: Metaprogramming in Elixir

#35

Earlier quoted context omitted.

Yes I never got into Rails for perhaps the same reason. There were tiny source files with some very succinct and clever code that obviously caused a huge amount to go on behind the scenes but it was all magic and impossible to trace or diagnose anything - for me. Also discoverability simply wasn’t there in Rails and I feel the same with Phoenix. I have no idea what pieces might fit in anywhere. Having to know that yo…

I'm about three years into using elixir professionally and I still kind of hate phoenix. There's a lot more to love in elixir than phoenix, and to be honest, especially if you're getting paid to work on a phoenix codebase, you can kind of grin and bear it, ask for help on slack/elixirforums, and it's mostly fine. There are truly only a handful of things where "you kind of have to know the magic incantations", and it'…

> Jose has stated that fixing internalized pain is a real priority for the elixir ecosystem moving forward, so it's entirely possible that these things will be fixed over time (or it's possible it won't!).

Ah, that sounds interesting. Do you have a link to where he said that?

Re: Metaprogramming in Elixir

#36

Earlier quoted context omitted.

I’ve seen this a lot. The biggest reason for failure is people assume they already know everything about the VM and language. Erlang + BEAM are the most integrated pair of VM and language I know of. It’s the only VM that will preempt running processes. It’s also truly functional. A lot of really brilliant folks have written truly shit Elixir code because they underestimated the challenge. Oh you’re passing that blob…

Yes. I view Elixir kinda like 2 different languages in 1: the functional language and the process language. The process language is the most unique one though so you will probably spend more time learning that than the functional one.

It's 3 languages. The functional language, the otp process system, and the compile-time scripting language.

I think people who have difficulty with some of the constructs at the just-inside-the-defmodule scope are not understanding concept #3

Re: Metaprogramming in Elixir

#37

I 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.

Having learned Elixir, there definitely were a couple interesting gotchas, what kept me sane was at least already understanding the Actor model and message passing. Having to learn a new language alongside a new paradigm can be very challenging.

My personal favorite Elixir gotchas I've witnessed are, trying to run Mnesia on only 2 nodes, and OOMKiller doing interesting things where somehow parts of your app die.

Re: Metaprogramming in Elixir

#38
post #25

Earlier quoted context omitted.

Macros can be de-mystified with proper editor support. In Emacs and Lisp you can (recursively) use "macroexpand" to see what code it produces in-place. I am not an Elixir user (though thinking about hopping on), apparently there is alchemist.el[1] that lets you do that (with caveat, and the project seems dead tbh). [1] https://github.com/tonini/alchemist.el

Macro expansion has recently been added to elixir-ls[1] and is supported via custom command in vscode extension. [1] https://github.com/elixir-lsp/elixir-ls

That’d be really handy! It’d make Phoenix that much more approachable. With good editor support, I much prefer macros to runtime OOP magic/design patterns.

Re: Metaprogramming in Elixir

#39
post #25

Earlier quoted context omitted.

Macros can be de-mystified with proper editor support. In Emacs and Lisp you can (recursively) use "macroexpand" to see what code it produces in-place. I am not an Elixir user (though thinking about hopping on), apparently there is alchemist.el[1] that lets you do that (with caveat, and the project seems dead tbh). [1] https://github.com/tonini/alchemist.el

Macro expansion has recently been added to elixir-ls[1] and is supported via custom command in vscode extension. [1] https://github.com/elixir-lsp/elixir-ls

That's awesome! Now, what needs to happen for this to be supported in generic LSP clients like Emacs lsp-mode/eglot or nvim-lsp?
Post reply on HN