Hacker News Reader

Comment by josai | Hacker News Reader

> I think it does, actually

You may be right, but what I meant is that every rubyist i know looking into elixir is after massively persistent connections. Websocket, basically, to thousands or more clients. They are leaving ruby because it simply cannot offer that (I don't care what DHH says. No-one big is doing EM WS in production, nor should they).

Phoenix has a steeper learning curve than rails but is addressing the new paradigm of persistent duplex connections. Rails remains unapologetically a request-based framework, ActionCable notwithstanding. That is fine. 99% of today's apps don't that. Right tool for the job! But to me, the future is very clear.

I'm heavy into ruby too, but speaking pragmatically, it and elixir are playing different games in different ballparks. That's why I said they don't compete.

View on HN

There are many, many other selling points to Elixir/Erlang over Ruby, if you already like Ruby (and its syntax, some of its conventions, etc.)

1) Immutable data throughout- prevents certain classes of bugs

2) 10x faster- obvious benefit

3) Actual macros- the ultimate metaprogramming: http://elixir-lang.org/getting-started/meta/macros.html

4) Functional paradigm- encourages decoupling of code by forcing state to be passed around explicitly as arguments, this also aids unit testing, it also reduces bugs further

5) Instant "forking" without having to worry about thread safety, and good semantics around it

6) Potential 99.999999999% uptime reliability (thanks to Erlang's OTP)

7) Hot-swappable code upgrades with no downtime

8) Pattern-matching reduces the amount of "switch logic" code greatly. In Ruby code I often saw complex logic branches with no test coverage- it's easier to cover those in Elixir when every "branch" is a different pattern-matched function

9) A bunch of neato things such as build-your-own-sigils, which felt even more "Ruby-like" than Ruby's own capability (or lack thereof) here: http://elixir-lang.org/getting-started/sigils.html

10) Trendy Actor model built-in from the get-go ;)

> A bunch of neato things such as build-your-own-sigils, which felt even more "Ruby-like" than Ruby's own capability

I like custom sigils, those are pretty cool, e.g. def sigil_i(string, []), do: String.to_integer(string)

But, having to put that char into the method name rather than argument, doesn't that limit the characters that you can use? Seems like would be better as arg.

I agree with that... Perhaps it's limited that way on purpose?

> 2) 10x faster- obvious benefit

Given Erlang is sometimes slower than Python [1] I am surprised if it's 10x speed improvement over Ruby.

1: https://news.ycombinator.com/item?id=9417453 (start at last comment & work up)

It depends on what you're doing.

I believe for the sort of thing typically done in these sort of languages (which usually boil down to doing lots of string processing) Elixir may well be 10x faster.

The reason?

Lack of dynamism.

Function calls in python/ruby? SLOOOOOW

Function calls in Elixir? Hella fast, because it's all resolved at compile time, there's no dynamic lookup, no creating a locals dictionary for each call, etc.

(PS: Most typical web frameworks make a LOT of function calls - all that data sanitizing, templating, and formatting has to happen somewhere)

It's true that Elixir is slower if doing numerics heavy code since it can't just call out to a highly tweaked numeric library like NumPy.

(This is all talking single threaded, of course. With a parrallizeable task you won't even be in the same zip code.)

Erlang and Elixir are both dynamically typed and do dynamic dispatch.

Erlang does not know the types flowing through a call site in advance and therefore has to do dynamic dispatch.

In particular, Erlang has a "code server" that all calls throughout the system must thunk through, versus a statically typed language where a call is optimized to a single JMP instruction. Smarter JITs, like Java's HotSpot, can also do this, and HotSpot is smart enough to inline both virtual and dynamic dispatch at runtime. BEAM can't.

Erlang's closest thing to a JIT (HiPE) cannot inline calls across modules, has no support for deoptimization, and is in effect a naive, crappy, AOT compiler which does the bare minimum to work in an otherwise dynamic environment.

Source: I made this... it was basically Elixir before Elixir:

http://reia-lang.org/

These days I like languages that can actually avoid this overhead through the use of static typing, like Rust.

Note that it isn't necessarily bad that Erlang works this way. When it comes to Erlang's core strength: coordinating the concurrent activities of a massive number of processes/clients, it really does shine. Just don't use it for anything CPU-intensive.

6) Potential 99.999999999% uptime reliability (thanks to Erlang's OTP)

I don't have much understanding of programming language internals but why we don't thing see low level stuff like distributed file system written in Erlang.

I genuinely interested in knowing why this is not tried by someone?

Every phone call you've made in the last 10 years+ probably touched an erlang node at some point. That's pretty distributed.

If your're looking for more traditional server stuff, there's RabbitMQ.

Actually quite a few systems have been! Besdies telco stuff, Facebook used it quite a bit and I'm told it was in LinkedIn's stack as well.

I get a lot of recruiting interest from my time at Powerset as an erlang engineer, from the most surprising places. Game companies come up a lot.

> 10x faster- obvious benefit

Please put down the kool aid. If you can't back statements like this up, you're not helping anyone.

I would swear I saw this somewhere, but in the meantime, this shows up to 6x

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Also this real-world example:

http://www.bigdatalittlegeek.com/blog/2014/7/10/ruby-vs-elix...

Add one to the column of people who are into Elixir for reasons that have nothing to do with websockets.

> No-one big is doing EM WS in production

Are you kidding me? Look at Pusher, which is literally EM sitting behind Route 53

Pusher? Aren't they moving all of their code to Haskell?

It will be a long time before we're rid of EventMachine. It's served (relatively) well considering, but I wouldn't say any of us are fans or would recommend it for new projects.

Reply on news.ycombinator.com