Someone brought that up on HN a couple of months ago and José explained it here. Also, if fn took a do block key then the non-sugared version would be fn, do: n -> n + 1 which is weird… or maybe it isn’t, I dunno 
Until that person brought it, though (was it you?? 
) I’d never even considered it before!
sodapopcan
0
carterbryden
Not me on HN there 
That non sugared actually version seems kinda fine to me, but then again so does the way it is now. It’s all very minor druthers instead of anything I actually care about.
I came from C, then Java, then PHP, then Elixir, so I think I’ve just always been more familiar with some kind of parentheses instead of do and end like ruby. Even today after years of elixir I’d still probably rather it was { } instead of do and end. Neither is better or worse imo, one just cemented in my brain at a younger age maybe.
0
aherranz
Although it is not the same, when I saw the “capture operator”, it reminded me of De Bruijn index - Wikipedia. It made me feel less uncomfortable when using the capture operator
1
wallyfoo
I see this shorthand so often thrown around in tutorials and demonstrations, that I was thinking it was just me. I just don’t get on with this at all. I’ll be reading someone’s work trying to understand it, and then this syntax gets thrown in casually like a brick wall in the middle of the highway.
2
sodapopcan
Nothing like exposure therapy to get used to something 
I agree it’s jarring at first, but I feel that many people see it once, think “nope!” and then hold tightly onto that feeling. If you let go of that feeling, it quickly becomes second nature to read. Of course it’s easy to make a convoluted mess with it, though that statement applies to code in general 
My biggest gripe with it is that I wish it used a different character for the variables. Something like &foo($1) for some visual separation between the declaration and the args. I suspect this may be why many people are fine with &foo/1 but not &foo(&1).
3
dimitarvp
Nah, I’ll have to disagree here. It costs them literally NOTHING to change this eye sore:
[ {:error, {:third_party_api_error, :connection_timeout}} ]
|> Enum.map(&elem(&1, 2))
To this:
[ {:error, {:third_party_api_error, :connection_timeout}} ]
|> Enum.map(fn {_status, details} -> details end)
The latter one immediately helps you understand BOTH shape of the data AND its intent (provided good naming is practiced, which it absolutely should). Zero excuses to opt for writing 20 less characters and make the life of the next guy difficult just because you feel oh-so-clever. And you yourself allude to that by saying:
This while topic reminds of me of how I get a kick out of making fun of people who write “u” instead of “you”, and I always smirk at them: “I wonder what do you do with all the extra time you gain that you saved from not typing ‘you’”.
1
dimitarvp
sodapopcan
Well, again elem is a terrible example because I hate elem and is one function I will never use, even if it breaks my “pretty pipeline.” I think some_tuple |> elem(2) is just as bad. I always pattern match tuples for the exact reason you state: you see the shape so that’s a different argument AFAIK. Enum.map(users, &shout_user_name(&1, "!!!")) is a different story.
And it’s never about typing for me. I rarely alias and only ever import if it’s a certain “type” of module, which I think we’ve talked about before Once you get used to the syntax it can become quicker to scan. YMMV, of course.
0
ellispritchard
I’ve now come to the conclusion, after years of skepticism, that Python’s indentation-based blocking is better than either do…end or curlies.
I’d not previously done much Python ‘in anger’, but now my job requires it, I’ve realised I just don’t make blocking mistakes, and never need to hunt for the beginning or end of anything.
Python-flavoured Elixir anyone?
0
sodapopcan
I’m not opposed to significant-whitespace other than I do sometimes like the ability to outdent in development to draw my eye to something. Like a debug statement, for example. I don’t make use of this too often, but I don’t find end ugly either. I do (lol) like it in Elixir since it keeps with that lispy-feeling of the underlying syntax.
2