Hacker News new | past | comments | ask | show | jobs | submit login
Ten years without Elixir (cretaria.com)
117 points by _nato_ 2 days ago | hide | past | favorite | 135 comments





From the perspective of someone coming the other direction (a developer working almost entirely with Elixir that needed to jump to Erlang docs occasionally), it's interesting to see the note on docs, and honestly the vibe I get from this blog post feels related to my personal overall gripe with the Erlang community.

To be blunt, I really dreaded needing to jump to the Erlang documentation, largely because of a perceived gap in developer empathy. Elixir documentation feels like it's written in a way that wants you to be successful and enjoy the process, while Erlang documentation feels very perfunctory. Where Elixir documentation is rife with examples and hints, Erlang documentation almost makes you feel like an idiot for wanting to see similar examples.

I wonder how much of that vibe is more due to priming because of community perception more than anything else. There's a distinct stereotype of Erlangers having a strong "I am very smart" vibe. That's not fair to a lot of the wonderful Erlang fans I've met that are extremely welcoming, but the wider Erlang community has a strong perception of gatekeeping where they almost don't seem like they want the language to be more accessible.


I've found that in general the longer someone has been on a project, the worse their documentation is.

People who have both deep practical knowledge of a domain and can explain it clearly are so rare that we tend to remember them by name. Experts can bitch all they want about how Neil deGrasse Tyson isn't a 'real astrophysicist', but lets see you try to talk to the general public, or for that matter, college students starting their senior year as undergrads in your field. Then lets have them frankly rate you on your lack of accessibility, tendency to circular reasoning, overuse of jargon, and complete lack of patience... We'll call it the head-up-own-ass quotient.

Erlang is a very, very old project, with a historically high degree of echo chamber going on. Without active pushback from a dedicated member of the core team, such things usually end in utter chaos. It is less likely that you will achieve understanding by reading documentation of that sort, than that you will accidentally summon an eldritch horror by reading it aloud and not being very precise with your pronunciation.


> Experts can bitch all they want about how Neil deGrasse Tyson isn't a 'real astrophysicist', but lets see you try to talk to the general public, or for that matter, college students starting their senior year as undergrads in your field.

You mean like Feynman, Hawking, Penrose, Brian Green, Richard Dawkins, Steven Pinker, Freeman Dyson, Edward Frenkel and so on?

I agree that it is not a sin to be "just" a science popularizer _a la_ Asimov and people who hold that belief are just being obtuse. Equally obtuse are the people who think "Those scientists cannot communicate with the common man", well guess what, that skill is distributed almost randomly among that lot, so for every scientist with an opaque style there is a wonderful communicator. The same happen in IT/CS and in any other field.


> Without active pushback from a dedicated member of the core team, such things usually end in utter chaos.

That may well be true, but Erlang is actually the opposite of utter chaos, it is extremely well designed, organized and implemented and battle hardened to a degree that would put most FOSS projects to shame.


My reading was that they were saying the documentation would end in utter chaos, not the project as a whole.

Erlangs documentation is fine. It's not 'modern', but it is actually quite good. There is a lot of it though and it isn't newbie friendly, which is a niche filled by some excellent books out there, for instance the (free!) Learn You Some Erlang website/book: https://learnyousomeerlang.com/

I find it frustrating how often on Hackernews people jump into the middle of a conversation as if the beginning of the conversation never happened.

From the top level comment:

> To be blunt, I really dreaded needing to jump to the Erlang documentation,


I onboarded a python dev onto elixir and he complained that elixir docs don't look like python docs, so it must be to some degree a matter of taste.

I gotta say I don't hate the official erlang docs, they're not terrible. The state of documentation in erlang libraries, though, is frankly atrocious. Even libraries that had their genesis in elixir (like telemetry) are basically unbearable to read. I wish at least there were a reasonable way to get erlang libraries to have their docs laid out exactly like the erlang docs.


> I onboarded a python dev onto elixir and he complained that elixir docs don't look like python docs, so it must be to some degree a matter of taste.

As someone who also came from Python I can't say I'm a fan of Elixir's docs either.

I often find myself having to externally search for Elixir / Phoenix resources and when you compare Python vs Elixir in that regard it's no contest. Almost every web dev problem you could think of is solved in Python with tons of examples, practical applications, blog posts, YouTube videos and the raw docs themselves. You'll almost certainly find high quality code you can at least work off of.

Where as with Elixir I find myself hitting dead ends in a lot of places and the docs often don't have enough details or context to understand something unless you're already an expert in which case you wouldn't need the docs. There's often 1 liners that expect you to have an understanding of the language that rivals its creator.

At the end of the day it's not really about the literal documentation. It's how fast you can go from being stuck to unstuck and walking away with understanding how you got from stuck to unstuck.


I'd argue you're not commenting on any specific language at all here, but rather the sheer size of the community/user base for a given language.

> I'd argue you're not commenting on any specific language at all here, but rather the sheer size of the community/user base for a given language.

Yes and no. A larger community will for sure help with filling in knowledge gaps, but those gaps stem from the documentation not covering something in enough detail.

