Elixir Blog Posts

[slashdotdash]

Using Elixir’s GenStage and Flow to build product recommendations. A real-world example of building a computational parallel pipeline using Flow. Step-by-step guide to building, visualising and optimising a pipeline built with the new Flow library.

Crowdsourcing product mentions, applying sentiment analysis, and scoring to rank products. Used to build the Start learning Elixir recommendation website. I’ve used this forum to source product mentions and recommendations for learning Elixir.

[slashdotdash]

I’m the author of that article. Ping me if you have any questions about CQRS/ES and Elixir.

[tony612]

btw, I created a to collect top resources about Elixir. After all, there’re too many resources. Check out it: https://github.com/tony612/the-zen-of-elixir

[AstonJ]

@mkunikow posted a link to this article earlier, it has some flattering comments about Elixir

https://smashingboxes.com/blog/choosing-your-future-tech-stack-clojure-vs-elixir-vs-go

ELIXIR

Elixir is a functional language syntactically similar to Ruby that runs on the Erlang VM (BEAM). Being Ruby-like helps its code feel familiar and subjectively beautiful. Running on the Erlang VM makes it easy to write high performing, fault tolerant code. In fact, one of its greatest features is the ability to let code crash without bringing the system to a halt. Its concurrency constructs are direct from Erlang: Actors and Agents.

You can see that the Elixir code looks like the Clojure code above, but with a more Ruby-esque take on things. In Elixir, you’ll often use the pipe (|>) operator to structure your code in a more readable way. Although the syntax is similar, the paradigms are very different. Where Ruby is object-oriented, Elixir is functional. Learning how to write code in a functional way is the biggest challenge to those who haven’t worked with functional languages before.

There are, however, some edges to the language which don’t make sense at first. I think many of them owe their heritage to Erlang. It’s that occasional twist that makes the learning curve steeper than it need be. However, I find myself loving features like pattern matching, destructuring and guard clauses. With them, it’s easy to write concise, declarative code.

[quote]
Elixir appeals largely to those with Ruby or Erlang backgrounds. Its creator, José Valim, was a Rails Core developer, so it’s no surprise his creation draws much of its inspiration from Ruby. Because of its esoteric syntax, Erlang has been one of the least approachable programming languages. Yet it sits atop an incredible piece of technology. It’s the same technology which handles most of the phone calls in the world with 99.9999999% uptime. That is 32 milliseconds of downtime a year. The creators of WhatsApp scaled to hundreds of millions of users with only a few developers in part thanks to its robustness. Elixir brings this technology to the broader public.

Thanks to the Phoenix framework, Elixir will attract a lot of Rails developers. It feels like the next generation of Rails in a functional flavored Ruby. It does things with ease that Ruby has been hacked into doing: long-running processes, multi-core processing, and WebSockets, among others. I think we’ll see Elixir use grow for both monolithic-style minimum viable products and for apps that require high user concurrency like chat, messaging, and audio/video calls. The platform can also see interesting uses in Internet of Things and machine-to-machine applications because of its ability to handle large numbers of connections.[/quote]

ELIXIR IS THE MOST FUN TO PROGRAM

Something about the interactive programming experience really vibed with me. The Erlang ecosystem allows programs to crash and recover and to hot swap code out of the box. Clojure can do these things, too, but they need extra setup.

NEW APPS SHOULD BE WRITTEN WITH CONCURRENCY IN MIND

I’m a polyglot who has learned nearly a dozen programming languages. Every year, I take on a new Perlis language (this year’s winner is Elixir!). Also, every year it becomes more and more apparent. We are past the point where you can scale up one processor to make your app faster. Nearly every new language is being built to solve this problem. If you are wanting an app that can handle what the future holds, demand to use one of these languages.

IF YOU ARE A DEVELOPER, YOU NEED TO LEARN ONE OF THESE LANGUAGES

None of them may be the Next Big Language (NBL). Yet, ideas from all are likely to make it into that NBL. These are also the type of languages that having in your Github profile tell me you’re likely the type of developer I like working with: the ones who are practical and pushing things forward.

Try them all out. See which one you like best. Right now for me, it’s Elixir. Are you playing with any of these? Are there others you’re looking at right now? Chime in below!

[mkunikow]

How Discord handles push request bursts of over a million per minute with...

[vikram7]

Wrote a blog post on the value of multiple changesets:

More Changesets, Less Problems

Hope you find it helpful. Any feedback is a welcome.

[hubertlepicki]

Blogged some of my recent thoughts:

Elixir - different kind of promises

[minhajuddin]

Optimal order for adding lists in Elixir

[knav_negi]

Hi Everyone,
I just wrote a blog about using Elixir processes as aggregate roots in DDD. Please let me know your views about it.

Elixir: Domain Driven Design with Actor Model

[dom]

What’s the added value of GenServer in this example? If read caching is what you’re looking for, I think ETS would be a much better idea. Using GenServers to represent objects makes your application complicated and brittle. For instance, since you’re using casts, in a high load situation the message queues can keep growing until the VM runs out of memory.

It’s similar to the discussion on To spawn, or not to spawn? and the Functional Web Development with Elixir, OTP, and Phoenix book thread.

[ludat]

Here is a blogpost about some not so basic aspects of Elixir, https://blog.10pines.com/2017/05/11/dissecting-elixir/ hope you enjoy it

[OvermindDL1]

I really like that, a great description overall and I’m still only part-way through.

[chvanikoff]

Hi,
I just published an article about refactoring std_json_io library, hope will be of interest for some of you: https://medium.com/@chvanikoff/lets-refactor-std-json-io-e444b6f2c580.

[OvermindDL1]

Hmm, that’s a cool read, I love seeing how such things change and develop.

[michalmuskala]

This is a great summary. I think it could be improved even further by mentioning one important aspect - naming things.

In particular the naming conventions around packages that build on top of other packages, e.g. ecto extensions, some reusable plugs, etc. It’s tempting to put your library under the Ecto.Whatever namespace, but that’s a bad idea. The Ecto namespace is already owned by the Ecto package itself and it’s easy to see what problems it might cause if it decides to add a module called Ecto.Whatever itself. It’s usually a much better idea to make the main namespace WhateverEcto or EctoWhatever - something unique to the new package.

[blackode]

@michalmuskala

It’s usually a much better idea to make the main namespace WhateverEcto or EctoWhatever - something unique to the new package.

Firstly Thanks for taking time and having a look. That means a lot to me.
what you mentioned is highly important . I don’t how I missed that.
Thanks a lot for pointing out.

[Mandemus]

Medium article was great.

However tbqh the youtube audio sounds like you are speaking orcish with your head stuck in a toilet bowl. You might want to flush that one and re-record.

[tyro]

This was interesting:

wish = fn -> fn -> fn -> IO.write "this is chain" end end end
wish.().().()   # usage

Are there any examples of this being useful/being used in e.g. elixir lang or other well-written projects?

[blackode]

@Mandemus

Medium article was great.

However tbqh the youtube audio sounds like you are speaking orcish with your head stuck in a toilet bowl. You might want to flush that one and re-record.

Thanks for that … definitely will take care of that … Thanks for the feed…