Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir 1.11

elixir-lang.org

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Elixir 1.11

#71

Post by areichert »

princevegeta89 wrote: post #64
areichert wrote: post #61

Pretty stoked for this. I started learning Elixir a few months ago [0] and it's been a great balance of fun + practical. Way easier to get up and running compared some other FP languages I've dabbled with in the past :P Also shameless plug: we're currently working on an open source messaging product called Papercups [1] if anyone is looking for an Elixir project to hack on! [0] https://www.papercups.io/blog/elixir-no…

I know you from your previous ShowHN, good luck, your product looks great!

Thank you :)

Re: Elixir 1.11

#72

Post by nemetroid »

dcolkitt wrote: post #30

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 used Erlang in some university courses, and once wrote a simple crud app in Elixir/Phoenix, so my experience is somewhat limited.

Erlang's syntax is unusual, but after grasping the concepts I always found the language logical and easy to understand. On the other hand, I haven't been able to get comfortable with Elixir. It's a significantly larger language, which comes with higher complexity (but also lets you write code at a higher level of abstraction). I often found myself only half-understanding the code I was writing (and I always make an effort to fully understand what I'm doing).

And personally I find the Elixir syntax to be among the most confusing and inconsistent (especially when compared to Erlang).

Nevertheless, if I was making something web related, I would definitely go for Elixir (because of Phoenix). If I was making something lower-level, I would probably consider both options.

Re: Elixir 1.11

#73

Post by dnautics »

dcolkitt wrote: post #30

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.

It's not an improvement if you prefer prolog syntax (for the record, I personally don't). Everyone likes to say that syntax doesn't matter, but it can affect your time-to-POC, example comprehension, debugability, especially if you're starting a greenfield project.

Otherwise, I would say stick with elixir. It is more opinionated about how to do tests, how to organize your code, how to do documentation, how to deploy, how to use libraries, all of which will make your life way easier, especially for a greenfield project.

Re: Elixir 1.11

#74

Post by dnautics »

PopeDotNinja wrote: post #53
ihumanable wrote: post #47

Earlier quoted context omitted.

I work in Elixir most of the time but can read and write Erlang reasonably well, here's my two cents. Elixir's syntax was inspired by ruby and so if you've used ruby or look at ruby code and think, "yea, I get what's going on here" then you will likely find working with Elixir's syntax preferable to Erlang. Erlang's syntax was based off of Prolog and so it will be less familiar, unless you have done a bunch of Prolog…

Speaking for myseld, rebinding variables in Elixir is my least favorite part of the language, and I specifically avoid using the feature.

you shouldn't do it in your code, and code linters (well, credo) can check for it and yell at you. I think you might have to activate it currently.

I 100% guarantee you don't miss "immutable variables" in your REPL.

    Pid = module:start_link(...).
oh crap. start_link/n returns {:ok, _}, not naked pid.

    {ok, PidForRealThisTime} = Pid.

Re: Elixir 1.11

#76

Post by lostcolony »

joelbluminator wrote: post #37
lostcolony wrote: post #28

Earlier quoted context omitted.

I'll echo this - when I've worked in polyglot shops, specifically on a team that did a lot of Erlang, we hired for "exposure to functional paradigms", not Erlang. The only places that looked to hire the specific language (and even that was negotiable) were places that just had Java. And the average quality of applicants was universally worse.

It's a common practice to at least say what stack you're working on on a job ad. If it's not a requirement I usually see "We use Rails but don't expect you to know it already".

The JD was, obviously, far more descriptive than the four words I listed there. I'm saying the actual, relevant requirement, not the description of the job.

Re: Elixir 1.11

#77

Post by lostcolony »

andy_ppp wrote: post #70
lostcolony wrote: post #27

Earlier quoted context omitted.

The conjunction here is purely to taste, since utilitarian implies functional, as well as not particularly attractive; both are correct (as would just 'utilitarian', since it's not a loss of information, implying as it does the functional aspect).

I read that comment less literally and more like “they just about work for their function, but damn they ugly” :-)

Sure, but do you interpret "functional and utilitarian" as meaning anything different? Utilitarian tends to imply functional + ugly.

Re: Elixir 1.11

#78

Post by sodapopcan »

PopeDotNinja wrote: post #53
ihumanable wrote: post #47

Earlier quoted context omitted.

I work in Elixir most of the time but can read and write Erlang reasonably well, here's my two cents. Elixir's syntax was inspired by ruby and so if you've used ruby or look at ruby code and think, "yea, I get what's going on here" then you will likely find working with Elixir's syntax preferable to Erlang. Erlang's syntax was based off of Prolog and so it will be less familiar, unless you have done a bunch of Prolog…

Speaking for myseld, rebinding variables in Elixir is my least favorite part of the language, and I specifically avoid using the feature.

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 I can deal with re-binding when only used like this (and really, the stakes are low). More complex cases can generally always be handled with piping.

Re: Elixir 1.11

#79

Post by gmassman »

princevegeta89 wrote: post #43

All I could only ask for today is just a better ide support. I don't like vscode; even though the plugin for intellij has improved, there is still a lot to be desired

I'm a bit biased as someone who's already used to nvim, but the coc-elixir support is fantastic. Takes a bit of configuration but once you've got the language server set up it's better than any IDE.

Re: Elixir 1.11

#80

Post by dnautics »

sodapopcan wrote: post #78
PopeDotNinja wrote: post #53

Earlier quoted context omitted.

Speaking for myseld, rebinding variables in Elixir is my least favorite part of the language, and I specifically avoid using the feature.

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
Post reply on HN