Comparing Elixir and Go

Basically:

- Code either "C code compiled with C++ compiler" or C++ OOP Spaghetti like in the CORBA/DCOM days before JEE was a thing.

- functions/methods that span several screens

- barely any kind of testing

- due to emphasis on C style programming, lots of fun tracking down pointer misuses

- re-implementation of code that is already part of C++ standard library, even the ones from C

- lots of copy-paste on the same file because devs don't understand neither source control nor modularity

If I were putting together a new awesome Thing(TM), I think I would probably use elixir on the front end and internal messaging to handle and distribute jobs, and let go do the crunching and hard lifting.

Maybe already fixed, but here are a couple things I noticed:

Go methods have to be defined in the same package as their receiver's type. As a result, you can only add methods to your own types, not someone else's.

Also, the article claims that Go interfaces are similar to Elixir's pattern matching but I don't see a resemblance. Perhaps clarify that?

This is more for people looking at erlang/elixir than a critique of the blogpost or a suggestion for a change.

> Within Elixir, there is no operator overloading, which can seem confusing at first if you want to use a + to concatenate two strings. In Elixir you would use instead.

When this popped up, it reminded me of something people try to do often and then have issues with performance. You probably do not want to concatenate strings.

"Yes I do" you'll first think, but actually erlang has a neat commonly used thing to help here.

Let's say you're doing some templating on a web-page. You want to return "Welcome back username!". First pass (a while since I wrote erlang so forgive syntax errors):

    welcome(Username) -> 
        "Welcome back " ++ Username ++ "!"

Now it's going to have to construct each string, then create a new string with all three. More creation & copying means things get slower.

Instead, many of the functions you'd use to write files or return things over a connection will let you pass in a list of strings instead.

    welcome(Username) -> 
        ["Welcome back ", Username, "!"]

Now it's not copying things, which is good. But then we want to put the welcome message into another block with their unread messages.

    full_greeting(Username) ->
        welcome(Username) ++ unread_messages()

More appending than is good here, concatenating lists is going to take time. Of course, we could put it all in one function, but then we lose re-usability in the templates and have horrible massive functions. While this is a simple example, I hope you can picture a larger case where you'd want to split up the various sections.

Anyway, there's a better way of doing this. The functions that take lists of strings actually take lists of strings or other lists. So we can just do this:

    full_greeting(Username) ->
        [welcome(Username), unread_messages()]

You can keep going, nesting this as much as you want. This saves a lot of copying, allows you to split things up and avoids having to keep flattening a structure.

So, for people about to get started, try not to concatenate your strings, you can probably save yourself and your computer some time.

For more info on this, you want to search for "IO Lists" or "Deep IO Lists".