…and how do you feel about it now?
This thread was inspired by some of the posts in this thread, and, as I am sure many of us have heard the Erlang syntax doesn’t always go down well with people at first 
but… and I’ve been hearing this more and more recently, people like it more the more they get accustomed to it.
So I am curious to hear your story - how did you feel about it at first and how do you feel about it now?
When I first saw the Erlang syntax I was overwhelmed by fear 
since the syntax was not like to any similar of other languages at all what I meet before. Nevertheless, this syntax eventually captivated me, in fact, one week is enough to learn the syntax and of course you need to practice a lot to get the necessary experience. Even though I haven’t worked that much with Elixir, I noticed one very convenient piece of syntax that is sorely lacking in Erlang is pipelines. It may also be missing some functionality for the list generator, etc. but this and other information is collected in EEP. At the moment, I would say that the syntax suits me completely 
.
The only thing I disliked about Erlang was its variables starting with an uppercase letter. But as Mark Anthony said “Erlang is worth whatever chaos it brings to the table, and you know it”. 
Before I even saw a bit of Erlang code, I heard things like “Erlang has a weird syntax nobody really grasps”, so I started with learning Elixir.
After a while I gave Erlang a go and was surprised: Even if it has a unique style, which seem to confuse people on the first look, I found it to be clear and simple after some RTFM 
As @vkatsuba mentioned I did miss Elixirs piping operator too at the beginning, but I’m ok without now
Never been a concern. Why would it be? It’s just something to learn. Learning is our job. Big smelling whoop.
There’s minor annoyances in the language, like every language, but nothing to be particularly concerned about. And the language has very nicely improved ever since the R12/R13 days so the remaining pain points are few and far between.
Because I never heard of Prolog before, It is quite different from the first time when I saw the Erlang code in the book Programming Erlang(first edition) and some videos in early 2013.
The main difference is the feel of the symbolic. Actually, I don’t know the concept of ‘symbolic’ before I watch Erlang The Movie.
After I tried more programming languages(like APL family, Forth, Prolog, OCaml), now I think the syntax of Erlang is not unique as the first time I saw it, but it is still nice though I think it can add some useful features.
The part I dislike the most of Erlang syntax is I have to use bitstring like <<"アーラン">> to avoid some Unicode issues, while Elixir can just use double-quotes to represent bitstring directly. I know this is not a big problem to write Erlang code but a big change with Erlang syntax, I still hope there is a more convenient way because it is quite annoying.
Another syntax problem, the record syntax, is not actually a syntax problem. Even OTP17 introduced map structure, the abstract ability of business logic of Erlang is still weaker than other dynamic class-based OO languages(like TypeScript or Python3.9+). Elixir has macro and ‘protocol’, and I think that’s why more people turn to other BEAM languages because nowadays more and more people need to write complex business logic(not deal with protocol layer or telecom related things).
In addition, I also hope Erlang can add some pragmatic syntax such as F#/Elixir’s pipe operator. However, it seems that more people don’t want to change Erlang syntax or treat it as the next dead language like C.
btw, I agree the Erlang syntax was a strange monster to the newcomer in the past because the mainstream language didn’t have enough essential FP features like pattern matching at that time.
But now everything has changed, the weight, the historical burden of BEAM and the old state ecosystem(included a fragmented and low-power community) are both the biggest problem when people consider whether join the Erlang world.
Maybe I should stop continuing this way I talk about all my views of Erlang’s future. In the worst case I thought, the BEAM will not die in 20 years, and the communities will be bigger than some other old languages such as XXXX at least.
I can’t imagine the best case, because it’s a little late to think that. Anyway, I wouldn’t stop using Erlang/OTP, even now I only use it for some toy or personal project.
The syntax is just unfamiliar, and change scares folks.
But the unfamiliarity was vastly overshadowed by the concurrency model (seriously, this blew my mind in 2009, coming from years of PHP and Perl), and frankly, I find the syntax to be a treat after all these years.
While I agree records are a bit clunky for data structures, I find records to be the perfect fit for the Nitrogen model of representing HTML or more complex HTML-like objects.
Could you tell more about this? How does macro/protocol in elixir help with business logic?
There was a parsetransform (think the erlang form of macro’s, but harder to build,lol) that supported pipelines, wasn’t bad, but still not something I’d use in production, lol. I’d definitely be for erlang adding a pipeline operator though, perhaps just |> and <| both to append (since erlang defaults to the end argument being the operational data in most cases) for |> and the <| is to take the right data as a chunk to pass into the latest argument (binding tighter than |> as is traditional in ML languages).
Yeah I know where that comes from but it’s still one of the bigger things I’m not a fan of, though it’s so minor so as to be barely mentionable, lol.
Overall though I still love the erlang syntax, over 20 years later, it’s nice and succinct and simple, no surprises.
It’s just simple lisp’y style code generation, so you can do things like build entire optimized http server middleware with but a couple of commands or generate a whole typed module from a simple definition all at compile time including compile time checks and whatever else you want. It’s pretty powerful, and it is absolutely possible for someone to build something similar in Erlang (like via a parse transform or so), just hasn’t been done yet.
I had not a single problem with Erlang syntax.
Maybe because I was very thrilled about learning Erlang so I came with an open mind from day one.
I even think it’s easier than most programming languages out there, and although I’m using and studying more Elixir than Erlang now, I still prefer Erlang syntax over Ruby/Elixir.
The only thing I miss in Erlang, is the pipeline operator like most people mentioned.
I also don’t like too much “magic” and Elixir does have a lot of syntactic sugar that gives me a hard time understanding what is going on sometimes. 
But I understand that’s as a personal limitation as it’s not normal to hear complaints about syntactic sugar I guess.
I just like that Erlang is simple and consistent.
I think I explained it here while explaining Erlang’s biggest strengths.
Erlang was love at third or fourth sight for me. As it was for most my peers. But it didnt have to be. I just had to see it through the BEAMs eyes and it’d make sense.
In summary of my first (ever) impression -
What I liked about Erlang:
! for message passing.Difficulties I faced:
, ;
X1 X2 etc aka no re-bindingI felt like programming languages should be more like human languages since I first tried FORTRAN in school, and I always wondered what’s wrong with the native punctuation, like commas, semicolons, and periods. So when I first saw Erlang, it was that “Wow, finally!” and everything else seemed as natural as I wanted it to be.
I really like the syntax because I think it maps well to expressing myself with function heads etc.
Something that isn’t a fault of the language but that I mess up often due to muscle memory are things like Boolean expressions and strict equality.
I think a pipeline operator would be nice, but I do tend to use multiple assignments to provide explicit names for pipeline steps; kind of like embedded, compiled documentation. The operator would be wonderful for simpler pipelines though.
I’m very new to Erlang and I’m still getting used to the syntax, although the more I learn it, the more I like it, with a few exceptions. As someone else mentioned, I’m starting to find it easier to write than to read. Reading someone else’s Erlang code is almost–but not quite–as bad as reading someone else’s Perl code. And I still haven’t figured out records. They make sense until I start trying to use them or read someone else’s code that uses them. Honestly, I just need to work with them more. They’re still very, very new to me.
On a tangential note, I was writing some Python today after days of doing nothing but Erlang. It’s funny how many times I ended a line with a period, and it felt very strange not ending a line in a function with a comma or semicolon.
Syntax is fine.
Naming conventions, or rather, the lazy semblance thereof, on the other hand…
Do you mean how like a significant number of erlang libraries are named erl*?
As someone who learned Elixir first, I find that the simplicity and consistency of the syntax is a breath of fresh air.
Things I like:
Things that could be added:
As a bit of a tangential anecdote, I bought 3 really nice knives for our kitchen last week over my wife’s raised eyebrow objections.
Today after using them for a week for chopping vegetables and somesuch she came to me and said: you know, I really like these knives, it feels like driving a high-end German car. Firm, but it gives you confidence that you’re in control.
So when I saw this thread, I thought, that’s what Erlang is like for me: it’s a takes a little more effort, but it inspires confidence and just “feels right”.
Nah dude.
I mean remembering that some functions are abbreviated, like sets:del_element, while others are spelt out in full, like gb_trees:delete_any, while some aren’t as intuitive, like qlc:q, unlike qlc:string_handle which is a string focus of q. Need to use List BIFs? Remember that everything there doesn’t have words separated with a _. Using ets? All of those *_to_* BIFs are instead *2*.
It doesn’t really help having both a cmp and read_encoding_from_binary in the same frame of workspace. And this is just for the stdlib.
Obviously, for the well-seasoned Erlang steaks this issue sorta goes away with time. For the curious and uninitiated though this is a headache. Especially when NIFs are included in the mix.
You just couldn’t let me get away with that drive-by comment, could you 
Most of it goes away with time. But I’ll admit I still consistently type set_element/3 instead of setelement/3. Probably because I almost never use it, so the weird naming that differs from its siblings delete_element/3 and insert_element/3 never sticks.
But something I do use often, and that will never, ever ever, ever, be possible for me without having the documentation open on one screen, is remembering what almost any of the functions in dbg do, or how the very similar ones differ. Does c mean clear in this function? Or is it call? It’s quite telling that every function’s documentation starts off by explaining what the name of the function actually means, before explaining what it does.
Apart from that I love the syntax. Worked with it for a long time before I even heard that it was controversial, and I cannot understand why it is. It’s not wordy or boilerplate:y, and like most languages’ syntax, it only takes an hour or two to learn. I think Erlang’s syntax does exactly what it tries to do, and quite well too. The one thing I wish for is a more concise way to write simple one-line lambda functions like IsUnderscore = fun(X) -> X == $_ end.
Most of the very old modules go back to a time when consistency was low on the list of priorities. Understandable I think, since Erlang itself was created more around a specific use case than as a language for the general public.
Aside from the naming inconsistencies, there are inconsistencies in argument order. For example, In most modules, the data you’re applying a function to is the last argument (eg, in all lists functions, the list you’re working on is last). In ets however, the table you’re working on is always the first argument. Well, except ets:foldl/3 and ets:foldr/3, where it is last, like in every fold function in every other module (that I have seen) that has one.
Also, sometimes things are mixed together in a module that should (IMO) really be in separate modules. For example, all functions in the lists module are concerned with lists of anything, making no assumptions about the type of elements, as the name lists suggests (to me). Except the key* family of functions, which assume and work with lists of tuples.
All that said, there is much more focus on consistency today. But the old inconsistencies cannot be removed without breaking basically everything in existence.