Hacker News new | past | comments | ask | show | jobs | submit login

Disagree with “cleaner”.

Syntax is a subjective concern for sure. My experience has been that Erlang takes a little more effort and time to read fluidly, but only when first learning. I think this is because Erlang uses visually subtle tokens for important language distinctions (upper vs lower caps and periods being the primary culprits). Now that I've spent enough time in the ecosystem reading Erlang isn't really a problem, but Elixir's syntax felt like it took less mental effort to read when starting out.

I think Elixir making different token choices for these distinct ideas is the main reason for readability improvements. Especially since Erlang has less different tokens overall which you'd think would help reduce the noise.

It'd be nice if dissenting opinions came with elaboration to continue the discussion instead of shut it down.

The dissenting opinion that it has "cleaner" syntax came with no elaboration.

Disagree with "disagree"

...see where that leads us? Please actually voice reasons how it's not cleaner, as it's most definitely less verbose, And having less clutter is generally seen as cleaner

The original claim is just as pointless. The implication that Elixir fixes Erlang's syntax is so commonly repeated without much discussion that it has many folks dismissing the entire language before they learn it.

I think both languages have issues with Syntax but in the cleaner department, I am baffled at the insistence that Erlang is hard. Inconvenient, maybe but most of the features in Erlang are so primitive that there is little to no ambiguity of what something can mean.

Verbosity strikes both (records and binaries in Erlang vs the sigil and keyword heavy Elixir code) and certainly some folks prefer rebinding variables and colon syntax on atoms but it's certainly not without real trade-offs in common idioms (tagged tuples, special casing required for atoms like true, false, nil, interop with Erlang becomes uglier, etc).

It’s more verbose when defining functions, calling anonymous functions, and referencing atoms.

Calling functions with and without parens makes for a less clean syntax. Less consistency (plus mandates the dot notation for calling anonymous functions).

> It’s more verbose when defining functions, calling anonymous functions, and referencing atoms.

and we're finally finding out how both opinions are correct

when people say that elixir code is cleaner, they're normally talking about the significantly reduced amount of code they have to write because of the macros. its not specifically about how they're defining a function or calling them anonymously

while i cant say that i agree with atom reference, (its 1 char in elixir, two in erlang), you're definitely correct about that annoying idea they've had about dropping parenthesis on functions without parameters... that was just misguided i think.

Using an atom doesn’t require any extra characters in Erlang. Update: just realized you mean the single quotes when you need an arbitrary atom name. Understood.

I definitely wish Erlang had the same macro capability. I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.

> I just find the overall syntax sufficiently unpleasant that I can’t get into Elixir.

Please, don't use such an excuse for not trying out a language. :(

The unpleasantness you speak about is akin to motion/sea sickness - the signals your brain receives disagree with the brain's predictions of what they should be. The discrepancy manifests as a feeling of unease at the very least, or you may throw up non-stop for 3 days on the deep end, but, eventually, the sea sickness disappears completely.

I believe I experienced something very similar to this many times while learning many strange, exotic languages as a hobby. When the syntax or semantics were completely outside of what I already learned, I was irritated that "I don't even know how to ...something...". When the new language was close to what I already learned, I was irritated that "it doesn't work as it should" due to the differences. Basically, I experienced some kind of rejection reaction from my brain every time. But then, after a few days to a few weeks, that feeling faded and disappeared.

There's a technique I thought up and used a few times which helped me with especially hard, complex, or simply exotic syntaxes. I'm not sure if it will work for everyone, but it helped me with Lisp and Prolog when I first learned them. What I did was to print several tens of pages of (syntax-highlighted and preferably heavily commented) example code and scatter them around the house at spots I was likely to look at. Next to the mirror in the bathroom, on the fridge doors, on my desk, and so on. I wasn't trying to actively read that code very much, just glanced at it from time to time, and sometimes tried to read a bit more when I was bored. When I returned to actually learning the language the next weekend (I think), it went much easier than before. I still wasn't able to write in the language, obviously, but reading - even if I didn't really understand more of it than before - stopped being a hassle, the feelings of rejection disappeared, and I was able to learn quickly from that point on.

Well, that's just my theory based on personal experience, so it may be utterly stupid or just my imagination, so take it with a grain of salt. Still, I believe the feeling of unpleasantness from the syntax should be very easy to neutralize and as such it's not, IMHO, a good reason for "not getting into" a language which is otherwise interesting (whether Elixir is such for you is another matter).

As someone who already knows and loves Erlang, I’m already quite familiar with the advantages Elixir offers, other than macros.

I like Erlang’s syntax. I like the concision. I like the clear differentiation between variables and atoms that capitalization offers. Erlang’s syntax and underlying model are firmly entwined in my head.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact