Hacker News Reader

Comment by qaq | Hacker News Reader

The surprising thing is Elixir has better tooling than many lang. funded by the tech giants.

I believe much of this is due to the Erlang/BEAM foundations Elixir is built on. Ericsson has invested considerably in Erlang for decades, giving Elixir a boost in the tooling department.

I think the runtime side absolutely, but package mngmnt, unit testing general dev. productivity things major kudos to Elixir team

No. Elixir has contributed a lot on its own, aside from what it inherits from Erlang. Mix, Hex, iex, Docs/doctests, ExUnit, etc.

iex runs smoothly because of erlang's console and ExUnit runs in parallel leveraging BEAM, so it's considerable. The foundation was pretty much there from the beginning.

While it's true that Elixir certainly wasn't built from the ground up, and it has benefited heavily from the work of Ericsson on Erlang, Elixir is more than Erlang with different syntax. A lot of stuff in Elixir was rewritten so that people can read the source in Elixir, and not have to know too much about Erlang.

I don’t think so. Earlang tooling, rebar3 and erlang.mk, is not really the best out there.

I'd love to get your feedback on rebar3; I've heard that opinion repeated often, but not really often have I heard specifics that we could address directly.

Not op, but just to counterbalance it, I'd like to mention that rebar3 is great. Thank you for all your time and work you put into it. With a large enough project there will be people who criticize stuff. Those who like it as a rule don't usually say anything, so it might seem like there are all these issues, problems and unhappiness, but it's just because it is an application that is used a lot.

Yeah. One thing I'm wary about though is developing blind spots due to a) knowing Erlang and OTP very well and b) knowing rebar3 itself very well.

I'm sure there are plenty of tricky traps that regulars have learned to work around and "just know how to use it without breaking it"; I have a suspicion a lot of unsatisfied people are those who come with different expectations of what the tool should do and how it should behave.

In these cases, they'll have a frustrating experience. I'd be interested to learn what it is so that we can make the whole thing better.

> I'd be interested to learn what it is so that we can make the whole thing better.

Ah good point. And rebar3 along with docs, and books are probably the first thing a newcomer will see when they explore Erlang the first time.

Maybe not the best. It is certainly quite good.

I don't think it's surprising if you consider Elixir's nature.

Languages like Go, Rust, and Haskell have to start from scratch. Getting to the point where they work at all is a huge achievement (though of course they do more than that).

Languages like Clojure run on an existing virtual machine, but want a very different programming model, so they have to invent a lot.

By contrast, Elixir runs on the BEAM and gets 99% of its features from Erlang: you still use processes, supervisors, pattern matching, etc.

So in a sense, the only reason for Elixir to exist is to provide a great developer experience for the BEAM. If it doesn't do that, you might as well use Erlang.

Very valid point

I quite like mix and hex. Now all we need is sane, Elixir-y dialyzer errors!

Disclaimer: I'm a maintainer but the next Dialyxir release makes a major improvement on this, thanks to contributions from Andrew Summers. He wrote a parser for the Erlangified term strings and uses the Elixir (1.6) pretty printer to print all the terms the way Elixir would. We're still fine-tuning the error messages and explanations but there is an RC on hex[0] - give it a spin if you haven't yet.

[0] https://hex.pm/packages/dialyxir/1.0.0-rc.3

Wow nice. The rate of progress is amazing.

thanks, the current state of dialyxir is quite good! I use it in my toolchain.

Hi Jeremy! If anyone has any questions about this work, I'm willing to answer them!

I'll check it out tonight!

Awesome. Thanks

You should try Dialyxir 1.0.0-rc3! The error reporting is vastly improved by a GSoC student.

Now you can get errors like this:

  ________________________________________________________________________________
  apps/activity_feed/lib/activity_feed/push_notification_listener.ex:10:callback_type_mismatch
  Callback mismatch for @callback push/2 in ActivityFeed.ListenerBehaviour behaviour.
  
  Expected type:
  {:error, _} | {:ok, _}
  
  Actual type:
  :ok
  ________________________________________________________________________________
  apps/activity_feed/lib/activity_feed/push_notification_listener.ex:24:pattern_match
  The pattern
  _ = {:error, _}
  
  can never match the type
  :error | :ok

Not quite -- that was me =). The GSOC student (Gabriel Gatu) is incorporating that work along with the incremental Dialyzer from the Elixir-ls project, and taking some of the new Dialyxir errors and morphing them a bit into a task that can be eventually merged back upstream into a more mainline mix task. You can track his progress here [0].

The lion's share of the work is now extracted into Erlex [1] which can be incorporated into other tools as needed.

[0] https://github.com/gabrielgatu/mix-dialyzer

[1] https://hex.pm/packages/erlex

Ooops! Sorry for getting that mixed up! erlex sounds like a neat project! I hope you make an Elixir Forum post about it so that more people are aware of it, I think it probably has quite a few good uses.

No trouble! I had unfortunate (or perhaps fortunate for Gabriel!) timing with its completion. Making a forum post is a good call! I need to throw some more docs in there, but I'll make one after that's in decent shape.

Reply on news.ycombinator.com