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

The Elixir of concurrency

cfenollosa.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: The Elixir of concurrency

#31

Post by di4na »

carlesfe wrote: post #23
dimgl wrote: post #10

I'm sorry you had such a hard time getting into Elixir. Dave Thomas's book on Elixir is a very good introduction and there are a few other Elixir books out there that can get you started really quickly. The issue really starts when you start writing web servers. I always advise that anyone who wants to start using Phoenix learns how to use Plug first. Phoenix is very macro heavy which can give that magic-is-happening…

I'm sorry if it looked like I had a hard time. It wasn't hard, just long. I consider writing production code of a new language with a different paradigm in just two weeks a success! I agree with web servers, check my reply below. Plug + Router is enough for most things, and even though everybody recommends Phoenix (maybe because many want to move from Rails to Phoenix?) I found it too complicated since I've never use…

Interesting, i think there is a telk to have here. Because Phoenix is not Rail. No part is forced. Everything is modular. Maybe there is a need to put an emphasis on that more on the main guides.

Because in the end, the only "mandatory" part of Phoenix are Cowboy, an Endpoint. And that is all. If you use Channels only, you do not need a Router.

Re: The Elixir of concurrency

#32

Post by dozzie »

avodonosov wrote: post #28
honua wrote: post #27

Earlier quoted context omitted.

While similar, it's not the same. Erlang/OTP/Elixir provides baked in tools to watch, restart, etc. processes. In C you'd need to do this yourself.

The tools to watch, restart, etc are bash, ps, top, etc

Not really. Those are equivalent to monitors and links in Erlang/BEAM, if we go this line of thought. OTP is a collection of architectural patterns coded down in Erlang (what means OTP is a framework).

Re: The Elixir of concurrency

#33

Post by timlyo »

carlesfe wrote: post #2

Hi, author here, I’d appreciate any feedback, I always try to update blog posts with new info and fixes :)

I wasn't going to mentions this, but now you've commented.

>Neither developers don't want their code to crash nor Elixir promotes writing bad code.

Is this a double negative?

    Not(x nor y) = (not x) or (y)
Ok, I'm done, I'll go and sit in the corner with the other pedants now.

Re: The Elixir of concurrency

#34

Post by carlesfe »

timlyo wrote: post #33
carlesfe wrote: post #2

Hi, author here, I’d appreciate any feedback, I always try to update blog posts with new info and fixes :)

I wasn't going to mentions this, but now you've commented. >Neither developers don't want their code to crash nor Elixir promotes writing bad code. Is this a double negative? Not(x nor y) = (not x) or (y) Ok, I'm done, I'll go and sit in the corner with the other pedants now.

Hi, I'm not a native English speaker. Could you please suggest the correct way to rephrase it? Thanks!

Re: The Elixir of concurrency

#36

Post by idobai »

andy_ppp wrote: post #30
idobai wrote: post #25

> Elixir's novelty, the pipe operator, is a fantastic approach to working with state in a functional manner. Instead of running readlines(fopen(user_input(), "r")).uppercase().split(), try the more readable user_input |> fopen("r") |> readlines |> uppercase |> split. The pipe operator isn't Elixir's "novelty". Also, why is it better than the '.' syntax: > fromFile(userInput).getLines.map(_.toUpperCase) Do you get cod…

A |> B |> C second_param Is the same as: C(B(A()), second_param) It's much more powerful than that because you can create chains of functions that pipe their output i.e. Some_data |> fetch_reports |> email_users |> setup_notifications |> IO.inspect |> affirm_elixir_pipes It's 100% not the same as dot or arrow! IO.inspect allows you to print details of any data being passed but also returns the first argument passed.…

I know how the pipe op works because I've used languages with that operator(f#) but I never had the need for it for ex. in Scala. In Scala a very similar solution has been implemented but nobody uses it.

Re: The Elixir of concurrency

#37

Post by avodonosov »

dozzie wrote: post #32
avodonosov wrote: post #28

Earlier quoted context omitted.

The tools to watch, restart, etc are bash, ps, top, etc

Not really. Those are equivalent to monitors and links in Erlang/BEAM, if we go this line of thought. OTP is a collection of architectural patterns coded down in Erlang (what means OTP is a framework).

We are talking about error handling. My point: "let it crash" aka "failstop principle" is well known for decades, and practiced in all major languages.

Re: The Elixir of concurrency

#38

Post by dozzie »

avodonosov wrote: post #37
dozzie wrote: post #32

Earlier quoted context omitted.

Not really. Those are equivalent to monitors and links in Erlang/BEAM, if we go this line of thought. OTP is a collection of architectural patterns coded down in Erlang (what means OTP is a framework).

We are talking about error handling. My point: "let it crash" aka "failstop principle" is well known for decades, and practiced in all major languages.

> We are talking about error handling.

I thought we switched to a little more down-in-the-trenches discussion with you saying:

> The tools to watch, restart, etc are bash, ps, top, etc

Re: The Elixir of concurrency

#39

Post by avodonosov »

dozzie wrote: post #38
avodonosov wrote: post #37

Earlier quoted context omitted.

We are talking about error handling. My point: "let it crash" aka "failstop principle" is well known for decades, and practiced in all major languages.

> We are talking about error handling. I thought we switched to a little more down-in-the-trenches discussion with you saying: > The tools to watch, restart, etc are bash, ps, top, etc

Carried away a little. Not to say it's not interesting to compare Unix/C programs with OTP/Erlang, but it's a different subject.

Re: The Elixir of concurrency

#40

Post by alxndr »

rubiquity wrote: post #19
goldbrick wrote: post #18

Earlier quoted context omitted.

Would you say that Plug is the Rack of Elixir?

Yes that's exactly the domain that Plug sits in. It's an interface from web servers to applications. As someone who tinkered around with Rack and Ruby web servers a lot, Plug is much better designed (yay for learning from past implementations).

I'd even say that Phoenix is more akin to Sinatra than to Rails.
Post reply on HN