Hacker News Reader

Comment by lectrick | Hacker News Reader

I've been doing programming for a while now (mostly in Ruby of late, but prior to that, lots of stuff) and the more I play with Elixir, the more I want to work in it. I'm actually going to ElixirConf (which is next weekend in Austin).

They seem to have done a lot of things right, and addressed pretty much every single criticism I had of Ruby.

> I'm very seriously considering Elixir/Phoenix for my next startup

It will be a risk, but I say go for it. Others (who have probably NOT had any Elixir experience!!) will tell you your startup is already enough risk, but here's the thing- Elixir could end up being the key differentiator technology for you. Who else provides NO DOWNTIME code upgrades, and that incredible request responsiveness as well as reliability? Immutable data? Extreme concurrency? The "Actor model" that everyone is enamored with these days? The awesome community? Nobody, I think.

View on HN

> They seem to have done a lot of things right''

This is because Elixir is "just" a different syntax for Erlang/OTP which is used in very mission critical software in real world (it was originally created for telephone systems)

To be fair, it is not just a different syntax. It can do a few things a bit better:

* Streams

* Actual macros

* Mutable variables (not data, of course)

Those would be kind of a pain to do in Erlang, maybe with parse transforms.

I personally prefer Erlang better. I like its syntax and immutable variables. Haven't hit a need to need macros too badly yet.

Where does Elixir allow mutable variables? AFAIK, it does not. Syntactically it might look like it allows mutable variables, but it actually does not.

> Where does Elixir allow mutable variables?

Everywhere pretty much. Learn a bit more how it works. Here is a good resource:

http://elixir-lang.org/getting-started/introduction.html

Here is an example:

   iex(1)> x=1
   1

   iex(2)> x=2
   2

x was 1, then it was 2. It mutated.

To compare here is Erlang:

   1> X=1.
   1 
   
   2> X=2.
   ** exception error: no match of right hand side value 2

Just like in math, once X=1, it stays that. It doesn't get to mutate.

The variable isn't mutated, actually — it's rebound. See http://natescottwest.com/elixir-for-rubyists-part-2/, for example.

Yes it is. x is the variable. It changed from 1 to 2. Mutation is a synonym for change. Try it yourself in the interpreter! So data is immutable, but variables are mutable in Elixir.

But if you passed that first x to a process, it would still be 1 even after you ran `x = 2`.

Dude that's not a mutation that's a rebinding. You do not understand the difference, and it is an important one.

Again, Elixir does not create mutation where in Erlang there was none. There is no mutation.

They decided to allow rebinding so that you wouldn't end up with a whole bunch of stupid temporary variables, which is exactly what you have to do in Erlang.

That is a variable mutation. Mutation is a change in value. x was 1 then it was 2. If that is not mutation, I don't know what is.

You are probably trying to say that Elixir and Erlang have immutable data. But that's what that's called "immutable data". Precisely because the variables can be mutated or not separately from the data.

> a whole bunch of stupid temporary variables, which is exactly what you have to do in Erlang.

Well we should tell Joe that it's stupid. Maybe he'll change his mind.

If variables don't mutate, all it means is that the memory location that stores the value of that variable is guaranteed to never change. Thus, if you reassign that same-named variable, it actually points to a new memory location with the new value. That is what "rebinding" is vs. "mutating." The advantage of this is concurrency, etc. etc. The disadvantage is you have to have good GC since you'll be doing a lot more garbage collection. It may LOOK like it's changing a variable, but it's not- the variable merely points to a new memory location.

Other languages, like Ruby, do not work this way. If you reassign an instance variable, the memory that is storing that value actually does change.

Here, compare the same sequence of operations in Ruby and Elixir, first Ruby:

    bash>> irb
    >> a = {a: 5}
    => {:a=>5}
    >> b = a
    => {:a=>5}
    >> a[:a] = 10
    => 10
    >> b
    => {:a=>10}

and now Elixir:

    bash>> iex
    Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

    Interactive Elixir (1.1.0) - press Ctrl+C to exit (type h() ENTER for help)
    iex(1)> a = %{a: 5}
    %{a: 5}
    iex(2)> b = a
    %{a: 5}
    iex(3)> a = %{a | a: 10} # updates a mapping
    %{a: 10}
    iex(4)> b
    %{a: 5}

Notice how b's value changed in Ruby, but not in Elixir. In both cases, the hash was updated.

> If variables don't mutate

I think we are talking about two different things when we say "variables". When I say "variable" I mean x, y, a, b etc. That is the variable. It has a value, you can see it in the shell (repl) or when printing it. Look at what happens to variable x:

   iex(1)> x=1
   1

   iex(2)> x=2
   2

It was 1 then 2. It changed. Mutation is a synonym for "change". I think it is a pretty simple concept. Did the framework create a new memory cell, put a 2 in there and now x behind the scene dereferences that. Did it update the old cell in place. Was it on the stack? That's not the point. The point is x now has a new value. x is a variable that means variable x mutated.

