The Human Side of Elixir

https://akoutmos.com/post/betting-on-elixir/

by feross • 5 years ago

186 76 5 years ago

japhib• 5 years ago

1. What's funny about the photo at the top of this blog post is that it scales with the width of the window you're using to view it. That normally would seem like a bug but it actually works with this photo, to the point that I can't tell what the original width of the photo is!

2. This quote is kinda funny to me:

Many of the engineers whom I work with, actively seek out Elixir specific opportunities because they enjoy the language and the run-time that much (I’ll be diving into specifically why a bit later in the post ). This is also supported by a recent StackOverflow developer survey where 68.2% of people working with Elixir, wanted to continue working with Elixir. For some comparisons, Go received a 67.9% rating and Javascript received a 66.8% rating.

It seems like OP is trying to make the point that Elixir is so special that engineers will actively seek out Elixir jobs ... and then cites stats that show that's true only 1% more than Go and Javascript.

Maybe I'm reading it wrong and OP is just trying to show that Elixir is only as loved as Go/JS, not better, but in any case the stat cited does not show Elixir is any more special than either of those other super popular languages.

(I'm currently an Elixir dev, btw. I like it well enough but I personally don't think it's enough better than Go or JS to justify switching when the community is still so small.)

lostcolony• 5 years ago

I think the case was more intended to point out it's no different than choosing Go or Javascript, in terms of developer affinity (the size of community is part of what the article is intending to address).

Personally, I find Stackoverflow's surveys pretty useless. Python has 73% "loved", which tells me...what? That 73% of Python developers like Python. But what else do they have experience with? Is this just objectively "I like Python", or "I like Python more than X"? What is X? For those who don't "love" their language (which really just translates to "they have not expressed interest in continuing to develop with it", based on what SO gives us), is it because of another language capturing their imagination more? What languages are those, have they actually used it in the past in production, etc.

carlmr• 5 years ago

For those who don't "love" their language (which really just translates to "they have not expressed interest in continuing to develop with it", based on what SO gives us), is it because of another language capturing their imagination more?

As a C++ dev, definitely Rust. It got almost everything right that is horrible with C++, while still maintaining similar power.

akoutmos3• 5 years ago

Author here. Glad you like the banner image and the zooming effect :).

Perhaps I miscommunicated what I took away from the StackOverflow survey. The point that I was trying to make was that in relation to other programming languages in the survey, Elixir ranked high with regards to how loved it is. The StackOverflow survey is just one data point in addition to the others that I bring up and like many surveys has it's own issues (like WebAssembly being a compilation target as opposed to a programming language the people program in).

eric4smith2• 5 years ago

Well echoing what the author wrote - it’s quite easy to learn Elixir.

We have a new guy who started a bit less than a month ago.

He’s now already writing functional Elixir (no pun intended) and contributing to big code base.

One of the first things I told him is that “there is no magic in elixir”. What you see is what you get.

If you understand that everything is literally a function - life is easy and using the language becomes fun.

Kototama2• 5 years ago

If you understand that everything is literally a function

Except when it's a macro :-D

ashton314• 5 years ago

Come now, macros are just functions over syntax. ;-P

But yes, the only headaches I’ve had have been with hard-to-follow macros.

That said, the Phoenix Framework has some well-chosen macros that are a delight to work with. Furthermore, all these macros are defined in your source when you create a new Phoenix project—I feel that over all there is remarkably little magic in Phoenix, and what magic there is is easily inspectable.

hinkley• 5 years ago

I'm still not entirely sure if I'll be an Elixir programmer, but I do appreciate the culture of the Elixir community. José definitely seems to be trying to Be the Change with respect to inclusivity.

ketzo2• 5 years ago

The Elixir/Phoenix forums are a genuinely delightful place. Can’t recommend them enough. Great mix of beginner questions and best-practice discussions, and commenters tend to be quite knowledgeable and very friendly.

dimitrios1• 5 years ago

And doing it in a genuine way as well. Just living out the values, instead of beating it over everyone's head, and shouting "We're inclusive! Look at us! We're inclusive! Hey everyone check us out! Inclusivity!"

