[HN Gopher] Ten years without Elixir
___________________________________________________________________
Ten years without Elixir
Author : _nato_
Score : 63 points
Date : 2021-01-13 19:44 UTC (3 hours ago)
(HTM) web link (blog.cretaria.com)
(TXT) w3m dump (blog.cretaria.com)
| mmcclure wrote:
| 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.
| hinkley wrote:
| 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.
| eterm wrote:
| 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.
| dnautics wrote:
| 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.
| nickjj wrote:
| > 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.
| mmcclure wrote:
| 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.
| nickjj wrote:
| > 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.
| crad wrote:
| 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.
| dnautics wrote:
| A lot of these things are made more difficult due to lexical
| substitution as it's metaprogramming primitive.
| dnautics wrote:
| 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.
| blackrock wrote:
| I dislike uppercasing.
|
| I wished Elixir would've used "io" instead of "IO".
| aeturnum wrote:
| 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).
| dnautics wrote:
| 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.
| jolux wrote:
| 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.
| cultofmetatron wrote:
| the entire ecto api is built upon chaining statements
| together. I have a few queries that are 8-10 statements
| long.
| jolux wrote:
| Good point, I don't use Ecto so I wasn't aware of this.
| dnautics wrote:
| Not an antipattern for nimble_parsec: https://github.com/it
| yonemo/zigler/blob/fe845a9fbbfef92da8ab...
|
| Plus think of how much easier that pipe makes it for you to
| understand what is going on.
| jolux wrote:
| 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.
| honkycat wrote:
| 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
| _nothing wrote:
| 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".
| _nothing wrote:
| 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
| ogre_codes wrote:
| > 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.
| _nothing wrote:
| > 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.
| ogre_codes wrote:
| > 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.
| jFriedensreich wrote:
| 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.
| prophesi wrote:
| tl;dr: Author thinks the pipe operator introduces anti-patterns,
| after not using a pipe operator for 10 years.
| loveJesus wrote:
| Praise the Lord, to me the the person writing the article seemed
| to be making fun of himself a little bit. Like a disgruntled but
| loving grandpa who has his ways, acknowledging how some things
| elixir does may actually be better, giving a congratulations to
| his grandchild as the central point.
| richardfey wrote:
| 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.
| sevencolors wrote:
| Negging for Programmers
| blackrock wrote:
| That was the lamest web page I ever had to open.
|
| Please learn some decent web design. And not create your own
| weird style.
| mssundaram wrote:
| 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.)
| jolux wrote:
| 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.
| crad wrote:
| 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.
| dnautics wrote:
| > 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.
| iSloth wrote:
| How is this number two on the front page
| ogre_codes wrote:
| HN Loves Elixir. I guess a bunch of people upvoted without
| reading?
| Grimm1 wrote:
| 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.
| rad_gruchalski wrote:
| > Erlang the language isn't imo.
|
| Why not?
| out_of_protocol wrote:
| 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 ;)
| rad_gruchalski wrote:
| Thanks.
| dnautics wrote:
| 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.
| rad_gruchalski wrote:
| Thanks.
| Grimm1 wrote:
| 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.
| dnautics wrote:
| 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.
| Grimm1 wrote:
| 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.
| querulous wrote:
| 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)
| svrtknst wrote:
| 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.
| desireco42 wrote:
| 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 :).
| hans1729 wrote:
| This might, impressively, be the worst Webdesign I ever saw
| flyingfences wrote:
| I miss the days when I could expect each website to look
| distinct and unique, for better or for worse.
| eitland wrote:
| [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.
| generalk wrote:
| 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.
| ogre_codes wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-13 23:01 UTC)