21–30 of 144 posts
In some sense, two ways to solve the same problem.
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 t…
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.
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.
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
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 percei…
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.
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
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 percei…
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.
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 singl…
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).
Earlier quoted context omitted.
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 (t…
Earlier quoted context omitted.
> 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 ;)