Maybe it's just me but whenever I read Elixir, Phoenix or Ecto's docs I can't really relate to them. It feels like they are written for a completely different type of person and very rarely do they focus on practical applications of something. Most of the docs feel more like a reference guide to a library's API and if you're lucky you'll get an example or 2, but there's not enough context written around it to figure out how to apply that to your specific problem. That and the docs are rarely linked to a meaningful result when Googling for stuff.

It's a much different world than Python, Ruby and PHP IMO.


Elixir's docs and guides are quite thorough and overwhelmingly focused on practical applications, I'm sorry that you clearly haven't had a good experience personally.

Again, though, reading between the lines, it sounds distinctly like your complaint is with the ecosystem and its maturity, not anything to do with the language itself. "No, it's not that!" you say, as you go on to mention three very, very mature languages with massive ecosystems that I do agree are a very different world.

Python, Ruby, and PHP are all great! It's difficult to even think of a language that has a better wealth of guides and resources out there than any of those three (with the exception of maybe JavaScript). Elixir and Erlang, two fairly niche languages that are the actual topic of conversation for this overarching thread, simply aren't comparable in that regard.


When Ruby and Rails were first getting popular in the English-speaking world, around 2008 to 2011, the documentation and community really were excellent for their size, which was a substantial contributing factor to the growth of the language. PHP, on the other hand, was pretty appalling.

Elixir inherited some of the Ruby history and contributors, and has some of the same strengths.


> Maybe it's just me but whenever I read Elixir, Phoenix or Ecto's docs I can't really relate to them. It feels like they are written for a completely different type of person and very rarely do they focus on practical applications of something.

My only experience before Phoenix was Django, and I have to say, even though it took a little while to wrap my head around Phoenix, it was about the same time it took to get my head around Django. Once I did, I found Pheonix to be more expressive and exceedingly productive.


I totally agree with you. I started learning Python about 14-15 years ago before its current popularity and its seemed to have a focus on clarity and ease of getting started. The Elixir docs less so but still ok. Ecto docs was where it started to really annoy me though.

However, after a year of developing and learning elixir I am dropping it. Just did not like it in the end, I prefer other languages and everything I like about Elixir was basically Erlang.


nick, on several platforms you have done nothing but kvetch about your elixir onboarding experience. I think it's pretty good for most people, but at the same time it's just not for everyone, and I can think only one of two things is going on.

1. You drew the unlucky straw and it's not for you, for whatever reason. 2. You have a closed-minded mentality and it's keeping you from learning elixir.


Python community and resources are amazing!

I really don't like Python but I often find loads of code in Python which do exactly what I need, so I prototype things in Python and then port them to whatever language I'm using.

I can't say I've been impressed with Python docs, it's more the surrounding community / blog posts / stack overflow which does it for me.


It's like 2000's MSDN vs current MSDN.

The erlang documentation tells you what you need to know and is accurate but it isn't helpful in the way it should be.

If you already know what you're doing, it can be a useful reference, but it doesn't aid understanding.


In other words, it's a spec sheet, which is useful for people who are already experts in the language. Beginners and intermediates, on the other hand, need it to be something more like a textbook: something that contain not just the technical details, but also commentary and examples about them that tie them to "real life" scenarios.

> 2000's MSDN vs current MSDN

Which one is better? I've been out of that world for close to 15 years.


This is my experience with OCaml docs too. Basically just type signatures/function signatures. I typically use Elixir's docs as one of my go-tos for a "Gold Standard". I mentioned this in the ReasonML community too. Whatever you do, do NOT adopt the OCaml way. Their API docs seem to be getting better.

I could see that, my biggest gripe with Erlang has always been around the "softer edges" - easy to grok tooling, easy to read documentation, etc.

And something to work on for sure.


A lot of these things are made more difficult due to lexical substitution as it's metaprogramming primitive.