paultannenbaum• 5 years ago

Metaprogramming in elixir (i.e. macros) will definitely feel like magic to most. It allows for really powerful abstractions, but doubtful the new guy would have been able to be productive in a month in a large codebase full of them. Your standard phoenix app, yes it is fairly straightforward.

Kototama2• 5 years ago

But what does a large codebase full of macros would look like? It's an anti-pattern to have too much macros. They should be used as a last-resort option.

beepbooptheory• 5 years ago

How can I get that kind of job, I would love nothing more than to be given the task of learning something for a company!

jherdman• 5 years ago

I did this twice this year at my current job. Each time I made a case for introducing something new and interesting (Typescript, and Elixir). It took some convincing, and finding the right projects to introduce these technologies, but it happened. The result is that I've shipped four projects with Typescript, and am in the middle of delivering a greenfield Phoenix (with LiveView) app.

strokirk• 5 years ago

What? There’s so much magic in Elixir and it’s ecosystem. Controllers in Phoenix, various handle_info overloads and requires implementations, misspelled atoms, pattern matching and mismatches with names structs, the implicit return… there’s so many footguns to fire at yourself.

Zababa2• 5 years ago

the implicit return

It's not magic, it's a regular feature of functional programming languages.

weatherlight• 5 years ago

pattern matching isn''t magic.... its pretty standard in FP languages, elixir just happens to match on value over type.

grumblenum• 5 years ago

HN meta question: When I see all these double-returns at the end of each sentence, should I assume it's because someone is using Slack (or another chat program where mashing return after every statement makes sense) and a bot/script to make the post? That strikes me as a very unnatural way to punctuate in a textarea form.

eric4smith2• 5 years ago

I just type weird.

No bot.

What's the point of a bot?

I type that way because I have some kind of mental condition that makes me try to make things easy to read for everyone.

sergiotapia• 5 years ago

This is kind of a puff-piece highly upvoted by Elixir fanboys. I'm a fanboy too lol fwiw.

sodapopcan3• 5 years ago

Ehn, the more pro-Elixir search results out there the better.

I feel the same way as the author and really want to find a job where I can work with it full time, but my current work situation is too good to give up.

alberth2• 5 years ago

Twitter considered migrating from Ruby on Rails to Erlang 11 years ago (but ultimately chose Scala due to the Java tie-in).

https://news.ycombinator.com/item?id=2825689

I've always wonder how the Erlang ecosystem would be different today if a digital giant like a Twitter/FB/Google had used Erlang as part of their core business.

Note: yes, I realize WhatsApp owned by FB is run on Erlang.

dmitriid• 5 years ago

Facebook chat was originally written in Erlang and then migrated to internal C/C++ framework.

Giants use and experiment with a variety of languages.

bcrosby95• 5 years ago

This is why I'm always skeptical when someone says "$bigco uses $language! It's on the map!"

Yeah, well, somewhere, in some department, $bigco probably uses any random language you can think of.

zinclozenge2• 5 years ago

Hard to say, as you pointed out, Whatapp runs on Erlang, and despite their upstream patches, no BEAM based framework is competitive on the techempower benchmarks.

But let's not forget, AWS SimpleDB was written in Erlang, as well as the first iteration of Facebook Messenger.

I invested a decent amount of time in learning Elixir and Erlang and understanding BEAM. My personal takeaway, which seems to be mirrored by every big company, is that the ecosystem just isn't worth the investment.

brightball2• 5 years ago

Techempower benchmarks don’t really tell the story, especially if you look into the code being used.

Besides, Django, Rails, Laravel, etc are awful in those same benchmarks but adoption is fine.

The selling points of Erlang/Elixir are far more than simply non-real world benchmarks.

josevalim4• 5 years ago

as well as the first iteration of Facebook Messenger

I was told, from someone familiar with the project at the time, that the first iteration was done with ejabberd, which is written in Erlang, with the main purpose of bootstrapping it. Erlang was not really in consideration in the long term at the time. Not sure if it changes your take personally but hopefully adding some context helps. I am always glad to be corrected if wrong. :)

