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

11–20 of 40 posts

Re: The Elixir of concurrency

#11

Post by sequoia »

"A small community also comes with some upsides: people are more motivated and willing to help, centralized tools like forums and IRC channels are still manageable"

I recognize the benefit here but I have a strong aversion to this line of decision-making. "Current thing is maturing and becoming popular, now the community is unwieldy and full of riff-raff-- on to the next thing!"

I'm in the JS community and it is suffering terribly from this line of thinking-- every time something reaches any sort of scale & there are new, bigger organizational challenges, Thought Leaders jump ship to some newer, cooler, smaller project (or language). Lather, rinse, repeat, repeat, repeat, repeat.

Online communities are like this as well (see Reddit, Hackernews, Twitter, etc.). Only difference is the cost of moving from Reddit to HN is minimal for the user, the cost of learning a new language or rewriting an app on a new platform is HUGE for developers and organizations.

So I don't know elixer & if it's cool and worthwhile, by all means let's encourage people to use it, but NOT because it's new and the community is small! Beauty fades and if you're moving on to the next thing because it's young & doesn't have any warts yet, mark my words-- you'll be moving again soon enough!

Re: The Elixir of concurrency

#12

Post by emson »

Great article thanks. One of the things that helped me learn Elixir was to play Elixir golf - it gives you a feel for the language and strengthans your thinking in a functional way. Anyway check out http://elixirgolf.com

Disclaimer I wrote a Udemy course on Elixir too, so if anyone wants a 30% here you go... https://www.udemy.com/elixir-for-beginners/?couponCode=Save3...

Re: The Elixir of concurrency

#13

Post by yarou »

sequoia wrote: post #11

"A small community also comes with some upsides: people are more motivated and willing to help, centralized tools like forums and IRC channels are still manageable" I recognize the benefit here but I have a strong aversion to this line of decision-making. "Current thing is maturing and becoming popular, now the community is unwieldy and full of riff-raff-- on to the next thing!" I'm in the JS community and it is suff…

I think you misunderstood the context of that sentence.

The way I read that was: "most people are hesitant to try a new language with a small community, and lack of stackoverflow support, but here are some potential upsides of being in a small language community".

Not so much: "hey, you should switch to this shiny new thing just because it's new".

Re: The Elixir of concurrency

#14

Post by rubiquity »

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…

+1 to learning Plug before Phoenix, too. Sometimes I feel like I have god mode activated when co-workers or friends are hung up on the connection life cycle or not sure how a piece of Phoenix works/scales. I'd add a basic understanding of OTP to that list as well.

Phoenix does do an excellent job of getting people to try Elixir, kind of like how Rails did for Ruby. Phoenix has also added a cool abstraction in Presence/CRDTs. Now that people don't have to implement that themselves I wonder if that will be as useful to people like how ORMs stormed onto the scenes in the early 2000s.

Re: The Elixir of concurrency

#15

Post by avodonosov » 

  1. Bring everything down?
  2. Try to capture the error and recover?
  3. Kill the crashed process and launch another one in its place?
  For example, C uses approach 1. Most modern languages
  with Exceptions like Java and Python use 2.
No, in Java and C the "let it crash" (aka the "failstop principle") is also used.

Re: The Elixir of concurrency

#16

Post by rubiquity »

arca_vorago wrote: post #9

I just started a new project in Elixir (aimed at systems administrators), and am very excited about using it for what it is good at, and breaking out to system for what it's not good at. To the author, this is one of the best summary writeups I have seen on it, and I read every elixir thing that comes across hn or elixir radar. I think there should be more emphasis that just because elixir doesn't necessarily do comp…

Very cool! I've had lots of ideas around how Elixir would be great for building orchestration or provisioning tools. The concurrency model and immutability are fantastic for that kind of work.

Regarding system calls and concurrency: Erlang does lots and lots of system calls. I think what that/those person/people were talking about are NIFs (Natively Implemented Functions) written in C. Those block the scheduler while calling out to C. However, that is a thing of the past with the implementation of dirty schedulers. AFAIK, Erlang/OTP 18 added better control of dirty scheduling and I think version 19 builds on that some more.

Re: The Elixir of concurrency

#17

Post by di4na »

carlesfe wrote: post #2

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

Hello. Really nice write up.

To follow up on your list of useful learning references, that talk from Chris is a bit old, but it covers all the basics. Nearly everything is still up to date. It is a bit long, but it takes time, cover everything and is not hard to follow.

https://www.youtube.com/watch?v=5kYmOyJjGDM

It was a workshop to teach the basics of Elixir at a Ruby conference. 3Hours long, but really great :)

Re: The Elixir of concurrency

#18

Post by goldbrick »

rubiquity wrote: post #14
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…

+1 to learning Plug before Phoenix, too. Sometimes I feel like I have god mode activated when co-workers or friends are hung up on the connection life cycle or not sure how a piece of Phoenix works/scales. I'd add a basic understanding of OTP to that list as well. Phoenix does do an excellent job of getting people to try Elixir, kind of like how Rails did for Ruby. Phoenix has also added a cool abstraction in Presenc…

Would you say that Plug is the Rack of Elixir?

Re: The Elixir of concurrency

#19

Post by rubiquity »

goldbrick wrote: post #18
rubiquity wrote: post #14

Earlier quoted context omitted.

+1 to learning Plug before Phoenix, too. Sometimes I feel like I have god mode activated when co-workers or friends are hung up on the connection life cycle or not sure how a piece of Phoenix works/scales. I'd add a basic understanding of OTP to that list as well. Phoenix does do an excellent job of getting people to try Elixir, kind of like how Rails did for Ruby. Phoenix has also added a cool abstraction in Presenc…

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

Re: The Elixir of concurrency

#20

Post by carlesfe »

rubiquity wrote: post #14
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…

+1 to learning Plug before Phoenix, too. Sometimes I feel like I have god mode activated when co-workers or friends are hung up on the connection life cycle or not sure how a piece of Phoenix works/scales. I'd add a basic understanding of OTP to that list as well. Phoenix does do an excellent job of getting people to try Elixir, kind of like how Rails did for Ruby. Phoenix has also added a cool abstraction in Presenc…

Author here, I definitely agree.

I tried to learn Phoenix just after Elixir, and I just couldn't do it.

Now I've written a couple of simple web apps with Plug, and realized that I don't need Phoenix for most of my use cases.

Post reply on HN