Live data from Hacker News

Elixir 1.11

elixir-lang.org

81–90 of 104 posts

Re: Elixir 1.11

#81

Earlier quoted context omitted.

I'm on the fence about re-binding variables. I don't really mind it and have gotten used to the pin operator when I need it. I actually use variable re-binding quite a bit but always only in situations where I want a prime. def foo(bar) do bar = decorate(bar) {:ok, bar} end I like that better than calling it something like `new_bar`. I kind of wish there was prime syntax along the lines of `bar' = decorate(bar)` but…

my preference is to only use rebinding if I need to rename something more than once (can happen, in with blocks), and when I do it I postfix-sigil with ! as a code annotation to remind myself to watch out when refactoring the code. def foo(bar!) do bar! = decorate(bar!) bar! = some_more(bar!) {:ok, bar!} end

Ha! That's a new use of `!` I haven't seen :) But I suppose we are saying completely opposite things. I use rebinding only when I re-bind once. In your example, I would use pipes with a single re-bind:

  def foo(bar) do
    bar =
      bar
      |> decorate()
      |> some_more()

    {:ok, bar}
  end

Re: Elixir 1.11

#82

Question from someone who's never tried Erlang/Elixir but is interested. If you're starting a greenfield project in 2020, is there any reason to use baseline Erlang instead of Elixir? I get the impression that Elixir is a strict improvement (besides legacy compatibility). But this is a very very uninformed impression.

Try both. It may be because I've been doing Erlang so long but I still prefer it and its tools (like rebar3 and Common Test). I find the syntax more consistent, less verbose and the lack of Elixir style macros to mean less confusing third party libraries.

But I do think Elixir has its strength in web applications. The macros make Phoenix and Ecto much simpler for building full web applications and if I were building a full fledged interactive web application I'd reach for those.

So mainly personal preference, you may find Elixir preferable, but all that to simply say it is not a "strict improvement".

Oh, and one none personal preference reason: it is nice to do libraries that don't benefit from being written in Elixir (like postgrex and jason get a lot of performance out of using macros so there isn't an argument to write those in Erlang) and aren't specific to Elixir (like a Plug adapter) in Erlang so they are more easily usable across BEAM languages, a list that continues to grow.

Re: Elixir 1.11

#83

Earlier quoted context omitted.

I recommend starting up a side project to learn a language. That's how I learned Ruby, and consequently Ruby on Rails 15 years ago.

What's a good side project, if one is not really interested in the problem space of the side project? I.e. I mostly just program for money, so how do I motivate myself to do a side project I'm not interested in, just to learn the language? I wonder if I could ask my employer for two weeks of time to "rewrite" parts of our backend in Elixir, just so I could scratch that itch, without any of the consequences of it actu…

I find building a simple game (like tictactoe) in Phoenix Liveview to be a good learning project. You can layer on multiplayer using Phoenix pubsub once you have a working one player version. You can also then layer on structs, typespecs, or any other idiomatic features of the language that you need practice in.

Re: Elixir 1.11

#84

Question from someone who's never tried Erlang/Elixir but is interested. If you're starting a greenfield project in 2020, is there any reason to use baseline Erlang instead of Elixir? I get the impression that Elixir is a strict improvement (besides legacy compatibility). But this is a very very uninformed impression.

Why I choose Erlang:

- simpler syntax: there’s no Erlang program that you can’t read after getting comfortable with the language. Seriously. Go read OTP source or Ryaks, everything is extremely clear and explicit. To me, easier to read also means less bugs.

- It’s so different from other languages that, IMO, it makes it easier to “think in Erlang”; the syntax fits so well the semantics that I find it easier to think in terms of processes, patterns and the ocasional recursion when switching from other language (most Erlangers are polyglots IME).

*Edit: Reliable network services (Erlangs sweet spot) are much easier to write and maintain when written in a clear and explicit way. I love macros (consider myself a lisper actually) but I think they’re the wrong tool when writing bullet proof network servers (macros are basically everywhere in Elixir).

Re: Elixir 1.11

#85
Reading through the details of this release, I have to say this sort of functional backend/compiler/performance, etc style releases make the whole product as a whole better in the long run. This tick/tock approach to releases is what every software project should strive for.

Too many consumer focused products become obsessively new-feature driven development [1], often to have new things to announce, or to appease the loudest whining customers/industry critics of the day (operating systems like MacOS, Windows, and mobile platforms are the classic examples).

Much like in the design world where saying "no" often and pushing back against fanciness is critical, the same in software for pushing towards general structural improvement iterations is key to making good software.

[1] Ignoring of course the bug-fixing-driven development cycle that many projects get trapped in.

Re: Elixir 1.11

#87

Question from someone who's never tried Erlang/Elixir but is interested. If you're starting a greenfield project in 2020, is there any reason to use baseline Erlang instead of Elixir? I get the impression that Elixir is a strict improvement (besides legacy compatibility). But this is a very very uninformed impression.

I have been using Erlang since 2008, and started using Elixir in 2014.

I much prefer the Elixir syntax. It files off the rough parts of the Erlang syntax, e.g. needing to keep track of commas, periods and semicolons at the ends of lines. The most important thing Elixir adds, though, is lisp-style macros, which makes everything else easier.

This is the post which made me switch to Elixir: https://littlelines.com/blog/2014/07/08/elixir-vs-ruby-showd... We get the best of both worlds: the ease of use of Rails with the power of Erlang.

Re: Elixir 1.11

#88

Earlier quoted context omitted.

my preference is to only use rebinding if I need to rename something more than once (can happen, in with blocks), and when I do it I postfix-sigil with ! as a code annotation to remind myself to watch out when refactoring the code. def foo(bar!) do bar! = decorate(bar!) bar! = some_more(bar!) {:ok, bar!} end

Ha! That's a new use of `!` I haven't seen :) But I suppose we are saying completely opposite things. I use rebinding only when I re-bind once. In your example, I would use pipes with a single re-bind: def foo(bar) do bar = bar |> decorate() |> some_more() {:ok, bar} end

well, I guess I gave a poor example, suppose you needed to destructure that bar! out of an ok tuple.

    def foo(bar!) do
      with {:ok, bar!} 
Inspiration came from julia, where ! at the end of the function means "watch out, one of the parameters is gonna be mutated!"

Re: Elixir 1.11

#89

Earlier quoted context omitted.

I recommend starting up a side project to learn a language. That's how I learned Ruby, and consequently Ruby on Rails 15 years ago.

What's a good side project, if one is not really interested in the problem space of the side project? I.e. I mostly just program for money, so how do I motivate myself to do a side project I'm not interested in, just to learn the language? I wonder if I could ask my employer for two weeks of time to "rewrite" parts of our backend in Elixir, just so I could scratch that itch, without any of the consequences of it actu…

Exercism is great for learning a language. https://exercism.io/tracks/elixir

Re: Elixir 1.11

#90
post #85

Reading through the details of this release, I have to say this sort of functional backend/compiler/performance, etc style releases make the whole product as a whole better in the long run. This tick/tock approach to releases is what every software project should strive for. Too many consumer focused products become obsessively new-feature driven development [1], often to have new things to announce, or to appease th…

I would argue that operating systems have been feature-driven.

For years now at best you can see 1-2 minor features a year. Mostly its just some design tweaks.

Post reply on HN