I wrote about Techempower in the past. In a nutshell, the Erlang runtime does plenty of assumptions that you would absolutely use in production but which become overhead in benchmarks like these. Previous comment here: https://news.ycombinator.com/item?id=22894191

My personal takeaway, which seems to be mirrored by every big company, is that the ecosystem just isn't worth the investment.

Your experience was guided by a decent amount of time and I actually appreciate you invested in learning it before deciding it wasn't worth it. However, I doubt every big company had the same takeaway for two reasons:

1. I doubt every big company went through the same experience (i.e. have they learned about the ecosystem?) to mirror the takeaway

2. The every quantifier is provably false, since there is Facebook/Whatsapp, PepsiCo, Klarna, Ericsson, Nokia, Mozilla, Cisco, and others using the ecosystem in production and/or investing on it (plus at least another company from FAANG using it at multiple projects)

quaunaut• 5 years ago

It's worth calling out that the TechEmpower benchmarks have been flawed as long as they've had Erlang/Elixir on them. People keep submitting changes and they keep refusing to implement them.

dudul• 5 years ago

Do you think Twitter using Scala had a big influence on the current state of its ecosystem?

alberth2• 5 years ago

There was no major users of Scala prior to Twitter that I can recall. Twitter put Scala on-the-map.

Plus, there is far less of an "ecosystem improvement" to be made with Scala since it's riding on the Java Runtime (which already had massive adoption and development prior to Twitter selecting it).

dustingetz• 5 years ago

twitter pumped tens of $M/yr of developer payroll into scala real-time infrastructure [citation needed]

mbo• 5 years ago

