Hacker News Reader

Comment by mrdoops | Hacker News Reader

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

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 ! ).

> 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.

> 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?

The dominant relational database system (Ecto) very elegantly dsl's databases.

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

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

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.

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.

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.

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/ca...

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)`.

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.

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.

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.

At the small prize of parallelism. And now that you are dealing with workers, task queues, etc. a native process + supervisor solution doesn't seem bad at all.

It's not a contest!

All I'm saying is that there are things that Elixir isn't the best at. Is that so weird? I feel like everybody responding to me has this strong emotional need to defend Elixir. Why? it's just a tool. Like any tool it has pros and cons.

Elixir is amazing at creating parrallelized network heavy iobound applications. obviously its going to be shit if you want to do machine learning or anything computationally bound. Thats why it has amazing first class integrations!

https://github.com/fazibear/export and https://github.com/hansihe/rustler

Reply on news.ycombinator.com