7 ms·

The worst part of Elixir is when you're working with other languages and you know it'd be better in Elixir.

dnautics 8y ago
It's not perfect. There's a few strange things like calling function variables with the dot notation, but it's there for a reason, and the rest of it worth the worst of the quirks. Side note, I wish variable rebinding were off by default but allowed on names with a sigil (or a ! ).
- derefr 8y ago
  > a few strange things like calling function variables with the dot notation, but it's there for a reason I feel like anyone who has written a Yacc-based parser for programming-language syntax will appreciate Elixir's grammar even more for these "quirks." Elixir's syntax is as beautiful as it can be while also being explicitly unambiguous. Which means that the language syntax is very easy to change or extend—unlike other PLs I could name, where the set of parsing rules resembles a late-game Jenga tower. Or, to put that another way: Elixir isn't just a joy to use; it's a joy to be a core maintainer of. (How often have you ever heard anyone consider that part of a programming language's UX?) Oh, and this simple, explicit set of parse rules also results in a highly-predictable and regular AST, which means you can write an macro-based DSL library in Elixir—one that will actually works with any arbitrary Elixir code hanging out inside your macro body—in not-much code, and without worry that a minor language change in the future will break your lib.
  - Bjartr 8y ago
    > fork and base your own programming language upon. (How often have you ever heard anyone consider that part of a programming language's UX?) Any time lisp macros come up?
    - dnautics 8y ago
      The dominant relational database system (Ecto) very elegantly dsl's databases.
  - dnautics 8y ago
    Specifically speaking the optionality (inexplicitness) of parens for function calls causes some parsibg difficulty. The compiler automatically assuming that a bare atom is a function call with () versus a variable, for example. However, this is really minor in the grand scheme of things, it really is one of the most beautiful pls otherwise
Thaxll 8y ago
Other language that have strong typing for instance or good performance?
- ramchip 8y ago
  I enjoy Elixir tremendously, but usually I’m forced to use another language (Python) due to popularity, not technical merits. It’s hard to sell anything that’s not in the TIOBE top 10. To answer your comment more directly though, for many systems the benefits of excellent concurrency, monitorability, and fault tolerance can outweigh those of a strong type system or raw performance. It really depends what you’re doing, and how your team likes to work. No such thing as a silver bullet and all that.
- nine_k 8y ago
  You don't have to let go of the FP goodies for a good type system or speed: take F#, or Haskell, or even Scala (with akka) or Kotlin. Ocaml or SML would do, too, but their concurrency story is not as good.
skrebbel 8y ago
Actually, the worst part of Elixir is when you're realizing that something asynchronous, of all things, would be easier in JavaScript, of all languages. Eg JavaScript lets you trivially memoize asynchronous requests, by caching Promise objects instead of responses. In Elixir you'll end up with enormous case expressions like this one: https://github.com/melpon/memoize/blob/master/lib/memoize/cache.ex#L99 https://github.com/melpon/memoize/blob/master/lib/memoize/ca...
- narrowtux 8y ago
  Elixir has a Task module that can be used like Promises. A task is a process that calculates something and eventually returns a result, which you can get synchroneously with `Task.await/1`. There's also an equivalend for Promise.all, which is just `Enum.map(tasks, &Task.await/1)`.
  - skrebbel 8y ago
    You can't use those to cache requests. You can store an Elixir task but you can only await it once. You can `.then` a JavaScript promise as often as you want which makes a promise an excellent primitive for caching things that take time (eg network requests) without triggering the same request twice.
    - _asummers 8y ago
      You can leave a process around as a cache, sending it messages when its values need to change. And if it dies for whatever reason, its supervisor can restart it to a known good state. You shouldn't concern yourself as the caller of how the cache updates itself, you should send it an explicit message like "the cache for X is out of date" and let that go and do its thing accordingly.
      - skrebbel 8y ago
        Yes and that's a lot of work for what would be a two-liner in JS. Every time someone says "just make a process and a supervisor, put it elegantly in the supervisor tree, go think through the failure modes, ponder a bit about these 3 or 4 edge cases and potential race conditions, and you're done! hooray!" I get a bit grumpy. Elixir is awesome, but there's a simplicity to a single-threaded execution model that takes away a lot of the things that make concurrency hard.
zerogvt 8y ago
Same here. Yet, as I'm gonna be job hunting soon, I feel that investing in learning more in Elixir/OTP won't land me a job (let alone a remote one). Too few jobs asking it. It seems that the vast majority is all about microservices/java (still), k8s, nodejs and the like.

It's not perfect. There's a few strange things like calling function variables with the dot notation, but it's there for a reason, and the rest of it worth the worst of the quirks. Side note, I wish variable rebinding were off by default but allowed on names with a sigil (or a ! ).

derefr 8y ago
> a few strange things like calling function variables with the dot notation, but it's there for a reason I feel like anyone who has written a Yacc-based parser for programming-language syntax will appreciate Elixir's grammar even more for these "quirks." Elixir's syntax is as beautiful as it can be while also being explicitly unambiguous. Which means that the language syntax is very easy to change or extend—unlike other PLs I could name, where the set of parsing rules resembles a late-game Jenga tower. Or, to put that another way: Elixir isn't just a joy to use; it's a joy to be a core maintainer of. (How often have you ever heard anyone consider that part of a programming language's UX?) Oh, and this simple, explicit set of parse rules also results in a highly-predictable and regular AST, which means you can write an macro-based DSL library in Elixir—one that will actually works with any arbitrary Elixir code hanging out inside your macro body—in not-much code, and without worry that a minor language change in the future will break your lib.
- Bjartr 8y ago
  > fork and base your own programming language upon. (How often have you ever heard anyone consider that part of a programming language's UX?) Any time lisp macros come up?
  - dnautics 8y ago
    The dominant relational database system (Ecto) very elegantly dsl's databases.
- dnautics 8y ago
  Specifically speaking the optionality (inexplicitness) of parens for function calls causes some parsibg difficulty. The compiler automatically assuming that a bare atom is a function call with () versus a variable, for example. However, this is really minor in the grand scheme of things, it really is one of the most beautiful pls otherwise

Thaxll 8y ago

Other language that have strong typing for instance or good performance?

ramchip 8y ago
I enjoy Elixir tremendously, but usually I’m forced to use another language (Python) due to popularity, not technical merits. It’s hard to sell anything that’s not in the TIOBE top 10. To answer your comment more directly though, for many systems the benefits of excellent concurrency, monitorability, and fault tolerance can outweigh those of a strong type system or raw performance. It really depends what you’re doing, and how your team likes to work. No such thing as a silver bullet and all that.
nine_k 8y ago
You don't have to let go of the FP goodies for a good type system or speed: take F#, or Haskell, or even Scala (with akka) or Kotlin. Ocaml or SML would do, too, but their concurrency story is not as good.

skrebbel 8y ago

Actually, the worst part of Elixir is when you're realizing that something asynchronous, of all things, would be easier in JavaScript, of all languages. Eg JavaScript lets you trivially memoize asynchronous requests, by caching Promise objects instead of responses. In Elixir you'll end up with enormous case expressions like this one: https://github.com/melpon/memoize/blob/master/lib/memoize/cache.ex#L99 https://github.com/melpon/memoize/blob/master/lib/memoize/ca...

narrowtux 8y ago
Elixir has a Task module that can be used like Promises. A task is a process that calculates something and eventually returns a result, which you can get synchroneously with `Task.await/1`. There's also an equivalend for Promise.all, which is just `Enum.map(tasks, &Task.await/1)`.
- skrebbel 8y ago
  You can't use those to cache requests. You can store an Elixir task but you can only await it once. You can `.then` a JavaScript promise as often as you want which makes a promise an excellent primitive for caching things that take time (eg network requests) without triggering the same request twice.
  - _asummers 8y ago
    You can leave a process around as a cache, sending it messages when its values need to change. And if it dies for whatever reason, its supervisor can restart it to a known good state. You shouldn't concern yourself as the caller of how the cache updates itself, you should send it an explicit message like "the cache for X is out of date" and let that go and do its thing accordingly.
    - skrebbel 8y ago
      Yes and that's a lot of work for what would be a two-liner in JS. Every time someone says "just make a process and a supervisor, put it elegantly in the supervisor tree, go think through the failure modes, ponder a bit about these 3 or 4 edge cases and potential race conditions, and you're done! hooray!" I get a bit grumpy. Elixir is awesome, but there's a simplicity to a single-threaded execution model that takes away a lot of the things that make concurrency hard.

zerogvt 8y ago

Same here. Yet, as I'm gonna be job hunting soon, I feel that investing in learning more in Elixir/OTP won't land me a job (let alone a remote one). Too few jobs asking it. It seems that the vast majority is all about microservices/java (still), k8s, nodejs and the like.