In the 3 years I spent writing Scala, the only major Twitter contribution I remember running into was Finagle (http://twitter.github.io/finagle/). It might have been a big influence at the time, but these days it's relegated to the scrapheap of older frameworks.

lmm2• 5 years ago

Twitter were the first to get the future/promise abstraction right and publish it widely (in Finagle). That inspired not just Scala's now-standard Futures but also the CompletableFuture in newer versions of Java and even e.g. Rust's Future, although none of them have the wonderful for/yield syntax (similar to Haskell do notation) that make it such a joy to work with in Scala.

Sadly most of the tooling funding came from the other big Scala user, who favoured an invisible-yield-point style (which I'm pretty sure inspired the model that Kotlin now uses with suspend functions).

One of the many tragedies of Scala (still the best general-purpose language on the whole, IMO) is that the community formed these somewhat siloed ecosystems that were each doing things their own way and had their own stack of libraries that didn't really play nice with each other. The language actually makes it very easy to write your own adapters (which may be why industrial users didn't create a lot of pressure to stop all the nonsense), but political fallings-out usually meant that it took years before there were "blessed"/official ways to use X with Y.

latchkey• 5 years ago

Early days of Twitter were a lot of scaling issues due to the choice and implementation of RoR and they considered a lot of things, which got a lot of public attention. 13 years ago...

https://venturebeat.com/2008/05/01/twitter-to-jump-off-ruby-...

sk55• 5 years ago

Twitter probably couldn't scale because of bad engineering, not because of RoR. For example, Shopify embraces the Ruby ecosystem and it scales up very well.

hervature• 5 years ago

Not sure if this against the guidelines (it says no job ads as submissions), but on the note of hiring Elixir developers, if anyone is interested in being involved in an early stage Elixir (Phoenix) startup, we at Jinso are hiring a senior engineer with Elixir experience and would love to hear from you: https://www.jinso.com/

Don't want to derail the conversation, but shoot us an email at admin [at] jinso.com. We are happy to tell you about us and get to know who you are!

Thaxll• 5 years ago

Do people actually enjoy FP on the long run? Most devs are used to OO.

sodapopcan3• 5 years ago

Yep, FP is really nice. A lot of what people think is going to be different is actually not that different from OO. Elixir especially ends up looking a lot like OO with its pipe operator ("string" |> String.split() vs "string".split(), for eg). Some of the major wins are immutability (which is actually very easy to grasp and a lot of people write in an immutable style in OO) and the fact you can every functions dependencies right there. The latter is actually huge for me as I always hated jumping around files, trying to see where things are coming from. FP minimizes this. There are lots of other niceties (some language-specific) but those are some of my faves.

Sometimes things take a little longer to write as you have to be slightly more verbose, but it's so much quicker to understand when coming back to it.

h0l0cube3• 5 years ago

What's better (and more flexible) than Object Oriented is Polymorphism.

The pipe operator |> that you mention is great example because it does something in OO that is typically done using a 'fluent interface'[0] often used in 'Builder' classes (i.e., the class methods return the object so that it can be chained together). The great thing about the pipe operator is that it's much more simple and flexible, it simply passes the result of the prior function as the first argument to the second. This means, unlike with a fluent API, you can pipe together functions from completely different modules:

    :crypto.hash(:md5, some_binary)
      |> :base64.encode_to_string()

Elixir also has protocols[1], which allow a function to be used across a variety of types (similar to obj-c/Swift). Which again is more flexible, as the functionality can extend a 'class' that you don't control.

Elixir also has behaviors[2], which just guarantee that a module contains a number of functions, something akin to interfaces Java.

Dialyzer can take advantage of behaviors and protocols to enforce typing constraints.

[0] https://en.wikipedia.org/wiki/Fluent_interface [1] https://hexdocs.pm/elixir/1.12/Protocol.html [2] https://hexdocs.pm/elixir/1.12/Behaviour.html

codeptualize• 5 years ago

Yes, I love it!

Zababa2• 5 years ago

I do, for some reason it fits my brain more than OO.

fish45• 5 years ago

I think many people haven't realized that different paradigms fit different people's brains in different ways; there are better paradigms for a specific person and task but it's impossible to generalize.

dharmaturtle• 5 years ago

Java/Python/C# were my first languages, and worked in them for over a decade.

I learned F# in a ~year, and then found a Clojure job. I _never_ want to go back to OO.

thibaut_barrere• 5 years ago

I started using OOP with Turbo Pascal and C++ a long time ago, and Elixir 5 years ago roughly.

Yes, I do enjoy FP on the long run, not only to write it but more importantly to maintain it (much easier in my opinion, including refactoring & tech debt reduction).

I still use OO too (e.g. with Ruby), but my Ruby style has gotten more FP-oriented as a result (e.g. ETL components which looks a lot like Elixir modules).

dnautics5• 5 years ago

After 15+ years of OO (C++, Ruby, Python, JS) I will never go back, with allowances for some relatively high bar for "if you pay me enough i will".

karmakaze2• 5 years ago

My OO definitely has a much more functional feel to it. Pretty much use OO to connect the parts so that the functions are connected from inputs through to outputs in a pipeline-y way. Monadic data, aspects, and error handling is also commonplace. I recently figured out that I can chain (value, error) in Go with different value types and not deal with input x output explosion of flatmappers--trick is to bind with closures to make zero-arg functions so only the output type varies.

wlamartin• 5 years ago

Sounds interesting, can you share a snippet?

lmm2• 5 years ago

Yes - far more than the opposite IME, it's pretty rare for someone who's good at FP to switch permanently to OO, whereas even successful, experienced OO people often switch permanently to FP.

dnautics5• 5 years ago

I'm curious about the experience of having taught a senior dev GenServers so early on. I guess it depends on what they are working on, but I think for most people (senior devs included) GenServers are YAGNI -- I have not once written a genserver for my current job, the senior might be tempted to be clever and use GenServers as code organization or as a circumvention to write stateful code, a la "objects" because GenServers are rather close to Alan Kay's original objects.

But I guess that's what code review is for!

zinclozenge2• 5 years ago

The temptation is there, but AFAIK most learning materials are good to call out that processes are for concurrency needs, and a genserver is an abstraction on top of that to help with certain things, like synchronization.

akoutmos3• 5 years ago

In my day to day work I don't write many GenServers either and I think that's a good thing. Like any tool, they can be overused and abused. It is best to stick to modules and pure functions until you really need to pull the stateful lever.

To that point, GenServers as an abstraction are super powerful and when applicable, are an amazing tool. For example, being able to control the initialization of a supervision trees using :ignore in the init callback can be handy to run DB migrations as part of the application startup. Or when used in combination with a registry it can be useful to hold on to user data in a GenServer and access it atomically across your cluster.

slezakattack• 5 years ago

As a seasoned Erlang developer, it's really foreign to me that people can go so far as to never need a GenServer since they are everywhere in Erlang. Have you had any experience with ramping up an Erlang engineer to use Elixir? After interviewing an Elixir dev for an Erlang position, it was interesting that so much of what they used in their day-to-day abstracted away the components of OTP and the Beam. Didn't really have a firm grasp of supervision trees, process linking vs monitoring, etc.

dnautics5• 5 years ago

There's so much you can use instead of GenServer.

Elixir gives you Task for one-offs, which is a superior abstraction over proc_lib, and has seamless integration with OTP things like supervision trees, which you will have to roll by hand and probably mess up if you use proc_lib.

For just stateful data, ets is much better performance-wise than a GenServer (with the tradeoff being complexity in understanding matchspecs and the like), and Agent is much simpler for dumb state and leads to better code (though I basically never use Agent).

Honestly, I think the GenServer behaviour is awful (not GenServers, themselves, they are great), because it does not engender writing well-organized code. Dave Thomas' empex talk about it is really eye-opening and you will understand the internalized pain. (I don't like his specific recommendations, and I think the ship has sailed on Elixir reimagining how GenServers are organized).

