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

131–140 of 144 posts

Re: Ten years without Elixir

#131

Post by 1_player »

pmontra wrote: post #118
vendiddy wrote: post #73

Earlier quoted context omitted.

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.

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

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.

Re: Ten years without Elixir

#132

Post by rlander »

sodapopcan wrote: post #127
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".

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

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.

Re: Ten years without Elixir

#133

Post by rlander »

dnautics wrote: post #91
rlander wrote: post #61

Earlier quoted context omitted.

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

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

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

Re: Ten years without Elixir

#135

Post by hinkley »

jacquesm wrote: post #117
whelming_wave wrote: post #63

Earlier quoted context omitted.

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,

Re: Ten years without Elixir

#136

Post by sodapopcan »

rlander wrote: post #132
sodapopcan wrote: post #127

Earlier quoted context omitted.

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

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

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?

Re: Ten years without Elixir

#137

Post by dc0d »

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

Re: Ten years without Elixir

#138

Post by dnautics »

sodapopcan wrote: post #128
dnautics wrote: post #113

Earlier quoted context omitted.

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.

Re: Ten years without Elixir

#139

Post by dguaraglia »

sevencolors wrote: post #3
richardfey wrote: post #2

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.

Negging for Programmers

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

Re: Ten years without Elixir

#140

Post by fulafel »

sodapopcan wrote: post #136
rlander wrote: post #132

Earlier quoted context omitted.

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

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.

Post reply on HN