The pipe operator seems silly until you learn to pipe into IO.inspect. for vscoders I use this snippet (https://slickb.it/bits/70) which also labels with the line numbers, meaning you can multiline select a bunch of lines in your pipeline and when you're done ninja them out with another multiline select (usually line numbers have the same number of characters around each other). In combination with triggering single tests, it's invaluable for isolating errors in code.

In action: https://youtu.be/WMYc3VzOSpg&t=23m20s

I suppose the problem with this snippet is that it keeps you from using more powerful tools like tracer and recon.


I think OP's point about building huge systems with pipes is well taken. They can become confusing when the break and over-use can be a code smell.

Their power, as you point it, is in the ability to jump into any statement and add another action with minimal syntax. It's extremely useful while iterating on development because you can quickly check that something works (or check on what is happening).


I think it also encourages a declarative style of programming, so that's a win if you ask me, especially for large systems, though I can't measure this.

If you’re chaining more than three or four things together I think you’re definitely doing something wrong but I’m not sure I’ve ever seen someone do that in Elixir.

I disagree. I think a common antipattern is piping only one thing.

This is good and readable:

    nuclear_missile
    |> open_hatch()
    |> open_fuel_lines()
    |> fire_thrusters(:all)
    |> configure_gps(%Coordinates{...})
This is unnecessary:

    word_count = 
      words
      |> Enum.count()
This is better:

    word_count = Enum.count(words)
Pipes read like a list of bullet points. We can easily deal with up to a dozen bullet points, but a single bullet point is bad grammar style.

the entire ecto api is built upon chaining statements together. I have a few queries that are 8-10 statements long.

Good point, I don’t use Ecto so I wasn’t aware of this.

Not an antipattern for nimble_parsec: https://github.com/ityonemo/zigler/blob/fe845a9fbbfef92da8ab...

Plus think of how much easier that pipe makes it for you to understand what is going on.


That’s a very beautiful usage of it. I hadn’t thought of it as a way to construct DSLs, but it makes a lot of sense here.

Looks like Haskell-like do notation would be helpful.

do you feel like the code presented is broken? I don't. Could it be better? Maybe... But how much? Is it worth a whole new pattern to learn?

My longest pipe chain in Elixir so far (with ~1 year of usage) is this[1], where I build a GraphQL context from an HTTP session. I personally think it's clean enough, but your comment made me wonder if it can be better.

[1] https://github.com/RodrigoLeiteF/craftup/blob/main/backend/l...


Well I believe that no pipe is better than a a handicapped pipe operator.

The Elixir implementation inverts the classical order of piping last in functional languages to the detriment of it. IMO a language should either support pipe last AND currying by default or supply a multitude of thread operators like Clojure does (->, ->>, as->, etc). Elixir's is just middle-of-the-road-weird.


Is it to its detriment? What's really at stake here? Elixir's pipe operator takes a stance, and I love that. It enforces consistency. I feel it's a lot better than having the "sometimes first, sometimes last" that Erlang and Clojure have.

IME it is. Many Elixir apis end up forcing an unnatural parameter order just so that the entire body can be piped through.

Clojure is way more consistent in this regard:

  - thread first (->) when operating on maps.
  - thread last (->>) when operating on sequences.
  - as-> "choose your own adventure".

Huh? Almost always the parameter order is "the type of the module first" (except builders bla bla). This is super easy to remember, and this convention also encourages good code organization and module naming.

The only place where pipe order bristles is Enum.reduce, but I'd bet if I counted I'd have wanted it the normal way more often than the backwards way.


I just gave reduce as an example in my response without reading yours first. Can you explain why it would be more desirable to have it last in reduce? I have never felt this pain though, again, don't come from a functional background.

The easiest way to say it is:

often you want to apply a list of actions to an object.

This is a "backward reduce".

I don't feel it often, but when I do, it's such a bummer.


I don't have a functional background so I can only empathize that only being allowed to pipe first is not what folks are used to. I am having trouble understanding your argument, however, that includes both "consistent" and "choose your own adventure". I also don't buy that, other than simply being used to it, that piping last to sequences is more "natural". "reduce a into b with c" or "reduce value a into value b using function c" reads perfectly natural to me. I'm happy to hear arguments otherwise.

You’re missing the crux of the argument: auto-currying. In languages like Elm and Ocaml all functions are single arity which means a multi-arity function is just a partially-applied single arity function thus you can treat all functions as being single arity. This also means the pipe operator can be implemented as a higher order function being, as such, first class. Languages without auto-currying have to resort to macros.

Clojure also doesn’t have auto currrying, but makes up for it by giving you 6 variants and creating a consistent default library for sequences and associative structures.

So, the pipe first operator is just a dirty hack.


I'm familiar with auto-currying from Haskell I've never worked seriously in a language that has it. But yes, that makes sense! I never thought about that.

I'm a bit stuck on your Clojure example still, though. If a language doesn't have auto-currying (or even currying at all in Elixir's case), why does the argument order matter? Whether it's a List or a Map, what does it matter if it's passed first instead of last?


There is no general implicit currying. I suppose if we are exact with CS terminology, currying means converting to 1-argument functions, so that's out.

But the threading macros do partial application in that they put the threaded-through value as an implicit argument. Look at the first examples in https://clojure.org/guides/threading_macros - the -> (thread-first) macro needs functions like assoc and update to take the map as the first argument.

And of course explicit use of partial application is also pretty common and argument order matters similarly there, just like it would eg in Python.


I dislike uppercasing.

I wished Elixir would’ve used “io” instead of “IO”.


This must be the most unflattering congratulations I have ever read. Sounds to me like Elixir should feel guilty of being successful despite not being Erlang.

Agreed. This article was very off putting to me. And felt like someone complaining about something without taking the time to learn the something first. Probably because that’s what it was.

> I feel as though this operator could be a detriment, or at least come with some prickily moral hazards

I don’t care about how you “feel” about elixir, or how it “could” be. Take the time to learn it, then speak to what it _is_.


In so far as the driving rationale for Elixir is not needing to learn Erlang, this seems like an odd criticism of the author.

Negging for Programmers

"Negging statements considered harmful."

Underrated comment. The more I think about it, negging is almost a defining characteristics of the profession, isn’t it? C programmers complain about languages like D or Rust as fancypants languages that just add syntactic sugar. Vim users shame VSCode users ‘because who cares about nice features anyway’. People who insist in using Mutt and Pine to read their mail because ‘pretty GUIs are for pansies’, command line vs. GUI, Linux vs. Windows (and conversely, Windows vs. Linux), IRC vs. Slack and a million other examples.

We are a bitter bunch, LOL


While reading I was remembering the old saying: "If you dont have something nice to say about...", but that is not the point I guess, the point is that it come across as disingenuous and faux-polite.

Define successful...

I get the sense that the author resents the popularity of Elixir on some level. Personally I appreciate that it removes boilerplate from Erlang and has a real macro system. I’m not picky about syntax in general but when verbosity can be eliminated I think it’s almost always a good idea.

As for his opinion on the pipe operator, I have to wonder what he thinks of do-notation and point free style in Haskell, let alone APL and its ilk.


As someone who came to erlang at least in part because i hated ruby (and also rails/phoenix like frameworks) i can partially sympathise. I would however put pipe operators clearly on the pro side of elixir and also add the string handling to that list (no pun intended).

I am ultimately really happy about Elixir giving BEAM some new popularity in otherwise unreachable audiences, even though i had really hoped for something more akin to erlang2 or similar to an erlangish coffeescript.

But in the end even joe approved of elixir and i don't remember significant effort on erlang2 after initial experiments.

But the problem seems not to be syntax but more culture. I see many ruby/rails people coming into the BEAM ecosystem who bring their poisonous way to think about systems with them, even when they understand the theory about functional programming and what BEAM is about, they seem to still fall back all the time, maybe partially because the syntax is too familiar.

If is see

  defmodule TimelineLive do
     use Phoenix.LiveView
i am already fighting a puking reflex, does elixir dictate to to build a framework like this? No, but the culture bleads over.

Funnily this is a similar effect to java culture poison-swapping into javascript after class and decorator syntax was added.


> Funnily this is a similar effect to java culture poison-swapping into javascript after class and decorator syntax was added.

This is a great insight. I remember arguing at the time that adding that stuff to javascript was stupid, and people responded arguing that it increased accessibility of the language. It’s heresy, but I think there’s something to be said for bringing people in to a language slowly so they have time and inclination to leave their past experiences at the door. Rust uses the borrow checker. Ruby has metaclasses and it’s excessive magic everywhere. Javascript used to use prototype based inheritance and callbacks. I use classes sometimes and async everywhere but we paid a price for that syntax. The price was in our previously more cohesive identity as a community around how JS was written.


Do you have actual criticisms of LiveView as a technology or are you just upset about macros?

I love Elixir (former Ruby dev) but I do find many Ruby devs will turn to macros when regular functions will do.

I haven't tried LiveView but it looks very interesting.


In this case I don't see how regular functions would do. It's a way of giving a module specific behavior in a way that fits in with the application structure Phoenix enforces. That aspect of it is very Railsy, but the way it's implemented is totally different. Elixir macros are much closer to Lisp macros than Ruby macros, because they are not object oriented. I personally find them much easier to read and understand as a result. Here's __using__ in Phoenix.LiveView: https://github.com/phoenixframework/phoenix_live_view/blob/v...

I think LiveView is a very compelling technology and I'm not sure we would have it if Elixir didn't exist, because Elixir brought a whole raft of different perspectives into the Erlang community. Erlang and Elixir are about as close as two languages can get, and I find complaints from either camp about the other silly. It reminds me of Python vs Ruby flame wars.

Maybe it's just because I'm used to C# and F# and the way they feel in the .NET world, but Elixir and Erlang both feel like different syntaxes over the exact same underlying language concepts.


> While emacs has parts written in C, that portion really exists to enable elisp.

You might not have noticed that the parts of GNU Emacs written in C exceed 250,000 lines of code.


You may be responding to the wrong comment.

To add a data point: Ruby and Elixir developer here (and Python and JS). I never wrote a macro in Elixir. All that weird quote / unquote stuff is too complicated. I get the idea (code running at compile time) but the syntax is just unwelcoming. Furthermore macros tend to make code opaque and onboarding difficult. I could wake in terror if I dream of my coworkers implementing some new functionality by adding macros instead of functions.

Agreed. My approach is to use macros written by someone smarter than me (Ecto), but refrain from writing macros myself. Regular functions very often are enough.

Macros are definitely abused, but there are some cases, fewer than you think, where they make code easier to follow.


: ) Don't get me started on LiveView, i was only talking about mimicking rails mixins with the "use" macro in phoenix.

But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.

Websockets are for things like multiplayer shooters or collaborative drawing, why would someone think it is appropriate to use it to react to clicking a button.


So what should Phoenix use instead of a using macro to accomplish this?

>But now that you ask: The LiveView Idea to use websockets in general purpose web applications to achieve "reactivity" is an abomination, we have SSE and HTTP2 and also SPAs for that matter, which are from an operational and reasoning standpoint 1000% simpler and actually made for this kind of thing.

SPAs are hugely complicated though. Have you worked on a production React app? It's another order of complexity above anything existing in BEAM world, and the JavaScript tooling ecosystem is atrocious in comparison. Not to mention, you will quickly end up having button clicks that require network requests if you are not careful with your SPAs as well.

The whole point of LiveView is that you can develop an app with a similar amount of interactivity as a React app without having to go into the split-universe world that SPAs live in and all the attendant complexity that brings with it.

>Websockets are for things like multiplayer shooters or collaborative drawing, why would someone think it is appropriate to use it to react to clicking a button.

People said JavaScript was just for making ad banners flash 20 years ago and now it's the most popular language on the planet. I don't think a technology's current uses are a good predictor of what it is most useful for. See also: the web itself becoming an application platform, while it started off as a hyperlinked document retrieval system.


With respect, web sockets are a tool. If you think it is inappropriate to use a tool a certain way then your are obviously free to feel that way, but it seems a little “get off my lawn” to be upset with other folks finding creative uses for it.

My team is using live view and accomplishing incredible things with far less time and effort than we would need using other SPA technologies.

I have no idea how you can assert SSE, HTTP2 and SPAs are 1000% simpler when my experience over the last two years has been the exact opposite. Live view is exceedingly simple to work with.


Can you expand a bit more on what you mean by Ruby culture poisoning Elixir? I've never used Ruby in my life and that part was entirely lost on me.

The most obvious example is thinking in classes and then mixing in behaviour from "magic" modules through inheritance and multiple mixins.

Phoenix for example uses the "use" macros like in my post above to mimic this horrible behaviour. In an erlangish approach you would mainly explicitly import and export functions from clearly specified modules.

If you specify a -behaviour (i know its not a perfect analogy but illustrates the point) that would not magically add extreme amounts of code paths but only force you to export the correct functions for what you try to do.


While “use” resembles mixins, it is a much restricted version of whatever you can do in Ruby thanks to lexical scope, closed modules (via open classes), and immutability.

In practice “use” is closer to Ruby’s refinements, which is something that never caught in Ruby because they were too restricted.

You are right that you don’t see this in Erlang but you don’t see similar high level frameworks in Erlang either. Many don’t care for them but many also find such tools an essential part of their toolkit.


What's the advantage that Elixir has over Erlang?

Beyond the very subjective syntax, docs and whatnot I would say adoption. At this point there are a lot of Elixir libraries and frameworks that are built with Elixir and are quite popular that might not work from Erlang. Elixir is a steadily growing language with a strong enthusiastic following. Erlang is super cool but on comparison does seem to remain quite niche.

Some would say the Elixir advantage is marketing. I think there is more to it with an approachable web framework, an interesting DB library, pushing into current trends around SSR with LiveView even before Rails got Hotwire.

There's a lot of interesting work around Elixir, I've blogged about why it has me hooked a few times. Things like the Nerves project, Membrane Framework and Scenic are very cool in my book.


It is mostly a matter of taste, but Elixir has pipes, decent string primitives, a bit less boilerplate, probably some edges nicer in tooling or standard library, i would say thats about it, both run on the BEAM VM and compile to similar BEAM bytecode.

The killer feature is approachability of syntax. Every single developer i talked to complained about erlang syntax unless they did prolog before or already were an erlang developer. I prefer it but me and OP seem to be the few people who do these days.


There are parts of the OTP that really struggle with erlang's "purity". The best example I can give is the tftp module, which I wanted to use to do pxe booting. After about 2 days of trying to track the spaghetti callbacks back and forth between the tftp, tftp_engine, tftp_lib, and the callback module to fix a bug and commit a change to OTP, I gave up and wrote my own TFTP module in Elixir. With a very conservative amount of `use` macros, to help organize calls it came out beautifully: https://hexdocs.pm/trivial/Trivial.html

My point being, is that sometimes some patterns (in the case of tftp, a really awkward java-esque factory pattern) do not do so well in erlang's pure functional system and if you instead pass behaviours with `use` you can do much better and have saner code.


Re: Pipe operator

Their argument for replacing the pipe operator is to do this instead:

foo(X) ->

    final_function(maybe_function(X)).
into this:

foo(X) ->

    Maybe = maybe_function(X),

    final_function(Maybe).
instead of this:

x

|> maybe_function()

|> final_function()

Their exact words:

Spelling things out so pedantically makes code dead-simple & clear. Yes, there is a tad more code, but you will also note that nothing is hiding. Un-nesting simply dumbs things down. Now, who wouldn’t want that after hours of squinting at a screen?

People love to trot out the "It's more explicit, its a bit more code but isn't it more READABLE" argument about everything. I've heard this argument used to oppose information hiding while refactoring functions to be smaller.

And I would argue that "readable" is subjective, and that their argument is extremely weak. I love the pipeline operator and think it should be standard in every language.

Also, his "Maybe" variable becomes a pain to maintain when you have a pipeline of multiple functions.

edit: for bad formatting


This reminds me of the attitude held by some Go developers (and Rob Pike) that the reason people want map/filter/reduce and similar generic functions on containers is because they want "less code", and the counter is that a for loop is "more explicit", "clearer", "less magical", and so on.

But for someone who is used to languages where these constructs (or list comprehensions) are idiomatic, they are perfectly clear and explicit, and using a for loop instead adds complexity.


If you're interested in what the code is trying to achieve, then `map`, `filter` and the like is clearly more explicit.

If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts.

It depends on what what you're looking for.


> If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts.

In what language? GCC will happily not just optimize away your counter variable but perhaps even replace your whole loop with an SIMD operation; I suspect the Go compiler will do the same.

Also, if you're trying to optimize for performance then looking at what code gets executed is (to first order) useless; the dominant factor is cache efficiency and you can't see cache hits/misses by reading the code.


`map` can compile to wildly different things depending on what you're mapping over.

Cache efficiency is important, but so is not running O(n^2) algorithms when you didn't mean to. The latter has an outsized impact on the performance of a program, and explicit loops makes it very clear when something's up.


> explicit loops makes it very clear when something's up.

Disagree. Explicit loops hide the essence of what's happening beneath a pile of ceremony. It's easier to spot accidentally O(n^2) code in map-style code where it's a lot clearer what the code's doing.


My 2 cents: I like functional programming style but it’s annoying to have both. I like that in Golang there’s usually one way to do it, even if it’s more code. Eventually most codebases look like they’re all part of the same codebase and it’s much easier to read. In Rust people alternate between for loops and map and it really takes a while to get used to the different ways people write rust.

Yeah, I went on to read that post and also didn't quite understand their reasoning.

It seems to me that one of the benefits of the pipe operator is that it very clearly lays out the steps involved, aka

  x
  |> maybe_function()
  |> final_function()
so that the code is dead-simple and clear. It doesn't seem nested in the say way that final_function(maybe_function(X)) is.

Granted, I don't have nearly the level of experience of the author so I can't say for sure, but it seems to me like they just haven't had enough experience with the pipe operator to see how it benefits the code "beauty".


Tbh I like both the erlang style and the Elixir style and don't see a _tremendous_ amount of difference, e.g.

    foo(X) -> 
        Y = maybe_function(X),
        final_function(Y).

Both, in my eyes, yield a declarative flow without mutations and overwriting variables

The pipe operator, if you wish to use it, also has the benefit of enforcing consistency when writing functions where the primary data structure being acted on has to be the first argument.

There is, of course, still people asking for a way to specify the argument to pipe into, but I, for one, am very pleased this was never introduced (and there are no signs it ever will be).


Great post, though as a disclaimer, it mirrors my own biases and thoughts on Elixir. I'm happy for its success, but I too find it a step backward.

On the positive side, I don't think we'd have gotten rebar3 without hex guiding the way.

That being said, I wish hex.pm did a better job at distinguishing between elixir packages and erlang packages. It's always super disappointing when I try and stay pure Erlang to have to sift through Elixir packages for what I am looking for.

It's amazing how far Elixir has come in 10 years. I've always hoped it can become a gateway drug for Erlang. I don't think it will, and I guess that's okay, as it pushes Erlang forward in its own way.


> as it pushes Erlang forward in its own way.

Yes. Thank goodness erlang is starting to adopt hex. And elixir is driving better documentation in erlang via the EEP process already, as well as things that people care about in modern systems like telemetry. I think over time it will push more use of binary strings and iolists.


as one of the rebar3 co-authors, you'd have gotten rebar3 regardless of hex: we couldn't use the packages in there, and there were no packages that existed. We even entirely broke rules about how package versioning works compared to what Hex expects.

However, we didn't spit on having a package manager (that wasn't a bad lazy index hosted on a github repo), and it became a very interesting bridge across communities that we don't regret working with. Our hope now is to try and make it possible to use more Elixir libraries from the Erlang side, but the two languages' build models make that difficult at times.