Compare to Erlang:

   1> X=1.
   1 
   
   2> X=2.
   ** exception error: no match of right hand side value 2

You can't mutate variable X. variable X is immutable. Again, I think that is pretty clear and simple.

What you showed in your example is how data is immutable in Elixir but not in Ruby.

> The advantage of this is concurrency, etc. etc.

Actually most data, except larger binaries, are copied between processes anyway. So concurrency advantage is mostly theoretical. In the future they could be switched to reference counting for other things. But that is a hidden implementation detail anyway.

Are you Löic Hoguin?

> NO DOWNTIME code upgrades

This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure).

Also, NO DOWNTIME in the context of services is kind of hard to qualify: I have no downtime for say, a web service, when doing a load-balancer deploy shuffle.

> incredible request responsiveness as well as reliability

"Request responsiveness" to some degree depends on language- a language is sometimes your upper-bound on performance.

Much more often, however, do I find that this is a function of application design. And yes, language design and application design heavily play into each other, but there are many, many languages that can achieve the same responsiveness/reliability concerns.

Haskell, many JVM-hosted languages are good choices.

> Immutable data

Almost every modern functional language. Many even do it (immutable data structures) better than Erlang/Elixir. Some even have interesting (state of the art) concurrency features that perform better in different situations - see Haskell STM (I wouldn't try and compare to Mnesia).

> Extreme concurrency

Haskell, Go, anything on the JVM, the CLR is catching up.

> Actor model

This is a bit of a subjective and semantic thing - many languages have green threads (though not all would necessarily fit the bill of "actor model" in out-of-the-box implementation, and not all are truly preemptive (most aren't)) - Haskell, Go are two good out-of-the-box implementations.

I know Haskell has an Erlang Actor analogue, not sure if Go does yet.

> The awesome community

I hesitate to use the word "niche language" - but most "niche languages" have great communities (albeit small ones) - possibly out of necessity.

I don't find that this scales often

(What would you call the "Java community?", where would you find it?, where are the pockets of "good?")

This is 100% subjective, but, I feel like Ruby has one of the best, largest communities. Some of that has bled into Elixir, for sure, to be fair.

---

All in all, Elixir is a great language, but I hesitate to recommend it without knowing more about GP's requirements and business.

(What if the GP needs to do very memory and CPU-intensive number crunching?)

> This doesn't need to be a language feature, but this is possible on the JVM afaik (see Clojure).

You don't need Clojure; Hot Code Replacement was added in Java 1.4 (yes, that's 2002) and has been supported by application containers as well as IDEs since then.

Good call - I am not as familiar with JVM-hosted languages, though I knew Clojure was capable of hot code replacement (as any lisp should be!)

This is definitely not a new idea.

Isn't Java's HCR very limited? You can't introduce incompatible classes, for example.

I've heard that putting together Erlang/Elixir releases isn't trivial; how would that compare?

Never done it. But I don't think anyone claims you get hot code replacement for free. You have to plan and design your app to support it. That said, it's actually intended for downtime-less upgrades, whereas Java's HCR seems intended for debugging and development.

Ah, that's a pretty significant distinction.

You can nitpick like this about just about anything — "Erlang has immutable data? Yes, but so does Haskell etc.".

That's missing the point that Erlang/OTP (and therefore also Elixir) is attractive because it's already a complete package. It's the intersection of a lot of different, neat technologies that becomes magical.

Try to accomplish the same things in Haskell or Clojure or Go and you'll find that you simply don't have the same tools available to you, and often they cannot be built as well as in Erlang because the foundation wasn't designed for it. And there's always some piece missing.

For example, you can build an approximation of supervisor trees in Go, but since goroutines cannot be killed, you're at the mercy of the runtime. (I also wonder if goroutines scale as well as Erlang's.) Similarly, no one has actually built a functional, immutable, process-oriented call-by-name-and-signature RPC mechanism for Go, so you'll have to invent your own. And so forth.

As a specific example, I was recently investigating OCaml to see if someone had implemented something similar to OTP. I found a couple of promising, nascent projects, but their activity all ended around 2009. Apparently nobody is doing it, even though the language seems damn near perfect for it. Never mind distributed processes; LWT is pretty weak even as an approximation of Go's goroutines.

> [downtime] This doesn't need to be a language feature ...

Erlang's live code replacement changes how you mentally think about versioning, I think. Instead of designing every piece of your infrastructure to transparently transition to a new version — using load balancers, multiple processes accept()ing on the same port, and so forth — you get a first-class language construct. This also opens possibilities beyond code deploys, such as temporarily injecting tracing into a running program. Also not often mentioned is how powerful it is to be able to connect to a running process and run the REPL inside it. (Ruby comes close here, but it's never been something you get for free.)

Reply on news.ycombinator.com