thoughts while learning erlang

array/string ambiguity is uncomfortable

6> [1000, 500, 4].
7> [100, 50, 4].
8> [100, 50, 40].


Strings are enclosed in double quotes ("), but is not a data type in Erlang. Instead a string "hello" is shorthand for the list [$h,$e,$l,$l,$o], that is [104,101,108,108,111].

($y gives you the ordinal value of the letter y)

I guess that's kinda fun. I'm starting to get feelings about Erlang similar to C++ -- it's somewhat perverse, but in a way I can appreciate.

boilerplate stuff

filename foo.erl needs "-module(foo)" at the top of it, which is annoyingly redundant. although i wonder what happens when the two differ? could this be useful somehow? (nope, otherwise it will break code loading. well that's pointless)

The "-export" list which says which functions in a module get publicly exported, is redundant. I feel like I'm writing C header files again.

(that's hyperbole, somewhat)

function name overloading

Looking for the same function name but with a different number of arguments seems a little annoying. It would be a little more obvious to just give them different names. This may just be a deficiency in the coding style of the tutorial I am reading.

arbitrary base integers

not really very useful for me, but i always thought it was a cool idea when i heard of it in smalltalk (i think). base#value where base is 2-36

(speaking of base 36... so that's what those dang reddit and youtube ids are!)

tail call recursion optimization

fun to have it; a refreshing change from python

% silently does nothing forever
foo() ->
# raises recursion limit error
def foo():

(or python will segfault if you increase the recursion limit)


Nick Welch <> · github · twitter