In many cases, Erlang has a simplicity that is largely unmatched. I love the pipe operator and it's something I miss in a lot of languages, but just as often I miss the simple form of Erlang as well, being able to just define a series of simple, immutable clauses.

In some sense, two ways to solve the same problem.


As someone who really love Elixir, I agree with you and share your sentiment.

I always found Erlang syntax, much different but once you get use to it, very simple.

Docs, on the other hand, truly not the greatest thing :).


Erlang's VM is great, Erlang the language isn't imo. Elixir just did it better imo and this person seemingly can't stand that people seem to like it more. Let people like the things they like :P I'm really not sure this needed a blog post.

This is unflattering. Do keep in mind that erlangs was built in the mid 80s so for it's time it was fantastic, and erlang is relatively conservative in it's language (which is not a wrong choice) so it just hasn't caught up, and it might never, and that's okay.

Sure, but this article called out Elixir in a most unflattering way too, two wrongs may not make a right but I don't see the point of this post to do anything other than what I did right there state an opinion that is going to rustle some jimmies. There's no real objective discussion to be had here.

Edit: That said I'm not being contrarian for the sake of it, I tried both Erlang and Elixir. Elixir however, is the one that kept me because I knew I wanted the benefits of that VM and the OTP capabilities to a degree but the niceties of a modern language which is after all a major reason I choose a language to do a job and be easy to write and maintain which I feel Erlang lacks the latter.


