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

1–10 of 138 posts

Re: Unpacking Elixir: Concurrency

#3

Post by conradfr »

I think a few code example would have been nice.

The thing I like about concurrency in Elixir is that it's there if you need it but it's mostly not mandatory in your code, compared to Javascript where its kind of imposed on you even when it's an hindrance.

I remember one trick I used to do with LiveView on click events etc was to put all async (or "asyncable") code in a spawn function, which would speed up the return.

Re: Unpacking Elixir: Concurrency

#4

Post by Dowwie »

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

I've found Elixir to be easy to understand given what it's doing, and it's doing a lot more work than Python does for each application. The thing is, though, that there are a lot of declarative frameworks in Python that make applications go further without burdening a developer with low-level detail. Elixir does the same thing. Elixir and OTP abstract away a lot of complexity, at times too much. Import enough frameworks into your Python application and you'll be making a lot more decisions. Thinking about process management for every application you write (BEAM process, not OS process) pushes you up front to think about the paradigm that is used everywhere, and once you grasp what you're considering you can apply your understanding of concurrency when using other languages. This often happens when an Erlang/Elixir developer works with Rust: many programmers adopt message-passing rather than sharing state, and as they make their system more robust think about how to control threads/tasks, adopting OTP-like paradigms.

Re: Unpacking Elixir: Concurrency

#6

Post by out_of_protocol »

Unlike javascript, elixir makes you write synchronous code, e.g.

    def process_items(items) do
        items
        |> Task.async_stream(&Processor.process/1, max_concurrency: 2, timeout: 7000, on_timeout: :kill_task)
        |> Enum.to_list()
    end
Semantics of regular and concurrent code is the same

Re: Unpacking Elixir: Concurrency

#7

Post by jasonjmcghee »

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?

There’s definitely a bit of a learning curve if you’ve never written in a language where everything is immutable. Certain problems have to be approached in a fundamentally different way if you can’t mutate state.

Fortunately there’s Agent/OTP, but again, pretty different than other (or popular with beginners - js/python/java) languages.

Re: Unpacking Elixir: Concurrency

#8

Post by Dowwie »

out_of_protocol wrote: post #6

Unlike javascript, elixir makes you write synchronous code, e.g. def process_items(items) do items |> Task.async_stream(&Processor.process/1, max_concurrency: 2, timeout: 7000, on_timeout: :kill_task) |> Enum.to_list() end Semantics of regular and concurrent code is the same

comment here is conveying that there is no function color, where a language distinguishes standard synchronous calls from asynchronous calls

Re: Unpacking Elixir: Concurrency

#10

Post by thibaut_barrere »

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

Coming from (a lot of) Ruby which is quite close from Python IMO, initially I felt Elixir was harder, but it was just because of my habits, and the huge "comfort vendor lock-in" that both Ruby & Python provide.

Ultimately I am still as fluent with Ruby as before, but I find developing with Elixir is easier than Ruby (it took a few years to get there though).

Post reply on HN