Live data from Hacker News

Unpacking Elixir: Concurrency

underjord.io

131–138 of 138 posts

Re: Unpacking Elixir: Concurrency

#131
post #90

Earlier quoted context omitted.

That has definitely been my experience. There's been a good number of times I end up gluing things together with ZeroMQ and SQS and Redis where I start thinking "you know this would have been easier to get an equivalent (or better) product in Erlang". Sadly, I've only ever had one job at a shady startup that used Erlang; I would love to work for a company that sees its power, but sadly it seems that everyone who has…

But go only has 3 or 4 ways you can shoot yourself in the foot at every turn with concurrency! Better than C++, I guess.

I don't really mean to crap on Go, I actually think it's a reasonably ok language all things considered; if nothing else (at least on one machine), it gives you nearly the highest performance-to-effort ratios.

It just annoys me that people see "Go is good at concurrency", and then see "Erlang is good at concurrency", and then assume Go ~= Erlang, which is not the correct conclusion.

Re: Unpacking Elixir: Concurrency

#132
post #127

Earlier quoted context omitted.

That's not answering the question. I've written many thousands of lines of elixir and never used index based access.

Good for you but why do all mainstream languages, including Clojure, have them?

Because they're built on mutable datatypes. Elixir (and Erlang, and some flavors of lisp) are not. Instead of fudging it to make it syntactically "look like" an array access, elixir makes you flip through the list to understand the cost of what you're doing.

Even clojure's is a cheat.

Re: Unpacking Elixir: Concurrency

#133

Earlier quoted context omitted.

Of course you example is hyperbole and I certainly understand what you are saying. But the attitude that many programmers take when learning a new language that something is "harder" when it's just different than what they are used to bothers me (to be clear, I'm not directing that at you). But comparing: i = 0 for x in [1, 2, 3, 4]: i += x vs i = Enum.reduce([1, 2, 3, 4], fn x, i -> i + x end) There is nothing inher…

I find that pure functional loops with reduce or fold often get a lot harder to read/write as soon as you have more than one variable to keep track of. Imperative loops don't really have this problem.

For me it's the other way around. With reduce you have to explicitly declare what you're keeping between each iteration.

When you have an imperative loop the state of any of the variables youve declared is up in the air. It gets even worse if you've shadowed variable names.

Re: Unpacking Elixir: Concurrency

#134
post #39

Disckaimer: I have never used Elixir in any serious capacity, but I have done a good chunk of Erlang. Concurrency in Erlang sort of frustrates me...not because it's bad, but because when I use it I start getting pissed at how annoying concurrency is in nearly every other language. So much of distributed systems tooling in 2023 is basically just there to port over Erlang constructs to more mainstream languages. Obviou…

I fell in love with Erlang pretty quickly, and it’s hard for me to enjoy writing other languages. Simple concise syntax, pattern matching, immutability, error handling without branches all over the place, concurrency… it’s hard to walk away from that.

Have you tried Elixir? So many blogs etc. talk about coming to Elixir from Ruby, which I don't understand, little similarity beyond def...do...end.

Elixir uses the same VM with a different, some including myself would say better syntax. Do you still prefer Erlang syntax?

Re: Unpacking Elixir: Concurrency

#135
post #134

Earlier quoted context omitted.

I fell in love with Erlang pretty quickly, and it’s hard for me to enjoy writing other languages. Simple concise syntax, pattern matching, immutability, error handling without branches all over the place, concurrency… it’s hard to walk away from that.

Have you tried Elixir? So many blogs etc. talk about coming to Elixir from Ruby, which I don't understand, little similarity beyond def...do...end. Elixir uses the same VM with a different, some including myself would say better syntax. Do you still prefer Erlang syntax?

I dislike Elixir’s syntax for two reasons: it seems unnecessarily verbose, and it’s too much like Ruby/Python.

When I see Erlang syntax, it helps me think in Erlang.

Anyway, I haven’t given Elixir a fair chance, but it’s hard to get past my knee-jerk dislike of all the extra verbiage. I’d rather use LFE if I wanted an alternative syntax with more powerful macros.

Re: Unpacking Elixir: Concurrency

#136
post #106

Earlier quoted context omitted.

Of course you example is hyperbole and I certainly understand what you are saying. But the attitude that many programmers take when learning a new language that something is "harder" when it's just different than what they are used to bothers me (to be clear, I'm not directing that at you). But comparing: i = 0 for x in [1, 2, 3, 4]: i += x vs i = Enum.reduce([1, 2, 3, 4], fn x, i -> i + x end) There is nothing inher…

Especially when Enum.sum([1, 2, 3, 4]) Exist ;)

...and Python has

    sum([1, 2, 3, 4])
so obviously not my point :P

;)

Re: Unpacking Elixir: Concurrency

#137

Earlier quoted context omitted.

Well, give me a call if you need help. Just looking for work again lately.

Feel free to shoot me your cv/resume to the address in my profile! We just hired two new engineers this week, so the timing is not perfect, but I would like to have your info around for a rainy day which might come sooner than later.

Just did. Thank you.

Re: Unpacking Elixir: Concurrency

#138
post #127

Earlier quoted context omitted.

Good for you but why do all mainstream languages, including Clojure, have them?

Because they're built on mutable datatypes. Elixir (and Erlang, and some flavors of lisp) are not. Instead of fudging it to make it syntactically "look like" an array access, elixir makes you flip through the list to understand the cost of what you're doing. Even clojure's is a cheat.

Then maybe that's a shortcoming of absolute immutability.
Post reply on HN