[inferiorhuman]

Deployments are a mess and as it is interpreted, performance is closer to Ruby than Go. I found the community to be pretty disappointing (but YMMV obviously) — it seemed more alternative oriented than the Rust community (which seems more solutions oriented).

[wolf4earth]

Performance is definitely not close to Ruby, this is just blatantly incorrect. Elixir and Erlang can easily hold their ground vs Go.

The BEAM was originally designed to run software for telephone switches. It's often referred to as soft realtime because it is so responsive. It has been battle-tested for now over 3 decades.

Where the BEAM falls flat is pure number crunching but it's blazing fast with binary processing (e.g. string parsing).

A fresh phoenix project where you render a nontrivial template easily reaches sub millisecond response times, without any kind of optimization.

[mtarnovan]

For CPU intensive tasks, performance _is_ close to Ruby, while both Ruby and Elixir are far behind Go. Soft realtime doesn't mean fast, it just means good std deviation on response time and not a lot of missed deadlines. Fortunately as the article points out, there's always Rustler if you need to optimize while still keeping BEAM crash proof.

That being said, I agree that performance for certain IO intensive applications like web servers is very good, way better than Ruby. Subjectively Phoenix feels way, way faster than Rails in development and is much more performant in production.

[enraged_camel]

>>For CPU intensive tasks, performance _is_ close to Ruby, while both Ruby and Elixir are far behind Go.

Yeah, but how many companies do you know of that perform heavy computations in such large scale that their choice of programming language has a noticeable effect on the result?

I mean, it might matter for tech giants like Google, who need to squeeze every bit of processing power out of their CPUs. For almost everyone else, it will be a non-issue.

[mtarnovan]

It's just that when you say "performance on par with Go", people might imagine you could write a 3D engine in Elixir, which obviously isn't the case.

[inferiorhuman]

A fresh phoenix project where you render a nontrivial template easily reaches sub millisecond response times, without any kind of optimization.

Going from Phoenix to Rocket.rs I saw a pretty dramatic speedup on even simple pages. Phoenix was faster than the Rails version of the app, but still slower than a compiled language.

[Existenceblinks]

It's not a mess. Mostly It was just unclear mixed of runtime and compile time configuration that contribute the inconvenience. Elixir 1.9 just comes up with a simple built-in release mechanism with more clear on how you put configuration.

[inferiorhuman]

It's not a mess. Mostly It was just unclear mixed of runtime and compile time configuration that contribute the inconvenience. Elixir 1.9 just comes up with a simple built-in release mechanism with more clear on how you put configuration.

From the sound of it things have gotten better (by throwing out oft-touted features), but Elixir deployments are inherently far too complicated. With Go and Rust you get a single binary and a single program to run. With Java (and other languages targeting the JVM) you get a single jar archive. With Elixir you get to bundle the whole runtime and spawn a few separate supervisor processes to run even a hello world app. Lord help you if the only maintainer for the deployment tooling takes an unannounced vacation or if the various BEAM processes stop talking to each other because the stars are misaligned (and the deployment tools are minimally tested) and you can't even run an Elixir based database migration as a result.

When I started toying around with Elixir and Phoenix I'd just come off of a Clojure kick. You can get most, if not all, of the syntactical sugar that Elixir promises with other languages that all offer infinitely simpler deployments with more mature tooling. In the case of Clojure you get whatever JVM tooling you'd like.

[foobarbecue]

Sounds compilicated.

[TylerE]

Aren't most things that actual survive encounters with the real world?

Make it as simple as possible, but no simpler.

[foobarbecue]

It was a pun.

[owens99]

For web development the performance is within a breath of Go and a kilometer ahead of Ruby on Rails.

[erokar]

Elixir is compiled, not interpreted.

[inferiorhuman]

Compiled into bytecode to be interpreted by the Erlang (BEAM) VM.

[erokar]

Are we doing semantics now? Java is also compiled into bytecode, executed by the JVM. Do you consider Java an interpreted language also?

[ralusek]

I think most people consider Java to be an interpreted language, it's interpreted by JVM. It's obviously somewhere in between, in the same way that JIT languages are, but it's still not native.

[didibus]

Not sure about the BEAM, but Java isn't considered an interpreted language at all.

First, discerning the compilation step to IR is relevant, which is why for example, Python can be compiled or interpreted. That distinction matters. Even though it is compiled to intermediate representation, it is still compiled.

Now, with regards to the intermediate representation, Java Byte Code is also not interpreted. Java Byte Code is compiled to native machine code either Just in Time by the JVM, or Ahead of Time by the SubstrateVM. Both of these make it a compiled language.

An interpreted language never gets translated into native machine code, it gets executed by a native interpreter, and that's very different. It is more akin to using a language where you read and parse texts, and based on the text, you might execute one or more things. Now if that parsing to execution branching is powerful enough to allow Turing complete behavior, you have yourself a full blown interpreted computer language. This is not what happens in the JVM. The JVM translates Java Byte Code to native machine code Just in Time, and then the native code is run.

[james-mcelwain]

We should be more precise: the JVM may or may not have an interpreter. This is implementation dependent. There are JVMs that are interpreted fully and AOT compilers as well.

Hotspot includes an interpreter -- your code may be interpreted until it gets hot and gets compiled.

Still, I don't think it's fair to call Java an interpreted language since the parts that are interpreted are only during warm up or slow enough not to matter.

[true_religion]

Java is an interpreted language because you always need a JVM to run it. I even if you distribute the runtime with your code as one package, that’s just an artificial distinction.

Regardless, interpreted does not mean bad, or poor performance for your task.

It’s a technical notion.

Most people would say Python is interpreted, even if you are only running compile python bytecode on a JIT like PyPy. That’s exactly the same situation as Java.

[datashaman]

It can be both. .ex files are compiled, .exs files are interpreted.