Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten years without Elixir

blog.cretaria.com

Post reply on HN
Print view View original

121–130 of 144 posts

Re: Ten years without Elixir

#121

Post by pmontra »

_nothing wrote: post #45
ogre_codes wrote: post #39

Earlier quoted context omitted.

> 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.

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.

Re: Ten years without Elixir

#122

Post by baby »

djur wrote: post #66
honkycat wrote: post #24

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…

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…

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.

Re: Ten years without Elixir

#123

Post by fortran77 »

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.

Re: Ten years without Elixir

#124

Post by svrtknst »

_nothing wrote: post #38
honkycat wrote: post #24

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…

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…

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

Re: Ten years without Elixir

#125

Post by [deleted] »

rlander wrote: post #61
Grimm1 wrote: post #7

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.

> 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,…

[deleted]

Re: Ten years without Elixir

#126

Post by zelphirkalt »

fractallyte wrote: post #111
zelphirkalt wrote: post #77

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 certifica…

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!

Re: Ten years without Elixir

#127

Post by sodapopcan »

rlander wrote: post #108
sodapopcan wrote: post #79

Earlier quoted context omitted.

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".

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.

Re: Ten years without Elixir

#128

Post by sodapopcan »

dnautics wrote: post #113
rlander wrote: post #108

Earlier quoted context omitted.

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.

Re: Ten years without Elixir

#129

Post by 1_player »

jolux wrote: post #36
aeturnum wrote: post #28

Earlier quoted context omitted.

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).

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.

Re: Ten years without Elixir

#130

Post by mononcqc »

crad wrote: post #5

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…

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.

Post reply on HN