Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unpacking Elixir: Concurrency

underjord.io

Post reply on HN
Print view View original

81–90 of 138 posts

Re: Unpacking Elixir: Concurrency

#81

Post by felideon »

mikhailfranco wrote: post #79
xwowsersx wrote: post #76

Elixir with static typing would be an absolute dream. I know there's https://gleam.run/

It's not possible, because functions, pattern matching, guards, typespecs and success typing are fundamentally incommensurable: each specifies and/or enforces a subset of the other, they are all useful in their own way, but not isomorphic. Formal attempts have repeatedly failed, even when they exclude message passing, which is the most difficult (and most useful) aspect. If Wadler cannot do it, I'm sure I (or you) ca…

Are you saying Gleam has failed?

Re: Unpacking Elixir: Concurrency

#82

Post by mhanberg »

mikhailfranco wrote: post #79
xwowsersx wrote: post #76

Elixir with static typing would be an absolute dream. I know there's https://gleam.run/

It's not possible, because functions, pattern matching, guards, typespecs and success typing are fundamentally incommensurable: each specifies and/or enforces a subset of the other, they are all useful in their own way, but not isomorphic. Formal attempts have repeatedly failed, even when they exclude message passing, which is the most difficult (and most useful) aspect. If Wadler cannot do it, I'm sure I (or you) ca…

Are you aware of any of the recent advances?

There is the set theoretic types work [1] lead by Jose and a couple of PhDs and also eqwalizer by WhatsApp [2]

[1] https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... [2] https://github.com/WhatsApp/eqwalizer

Re: Unpacking Elixir: Concurrency

#83

Post by lawn »

mikhailfranco wrote: post #79
xwowsersx wrote: post #76

Elixir with static typing would be an absolute dream. I know there's https://gleam.run/

It's not possible, because functions, pattern matching, guards, typespecs and success typing are fundamentally incommensurable: each specifies and/or enforces a subset of the other, they are all useful in their own way, but not isomorphic. Formal attempts have repeatedly failed, even when they exclude message passing, which is the most difficult (and most useful) aspect. If Wadler cannot do it, I'm sure I (or you) ca…

In addition to gleam, there's also ongoing attempts to add static typing to Elixir.

Re: Unpacking Elixir: Concurrency

#84

Post by zelphirkalt »

spinningslate wrote: post #37
freedomben wrote: post #13

Earlier quoted context omitted.

Yes exactly! This is super important for people new to elixir. The vast majority of the time, you don't even need to know that there is even any concurrency. You can write entire sophisticated Phoenix apps and never need it. But when you do eventually need it, it's there and it's wonderful, once you grok the pattern.

Agree. That's a big advantage of thread-based concurrency [0] vs async/await. The decision of whether to do things sequentially or concurrently sits with the caller, not the callee. Which means it's there where you need it and out of the way when you don't. With async/await, the decision is made by a function implementer somewhere down the stack, quite probably in 3rd party code. As the caller you get no choice becau…

Is thread-based the right terminology for Erlang's lightweight processes? I guess the pattern is comparable.

Re: Unpacking Elixir: Concurrency

#85

Post by tomjakubowski »

cutler wrote: post #12

The deal-breaker for me with Elixir has always been the lack of real Elixir vectors rather than the crappy Erlang array library. Yes, I know you can use a Map with numeric keys but that's not the same.

Does nx not work for you? https://github.com/elixir-nx/nx/tree/main/nx#readme

Re: Unpacking Elixir: Concurrency

#86

Post by passion__desire »

lawik wrote: post #5
passion__desire wrote: post #2

I liked this approachable talk I watched few years ago. I wish developing in Elixir was as easy as python. https://youtu.be/xoNRtWl4fZU

What do you find more difficult? The achieving tasks in it or the getting paid to do so part?

If faced with the one-off problem shown in the video, I would have reached for a python solution like joblib etc. But knowing efficient better way to do would be additional tool. As shown in the video, it took him jumping through multiple hoops and expert help to get to his solution and without knowing beforehand if all the required pieces can be put together in Elixir ecosystem. No such hurdle in python solution.

Re: Unpacking Elixir: Concurrency

#87

Post by gpderetta »

throwawaymaths wrote: post #38
strzibny wrote: post #17

Earlier quoted context omitted.

This. I don't want to be in an event loop by default.

Hate to break it to you but in the BEAM you're always in an event loop.

At the limit, there is always an event loop in the kernel. The question is how leaky are the abstractions on top.

Re: Unpacking Elixir: Concurrency

#88

Post by nesarkvechnep »

whalesalad wrote: post #66
hinkley wrote: post #59

Earlier quoted context omitted.

Any sufficiently complicated distributed program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang

I've done this multiple times. I will not make the mistake again. Next big system is being born in Elixir.

Same as @pdimitar. I’m looking for part-time work.

Re: Unpacking Elixir: Concurrency

#90

Post by tombert »

hinkley wrote: post #59
tombert wrote: 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…

Any sufficiently complicated distributed program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Erlang

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 not drunk the Erlang koolade thinks that Go is a suitable replacement.

Post reply on HN