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.
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.
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.
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.
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.
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.
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.
Which one is better? I've been out of that world for close to 15 years.
And something to work on for sure.
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.
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).
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.
I wished Elixir would’ve used “io” instead of “IO”.
> 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_.
We are a bitter bunch, LOL
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.
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
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.
I haven't tried LiveView but it looks very interesting.
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.
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.
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.
Syntax - Elixir has a more familiar looking Ruby derived syntax, plus some little extras like the pipe operator. In practice, once you've used either Elixir or Erlang for a few hours the syntax difference isn't that important, you get used to it quickly. That first few hours is important though - if someone doesn't get through them they're not going to learn the language. Elixir makes that a bit easier, gives you one less thing to think about during early learning and helps adoption. There are some other niceties like the pipe operator and for comprehensions that can help organise code, but you could live without them.
Macros - Erlang has no capability for metaprogramming. Macros do need to be used sparingly and carefully as they can obscure what's going on (Erlang is very literal and that's a good thing). When used well they can be a great help at avoiding boilerplate. Elixir itself uses them for things like GenServers and supervisors. This does things like providing default child specs and allowing them to be overriden in the GenServer. Phoenix makes heavier use of them, mostly seamlessly (and it's a great benefit). The router is the only place where they're slightly confusing as the magically macros generate some extra helper functions. The mix tasks (mix phx.routes) show these generated function names, but it's not the same as having a definition in a file.
Other hand wavier things include better tooling (although a lot of the improvements are now present in Erlang tooling as well) and better documentation.
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.
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.
Their argument for replacing the pipe operator is to do this instead:
foo(X) ->
final_function(maybe_function(X)).
foo(X) ->
Maybe = maybe_function(X),
final_function(Maybe).
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
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 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.
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()
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".
foo(X) ->
Y = maybe_function(X),
final_function(Y).
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).
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.
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.
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 some sense, two ways to solve the same problem.
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 :).
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.
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.
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.
i wish i could still write erlang but i've moved on to languages with much better implementations (go, rust, julia)
Why not?
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 ;)
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!"
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.
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
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 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.
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.
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.
― Bjarne Stroustrup, creator of C++ programming language
The fact that Elixir is getting some hate is a good sign - it's reach is growing.
[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 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.
Even when I hold my phone sideways, reading such short lines fatigues my eyes quickly.
What made it so bad for you? Genuine question, I don't find it offensive, or noteworthy at all.