> Elixir just did it better imo and this person seemingly can't stand that people seem to like it more.

The post does read more like venting than a structured critique, but a few of his points are still valid.

Every time I hear someone praising Elixir, it's never about some Elixir-specific feature but usually about something that Erlang has provided for ages like pattern matching, lightweight processes, supervisors, the preemptive scheduler. Given this, I'm sure you can appreciate how bittersweet this can be for an Erlang developer.

To me Elixir is just a more complex, verbose and less elegant version of Erlang so it kinda frustrates me when newcomers would rather learn Elixir than plain Erlang.


Elixir code out there is much cleaner than erlang code bases. In terms of organization, picking names. And there's much more dedication to testing and documentation. I think these software habits are very important for newcomers, and so if you are truly dedicated to the craft of software you probably should want them to learn Elixir even if the language is 25% more cumbersome in the small. There is something about the terseness of erlang that I think carries over to a mentality of not writing tests and not documenting. It doesn't help that it is less of a part of the culture (probably since it's an older language, Elixir is a post-"software-testing-revolution" language; Erlang is a pre-testing-revolution language).

> Elixir code out there is much cleaner than erlang code bases.

You do understand this is just your subjective opinion and not a universal truth, right?

You are basing your argument as if it was a fact that Elixir is “cleaner” (whatever that means) and that there was a thing called “software-testing-revolution” which Erlang was never a part of. Both are subjective and, frankly, plain BS.

> if you are truly dedicated to the craft of software you probably should want them to learn Elixir

Oh boy, I don’t even know where to start... so you’re basically implying that Erlang programmers are not “truly dedicated to the craft of software”? It would be laughable if it wasn’t just sad.

This is the Ruby world mentality that just rubs me the wrong way. Not even worth carrying on with the discussion.


I legitimately could not get passed the choice of syntax, module organization etc. I believe many people feel the same way. Verbosity is good imo, languages are read more than written and Erlang is too terse for me. I love Erlang conceptually and I love that Elixir made it accessible to me because I otherwise would have just avoided the Erlang ecosystem all together and would have gone with Go, the thought of which makes me shudder because I am not a fan there. I can completely understand it being bittersweet and not that I knowingly represent a majority but I suspect many people think the same way I do in regards to writing in Erlang. To me terse != elegant and I find Elixir goes the mile for me there in what I do find elegant.

It's curious how these matters can be subjective. It's Erlang the verbose one for me: the commas at the end of the lines. Of course Elixir has all those do/end and commas in the with statement (I wish it was part of the language and not a macro). Maybe I was just too happy to do without the trailing ; when I moved to Ruby and Python from C and Java.

> Let people like the things they like

Does that include writing blog posts? Or, liking Erlang over Elixir? Or, bashing Elixir?

How do any of those stop people from liking what they like? Unlike, what you did.

I'm not really sure this needed a hypocritical comment.


"Unlike what I did" care to clarify?

i couldn't disagree more. erlang is a great language let down by it's primitive and esoteric vm

i wish i could still write erlang but i've moved on to languages with much better implementations (go, rust, julia)


> Erlang the language isn't imo.

Why not?


Personal thoughts:

In Elixir you have consistent utf-8 binary string usage everywhere, consistently named modules/functions, consistently ordered arguments/return values, and, thanks to the pipe operator, in 3rd party code as well.

And none of that in erlang ;)