So yeah. My philosophy is don't write GenServers, unless you are really sure you need them (like maybe collaborative state for games; to wrap a stateful communication protocol, like http tcp, or an application layer over udp; or to to model something IRL or remote, e.g. browser state as in liveview, or as I have in a previous gig, qemu VM state). And even for some of these you're probably better of with a gen_statem or the like.

supervision trees, process linking vs monitoring

you still need to understand these to use Task correctly, or gen_statem, but those are really advanced topics. It's crazy, but you can get really really far without those (even if it's not, strictly speaking best practice), and it's not like once you learn about them it's hard to change your code to start using those correctly.

vasergen• 5 years ago

What is not mentioned here, the lack of static typing in elixir. I think for some people it could be no go. That is one major downside for me as well. On the other side, totally agree with the developer experience, really love it. I work profecionally with nodejs/typescript and on my free time looking on other languages, especially functional ones. I tried clojure before, but found the ecosystem in Elixir way better, especially dev tooling. It feels like it all really stick to each other. Another part, because all structured around modules, it is easy to check documentation and find the function you are looking for.

akoutmos3• 5 years ago

I personally don't miss statically typed languages having worked professionally with Java, C++, and Typescript in the past. But if static typing is your cup of tea and you want to run on the BEAM, be sure to check out the Gleam programming language https://gleam.run/

conradfr• 5 years ago

I dont' care about static vs dynamic typing but if I could at least typehint function arguments my IDE intellisense and I would be so happy :) Maybe it could even be compiled to guard clauses or something?

Writing specs is tedious and apparently not even encouraged for private functions.

OkayPhysicist• 5 years ago

Pattern matching and guards handle that aspect quite well.

shazzdeeds• 5 years ago

We use the dialyzer and also heavy usage of the @spec function signature annotation on public module functions to work around this. It’s an nice compromise between some defensive safety while still enjoying the readability of the dynamic typing.

h0l0cube3• 5 years ago

Agreed. In my experience, typespecs and dialyzer has caught a bunch of bugs living on rare code paths. If I had neglected to test those code-paths, they might have found their way in production.

And what's liberating is that there can be multiple types (including patterns) for each argument and the return value, and the spec can capture all those details. This combination of specificity and flexibility is unthinkable in most languages.

syspec• 5 years ago

This post was sponsored by digital product consultancy DockYard to support the Elixir community and to encourage its members to share their stories

The Human Side of Elixir

Related Stories