Live data from Hacker News

ElixirNitpicks

wiki.alopex.li

1–10 of 60 posts

Re: ElixirNitpicks

#2
Interestingly, though I am not a great Rust programmer, nor a great Elixir programmer (I have written programs in both languages). And, gotten a little ways through the amazing Exercism (https://exercism.org/tracks/elixir).

What I loved about this writeup was the way I could review both by comparing two languages in which I have a moderate understanding. The comparison of imports was very engaging to my brain.

I really feel like I could accelerate learning a new language if the tutorial was written by comparing that language to another language I already know. Partially I just think that would keep my interest. I'm never excited when I start learning a new language and read the description of how to import a module in that new language; my brain would say "doh, I'll review this when I actually start writing code, let me zone out here..." I feel like most language tutorials feel obligated to cover this minutiae and there is always a lot to review when you are writing a tutorial. People would probably get upset if you skipped that stuff, but for me as a reader, I really prefer this approach here.

Re: ElixirNitpicks

#3
post #2

Interestingly, though I am not a great Rust programmer, nor a great Elixir programmer (I have written programs in both languages). And, gotten a little ways through the amazing Exercism ( https://exercism.org/tracks/elixir ). What I loved about this writeup was the way I could review both by comparing two languages in which I have a moderate understanding. The comparison of imports was very engaging to my brain. I re…

https://www.languagetransfer.org/ tries to do this with spoken languages

Re: ElixirNitpicks

#4
I add my own nitpick about the with statement.

If I start with this code

  true = is_email_address?(email)
  true = EmailAddresses.is_available(email)
and I decide to turn it into a with like this

  with true 
then I have to go line by line replacing = with I understand why with could not work with the = matching operator (it's a macro) but that's about language design, ergonomics and in part not making developers do the job of the compiler.

Re: ElixirNitpicks

#5
post #4

I add my own nitpick about the with statement. If I start with this code true = is_email_address?(email) true = EmailAddresses.is_available(email) and I decide to turn it into a with like this with true then I have to go line by line replacing = with I understand why with could not work with the = matching operator (it's a macro) but that's about language design, ergonomics and in part not making developers do the jo…

Your two examples aren’t quite equivalent.

  true = false
raises a match error while

  true 
in a with statement doesn’t.

You can actually use true = false in your with statement, but it will still raise the match error.

Re: ElixirNitpicks

#6
For me it would be the Pin-Operator. Which is only needed cause variables can "mutate". IMHO it's not that common that we need to "reassign" variables, we could life without the looks-like-reassignment.

I touched Erlang before, it's hard to get my brain to accept elixir is different in regards of variables :)

Re: ElixirNitpicks

#7
post #2

Interestingly, though I am not a great Rust programmer, nor a great Elixir programmer (I have written programs in both languages). And, gotten a little ways through the amazing Exercism ( https://exercism.org/tracks/elixir ). What I loved about this writeup was the way I could review both by comparing two languages in which I have a moderate understanding. The comparison of imports was very engaging to my brain. I re…

This is why a survey in programming languages is beneficial. You want a variety to fill in the gaps and this increases capacity to learn new ones but you are also easily able to identify short comings and foot guns where people who are siloed to a single language could never be aware of which leads to instances of NIH syndrome like we've seen in Python & Go.

Re: ElixirNitpicks

#9
post #6

For me it would be the Pin-Operator. Which is only needed cause variables can "mutate". IMHO it's not that common that we need to "reassign" variables, we could life without the looks-like-reassignment. I touched Erlang before, it's hard to get my brain to accept elixir is different in regards of variables :)

    iex(1)> a=10
    10
    iex(2)> a=11
    11
Because underneath, it’s doing

    A0 = 10.
    A1 = 11.
You might not like it, because it feels like mutation, but it’s not, it’s rebinding. Just consider this as a syntactic sugar. It’s useful when doing

    conn = conn |> apply_some_change()
In the end, it does generate valid bytecode for the BEAM, and immutability is respected.

BTW You might prefer Erlang syntax, but You would lose |>

José Valim, has a great writeup about this here.

https://blog.plataformatec.com.br/2016/01/comparing-elixir-a...

Re: ElixirNitpicks

#10
post #6

For me it would be the Pin-Operator. Which is only needed cause variables can "mutate". IMHO it's not that common that we need to "reassign" variables, we could life without the looks-like-reassignment. I touched Erlang before, it's hard to get my brain to accept elixir is different in regards of variables :)

Interesting. In our codebase we do this all the time. A quick search revealed 280 occurrences of `some_var = some_var |> ...`.

I also find the pin operator much more readable, as the meaning of `{foo, ^bar} = result` doesn't require to know the context. `foo` is being assigned, `bar` is being matched on. No need to know the code before this line to interpret it.

Post reply on HN