Your Elixir Tips Thread

My fave is __CALLER__ struct has a context key which might be used to distingush context of macro invocation (might be :guard when invoked in guards, :match when invoked in matches, or nil otherwise.) Here is the self-explanatory example from Kernel.or/2 macro

  defmacro left or right do
    case __CALLER__.context do
      nil -> build_boolean_check(:or, left, true, right)
      :match -> invalid_match!(:or)
      :guard -> quote(do: :erlang.orelse(unquote(left), unquote(right)))
    end
  end

It helped me to build the MapSet matchers fwiw.

This is a very nice tip, it makes you understand the function and adding a doc to the function even make it better to understand what that function is doing, if you want to use multiple clause function, so you can understand what each function with its own clause is handling
Thank you

Learning the basics of any programming language or anything in life. Is like a farmer forging it tools
When I started elixir, I just started with how to use Ecto, I would ask my senior colleagues any questions and they will always wonder how come the simplest thing about the language I didn’t understand. Last year when I thought of going full stack into Elixir . Reality hit me that I didn’t understand anything about the language, so I requested help from CTO and when recommend things to me, I went to senior developer in my team to ask questions and while learning with all these materials, confusion finished me.
Then I was hit the utmost truth, I don’t know anything in this language and when I accept the truth and also a declaration. I will forge myself in this language, I started learning and still on learning journey and the progress I can see, make me wonder why I delay this journey. elixir documentation would help you, also Elixir in Action is a great book for elixir developer, we have Exercism for elixir challenge and practices, we also have Elixir school for roadmap and learning curve but above all this we have Livebook to practice your skills and we have Elixirforges a YouTube channels for beginners and any level of developers and we have Elixir mentor. We have chatgpt to ask questions. Don’t just stay okay in your programming language, advance daily

Here’s a neat tip from PragDave

If you want to comment a public function, but hide it from the documentation system, try the following. (The trick is the “!” operator.)

https://twitter.com/pragdave/status/1000456904185966592

More than tips, I’m trying to find repositories with sample code. I’m very fresh in FP (and Elixir too), I´ve already started @pragdave´s course too. It was a great source but I want to find more code to learn strategies of coding in FP because today all my code looks like an OO approach.

It’s easy to find tools and libs written in Elixir in github, but sites, apps and information systems that is my focus now it’s not so easy to find.

If someone knows or have any github repositories I will be gratefull.

Also, just to clarify, it is so the compiler can scan the exposed functions on the module to know what to import from which module.

/me wonders if an option on import could import only: ... names without the compile-time checks, perhaps like import Blah, compile_check: false, only: [my_fun: 1, my_fun: 2, more_funs: 1, ...]

To clarify, both alias and import are fast to compile and both do not affect the runtime performance. The issue is that import implies a compile time dependency, aliases do not. When you do import Foo, Foo needs to be available at moment and the compiler will block until such happens.

Reading @josevalim’s post on this thread just got another insight of tip:

Prefer alias over import. Aliasing is clearer (explicit is better than implicit), faster to compile and does not affect performance on runtime at all (I guess)!

Oh, one more thing! Apply the “let it fail” philosophy wherever you can!

For example, instead of:

case foo(bar) do
  {:ok, bar} -> {:ok, bar.foo}
  resp -> resp
end

Do no match all clause, and let it fail for unknown scenarios:

case foo(bar) do
  {:ok, bar} -> {:ok, bar.foo}
  {:error, resp} -> {:error, resp}
end

Again, silly example, but what I mean is: exceptions like CaseClauseError are better errors to get than unexpected values escaping out of your own code, believe me.

Well, I’ve some:

1. Understanding some key concepts of Elixir, which @josevalim nailed explaining them on his keynote for last ElixirConf EU. For those who like to go straight to the point, is the “What is Elixir? (ElixirConf version)” part I’m talking about. What I mean is that, once you understand the concepts he talks about, you will understand how Elixir is made to work, and consequently do better code for Elixir.

2. Use railway oriented development, and Kernel.SpecialForms.with/1 is a great tool for it. Pipe operators are great when you have to make a simple job in many steps, but when you have to handle errors on any of these steps, with fits better.

3. Another silly thing I do is to avoid var attributions on my functions, at all. I know, maybe a lot silly, but conceptually it’s very tight with what @AstonJ said. No attributions help me to think when I can extract another function to do something that I’m saving in a variable to use after. Of course, that’s not something to do in every single case, sometimes it’s a good idea to save calculated values which will be used a lot later. But most times, you could do this:

   def foo(map) do
     bar = Map.fetch(map, :bar)
     "ID: #{bar.id}, NAME: #{bar.name}"
   end
   

   Without attributions:

   def foo(map) do
     map
     |> Map.fetch(:bar)
     |> do_foo()
   end
   
   def do_foo(bar) do
     "ID: #{bar.id}, NAME: #{bar.name}"
   end
   

   I know, silly example, but on complex cases it can help you a lot. Hope you got what I mean.