4 ms·

Agree with the sentiment behind a lot of the comments above. Elixir/Erlang are awesome and there is a lot of vitality in those communities at the moment (more i

Agree with the sentiment behind a lot of the comments above. Elixir/Erlang are awesome and there is a lot of vitality in those communities at the moment (more in Elixir perhaps). Elixir is definitely a darling of HN but there are some areas where there are some shortcomings in my point of view: - A lot of people seem to love Elixir macros but I actually think that they result in a lot of compile time magic and make the code difficult to debug/read. Macros make code easy to write but supremely difficult to behind-the-scenes-understand and debug. The code that you write is transformed into something very different when you run it! Also every major Elixir library brings its own special macros which is a pain. Erlang OTOH does not use user defined code transformations (i.e. macros) so much so the code there is easier to comprehend. But the Erlang language is quite barebones and does not have the expressive power of some of its functional cousins like OCaml/ML/Haskell. Its seems that macros were an easy way to impart this expressive power to Elixir but it comes with the above mentioned costs. - The Elixir (Erlang) runtime is stateful. This leads to many advantages but I kinda love the PHP model of every request is isolated/new from the rest of the system also. This may make PHP feel clunky/slowish but then its super easy to debug. PHP works out fine for _most_ systems even at scale. If your system does not have extreme requirements then PHP should work out fine. - Elixir is not statically typed. In 2018 for a new project its hard to justify not using a typed system to make code more likely to "run" properly out of the gate or increase your confidence while refactoring it. Even a simple type system like golang's will do. No need for something complex like C++/Java/Rust etc. In summary there is a lot of good in the Erlang/Elixir ecosystem. I think it makes sense to use this platform in many scenarios. P.S. I've talked about PHP above. It continues to be fashionable to bash PHP and I feel this is a meme that must be combated. PHP 7.x is a much improved platform. Once you look past some of its historical warts you'll find that it can be very productive to work in. Of course it lacks static typing but if you specify the types of the your function parameters and (comment) annotate the type variables you can get some of the benefits of typing if you have the correct IDE/code analysis tools. (Elixir/Erlang also have "soft" static typing via dialyzer).

dnautics 8y ago
> every major Elixir library brings its own special macros which is a pain. Is this actually a problem? The macros are not really overused, most library developers are sane about limiting the use of macros, and the lexical scope of any given macros is limited by the require/include semantics. "use" is pretty bizarre, but I've never had a problem with "just roll with it"
- sidkshatriya 8y ago
  Its a problem while debugging. The code has often been so transformed that it can be unrecognizable.
  - dnautics 8y ago
    Is this from experience with elixir specifically, or is it theoretical? I've never had any problems. Can you tell me where you had a problem?
filmor 8y ago
1. Erlang has parse transforms, so it's not like Erlang has /nothing/ in this regard. They are painful to write, though, although that could probably be fixed by introducing a parse transform (apparently someone else thought the same, just found this: https://github.com/bucko909/uberpt https://github.com/bucko909/uberpt). I just didn't really /need/ parse transforms. The only ones I ever used were lager and exprecs, and regarding the latter it turned out to be much easier to get the specs right by just writing modules manually. 2. Depending on the framework you use (we just use cowboy directly), Erlang HTTP pages/endpoints are pretty light on state as well, you need to pass them information or call global functions to make them stateful. Maybe I'm not getting you right here. 3. This is an issue to me as well, but I think most Elixir and Erlang developers would agree that this would really be nice to have, at least optionally. We're right now in the process of making our codebase "dialyzer-safe" but there are so many parts of it that could be checked statically. From what I got from different talks and articles on the subject, the main issues are the dynamic "dispatch" mechanisms, like throw/error/exit and general message passing that allow for arbitrarily typed data to be thrown at arbitrary other code.
di4na 8y ago
regarding point 3: In 2018, for an actor model on the BEAM, it is really easy to justify not being statically type. For a single simple reason. No one knows how to do it. It is an open research problem and we are far from a solution still.
- sidkshatriya 8y ago
  That is true. But some other models of concurrency (e.g. golang channels) _do admit_ static typing. This is a weakness of actor model adopted in BEAM. Its a tradeoff -- do you go with untyped BEAM concurrency or typed concurrency like in golang.
  - digitalzombie 8y ago
    In Erlang you only care about cases that you care about. The let it crash mentality. Pattern matching is also good here too. In Go you have to write code to catch unwanted error and figure out what can go wrong. So there are many things in Erlang where it soften this no type weakness.
- erszcz 8y ago
  https://github.com/josefs/Gradualizer https://github.com/josefs/Gradualizer already introduced above by Zalastax is one project which shows how to do it. It implements the gradual typing model, which merges static typing a'la ML/Haskell, with dynamic typing of Erlang. Other real-world examples of gradually typed languages are Facebook's Hack and TypeScript. Erlang already has a dual nature: - the sequential part, which strives to be a pure and mostly side-effect free functional language - the concurrent part, i.e. send, receive, process preemption, message delivery semantics, etc, which is inherently stateful due to interactions between stateful processes Gradual typing fits this model well, because it provides soundness to the sequential part of the language, while leaves the message passing parts which _no one knows how to_ type dynamically typed. BTW, I've spent a while to integrate Gradualizer with Vim - https://github.com/neomake/neomake/pull/2115 https://github.com/neomake/neomake/pull/2115
  - di4na 8y ago
digitalzombie 8y ago
> Elixir is not statically typed. In 2018 for a new project its hard to justify not using a typed system to make code more likely to "run" properly out of the gate or increase your confidence while refactoring it. Even a simple type system like golang's will do. No need for something complex like C++/Java/Rust etc. Elixir was inspired by Ruby iirc and it was a project started in 2012 according to the elixir documentary by Honey. Scripting languages without static typing have its place. I don't believe all languages even new one starting in 2018 should be type. It depends on the language goals. If you want a actor concurrency model with type then try Pony.
Zalastax 8y ago
We're adressing the lack of static typing with the Gradualizer project. It's not ready for prime time yet but I find it very promising. https://github.com/josefs/Gradualizer https://github.com/josefs/Gradualizer

dnautics 8y ago

> every major Elixir library brings its own special macros which is a pain. Is this actually a problem? The macros are not really overused, most library developers are sane about limiting the use of macros, and the lexical scope of any given macros is limited by the require/include semantics. "use" is pretty bizarre, but I've never had a problem with "just roll with it"

sidkshatriya 8y ago
Its a problem while debugging. The code has often been so transformed that it can be unrecognizable.
- dnautics 8y ago
  Is this from experience with elixir specifically, or is it theoretical? I've never had any problems. Can you tell me where you had a problem?

filmor 8y ago

1. Erlang has parse transforms, so it's not like Erlang has /nothing/ in this regard. They are painful to write, though, although that could probably be fixed by introducing a parse transform (apparently someone else thought the same, just found this: https://github.com/bucko909/uberpt https://github.com/bucko909/uberpt). I just didn't really /need/ parse transforms. The only ones I ever used were lager and exprecs, and regarding the latter it turned out to be much easier to get the specs right by just writing modules manually. 2. Depending on the framework you use (we just use cowboy directly), Erlang HTTP pages/endpoints are pretty light on state as well, you need to pass them information or call global functions to make them stateful. Maybe I'm not getting you right here. 3. This is an issue to me as well, but I think most Elixir and Erlang developers would agree that this would really be nice to have, at least optionally. We're right now in the process of making our codebase "dialyzer-safe" but there are so many parts of it that could be checked statically. From what I got from different talks and articles on the subject, the main issues are the dynamic "dispatch" mechanisms, like throw/error/exit and general message passing that allow for arbitrarily typed data to be thrown at arbitrary other code.

di4na 8y ago

regarding point 3: In 2018, for an actor model on the BEAM, it is really easy to justify not being statically type. For a single simple reason. No one knows how to do it. It is an open research problem and we are far from a solution still.

sidkshatriya 8y ago
That is true. But some other models of concurrency (e.g. golang channels) _do admit_ static typing. This is a weakness of actor model adopted in BEAM. Its a tradeoff -- do you go with untyped BEAM concurrency or typed concurrency like in golang.
- digitalzombie 8y ago
  In Erlang you only care about cases that you care about. The let it crash mentality. Pattern matching is also good here too. In Go you have to write code to catch unwanted error and figure out what can go wrong. So there are many things in Erlang where it soften this no type weakness.
erszcz 8y ago
https://github.com/josefs/Gradualizer https://github.com/josefs/Gradualizer already introduced above by Zalastax is one project which shows how to do it. It implements the gradual typing model, which merges static typing a'la ML/Haskell, with dynamic typing of Erlang. Other real-world examples of gradually typed languages are Facebook's Hack and TypeScript. Erlang already has a dual nature: - the sequential part, which strives to be a pure and mostly side-effect free functional language - the concurrent part, i.e. send, receive, process preemption, message delivery semantics, etc, which is inherently stateful due to interactions between stateful processes Gradual typing fits this model well, because it provides soundness to the sequential part of the language, while leaves the message passing parts which _no one knows how to_ type dynamically typed. BTW, I've spent a while to integrate Gradualizer with Vim - https://github.com/neomake/neomake/pull/2115 https://github.com/neomake/neomake/pull/2115
- di4na 8y ago

digitalzombie 8y ago

> Elixir is not statically typed. In 2018 for a new project its hard to justify not using a typed system to make code more likely to "run" properly out of the gate or increase your confidence while refactoring it. Even a simple type system like golang's will do. No need for something complex like C++/Java/Rust etc. Elixir was inspired by Ruby iirc and it was a project started in 2012 according to the elixir documentary by Honey. Scripting languages without static typing have its place. I don't believe all languages even new one starting in 2018 should be type. It depends on the language goals. If you want a actor concurrency model with type then try Pony.

Zalastax 8y ago

We're adressing the lack of static typing with the Gradualizer project. It's not ready for prime time yet but I find it very promising. https://github.com/josefs/Gradualizer https://github.com/josefs/Gradualizer