No separation between header and code, structs are better than records (because they bear their data labels when you inspect them, even if you send to another node that doesn't recognize them), and also since elixir requires that the tags are modules, you can use them for polymorphism (this is the best of OOP without OOP).

Much better documentation support, better compile time infrastructure, smart metaprogramming (this package would be a PITA in erlang: https://github.com/ityonemo/zigler), opinionated but optional directory organization. Module namespaces which are trivially subdivided and aliased, easier time making anonymous GenServers. The Task module, full stop. The registry module, as well.


Thanks.

most of that has to with libraries, not the language. I'd take good libraries with Erlang semantics and syntax over good libraries with other lang's semantics and syntax.

Thanks.

Not really the underlying concepts again the VM and OTP stuff are pretty neat, but the fact that it's fairly esoteric when it comes to writing it imo. That may be a shallow opinion but it did keep me away from the language in a way Elixir did not, time is money and I believe Elixir is far easier to write and maintain and as such is quicker to work in with the right tools to boot.

How is this number two on the front page

HN Loves Elixir. I guess a bunch of people upvoted without reading?

I once tried web framework after web framework, anything I could find, for Erlang. Many were outdated and I could no longer get them running. I was not an Erlang pro, so perhaps they did still work, but no instructions on how to get them working.

Some offered documentation and I followed every single step, until something did not work any longer, like adding certificates. Simply could not make it accept the certificates I created using openpgp moments earlier and of course no documentation on what the certificates need to look like. I think that was Cowboy. The lack of beginner friendly documentation made me desparate. There must be one good and simply working web framework, I thought. I found a chat for N2O and entered that, asking questions and how to do something minimal with N2O, not a whole chat, which was the starting point of the framework, the only example it came with, which it already created, when you followed the tutorial or some steps I had found. I had seen interesting things in a video about it, particularly and how it handles / creates JS inside Erlang.

When asking for help and mentioning, that no other framework had worked and that I need more documentation, which there is a lack of, I was told to stop "trolling" and to "f* off" ... That was only one person (one contributor of the framework actually), but others did not offer any insight or help either. That was when I stopped looking into Erlang in my free time, trying to get a web project going. I simply gave up at that point.

Erlang itself is a great language. I often mention it as a language, where a lot of things are already there for a looong time. Concepts, which more and more languages now adopt for themselves and hype about. I have to agree with lack of beginner friendly documentation though, which is not "Look at the code!"


Build It with Nitrogen: https://builditwith.com/nitro

This is a really excellent book, and a great introduction to Erlang with a mature web framework.

And it's refreshing to have an alternative to the 'Rails' way.


Thank you for that recommendation. Might make me pick up Erlang with web development again in the future!

I thought this was an interesting perspective. I'm a big enthusiast about Elixir and I'm always curious to see how the die-hard Erlang people feel about it.

Elixir makes me want to know more Erlang but I don't think I'll ever move to Erlang for my day-to-day use.

Appreciate this author making a post commemorating Elixir with a fairly nuanced sentiment.


Content aside, I don't get why people keep criticizing the site design, and I say that as a frontend dev.

This appears to be the personal blog of a lone Erlang developer-- why should they put in effort to make bring it up to current design standards?

It does what it's designed to do. It conveys information in a simple, readable way, same as HN itself. IMO there's nothing worth criticizing here.

edit: typo


> bring it up to current design standards?

I'm curious what makes this an out-of-date design. Did easy to read go out of style at some point?

As far as I'm concerned this is the purest form of a text based blog. Pure content, decent font, Good contrast, no bullshit popups or animations to distract from the point.


> I'm curious what makes this an out-of-date design.

I'm not a designer myself but the things that strike me immediately are that the fonts and colors seem out of fashion and the site looks somewhat awkward on mobile. But that's my whole point. You wouldn't want those things on the homepage of a startup, but this isn't that. It's just a simple blog and it does a good job of being a simple blog.


> site looks somewhat awkward on mobile

Ah... yeah I'm on my desktop right now so didn't even think about that. I don't love the colors/ fonts or justification, but they also don't interfere with readability which is my #1 criteria for evaluating a site.


Text is a 25 x 16 grid of characters on my phone. Luckily I read it first on my computer. Reader mode does help though.

I didn't get a lot from this article, despite being in similar circumstances. I have a lot of Erlang experience - and I'd love to jump into Elixir, and I think Jose got a lot of things right with it. It's not just a "nicer" syntax - things like strings got fixed up.

Is this in response to the “10ish Years with Elixir” post from Jose?

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


I wouldn't say, like the author, that Erlang has "prettier syntax". At first glance, Elixir's syntax is much nicer and prettier (whatever that means). However, Erlang's syntax is both more terse and consistent. It has much fewer special cases, syntactic sugar and all. It is the syntax, once you know and understand it it's simple.

That is really my main issue with Elixir. And I can understand if I'm in the minority, but I'm more comfortable typing a bit more for a consistent and predictable syntax.


"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

― Bjarne Stroustrup, creator of C++ programming language

The fact that Elixir is getting some hate is a good sign - it's reach is growing.


We do a lot of work in Erlang and I have very reluctantly had to deal with Elixir. I, too, prefer the "purer" Erlang syntax, and have been turned off--just like the author of this essay--with the "Ruby-ness" of Elixir.

Meta: if the author happens to see this comment, just letting you know your mobile styling is a bit off. Font size and letter/line spacing is all off (far too large). Just trying to be helpful, apologies if you already know!

tl;dr: Author thinks the pipe operator introduces anti-patterns, after not using a pipe operator for 10 years.

There's room for everyone on the BEAM.

[flagged]


Wait, you would qualify it as the lamest? I really don't see how it's very different than HackerNews in aesthetics and in design philosophy (minimalist, simple etc.)

This might, impressively, be the worst Webdesign I ever saw

[x] Readable

[x] Loaded fast

[x] No moving parts

[x] Don't mess with scroll

[x] No autoplaying videos

No, it definitely isn't the worst I've seen.


I gotta put a big, giant X next to "Readable."

I have HN at 170% zoom right now. I keep most of my font sizes around 14pt minimum. I have one useless eye and another that isn't so great even corrected with contact lenses.

Give me more web design trends that emphasize fonts at a readable size AND color contrast with the background color. Dark gray Calibri Thin on a light gray background might impress some design nerds but I'll take large, margined, justified text well set from its background any day of the week.


Did you view it on a larger screen? I viewed it in mobile, I appreciate the design, but I do find it hard to read with only a few words fitting on a single line. I wonder if the poster you replied to also viewed it on mobile.

Even when I hold my phone sideways, reading such short lines fatigues my eyes quickly.


Web design was one of the better bits of this article. I don't agree with the content and I'm not a fan of full justification myself. But the simple, readable page is a sign of good taste... and makes the article easier to read.

Bigger font, straight to the point and no fuss. Contrary to you, I love its (non) design.

I miss the days when I could expect each website to look distinct and unique, for better or for worse.

Are we looking at different sites? It's a column of text with a couple of headers...

What made it so bad for you? Genuine question, I don't find it offensive, or noteworthy at all.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: