5 ms·

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) —

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).

erokar 7y ago
Elixir is compiled, not interpreted.
- inferiorhuman 7y ago
  Compiled into bytecode to be interpreted by the Erlang (BEAM) VM.
  - erokar 7y ago
    Are we doing semantics now? Java is also compiled into bytecode, executed by the JVM. Do you consider Java an interpreted language also?
    - ralusek 7y ago
      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 7y ago
        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.
        true_religion 7y ago
        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.
        TylerE 7y ago
        There is nothing about Java that requires a VM. That is just how Sun decided to implement it. GCJ, for instance, allows AOT compilation of a Java program that requires no JVM.
        didibus 7y ago
        Java is compiled to Java byte code. It cannot be interpreted in its source form. There's nothing preventing it to be, but as far as I know, there are no interpreters for it. Python on the other hand can be interpreted from source, and that's the default behavior, making Python an interpreted language. This makes Java a compiled language, even though it is compiled to machine code for a machine that doesn't exist. Java Byte Code is an assembly language, and in fact, Sun had at one point machines that were natively using Java Byte Code instruction sets. Now Java Byte Code is trickier. You could consider it to be interpreted or compiled or both. It is fair to say that in general it is interpreted, but it is just as fair to say it is in general compiled. What matters most though is to understand that modern JVMs make use of a JIT compiler and optional AOT compilers. In the latter mode, you can compile Java Byte Code to native machine executables ahead of time or pre-runtime and no JVM beyond that point is required. So you can distribute the app as a self-contained executable. In most cases though, this will be less performant in the average and peak performance, but it will speed up the worst case, such as start time. In the former mode, the JVM will analyze runtime behavior and based on the frequency of use of various code paths, it will either compile the code to native machine code (cache the compiled code), and then run the freshly compiled code block, or it will choose to interpret the byte code directly. This allows aggressive optimization from information which is only available or easily available at runtime when performing compilation.
      - deleted 7y ago
        [deleted]
    - deleted 7y ago
      [deleted]
- datashaman 7y ago
  It can be both. .ex files are compiled, .exs files are interpreted.
Existenceblinks 7y ago
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.
- foobarbecue 7y ago
  Sounds compilicated.
  - TylerE 7y ago
    Aren't most things that actual survive encounters with the real world? Make it as simple as possible, but no simpler.
    - foobarbecue 7y ago
      It was a pun.
- inferiorhuman 7y ago
  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.
wolf4earth 7y ago
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 7y ago
  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 7y ago
    >>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 7y ago
      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.
- 7y ago
owens99 7y ago
For web development the performance is within a breath of Go and a kilometer ahead of Ruby on Rails.

erokar 7y ago

Elixir is compiled, not interpreted.

inferiorhuman 7y ago
Compiled into bytecode to be interpreted by the Erlang (BEAM) VM.
- erokar 7y ago
  Are we doing semantics now? Java is also compiled into bytecode, executed by the JVM. Do you consider Java an interpreted language also?
  - ralusek 7y ago
    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 7y ago
      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.
      - true_religion 7y ago
        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.
        TylerE 7y ago
        There is nothing about Java that requires a VM. That is just how Sun decided to implement it. GCJ, for instance, allows AOT compilation of a Java program that requires no JVM.
        didibus 7y ago
        Java is compiled to Java byte code. It cannot be interpreted in its source form. There's nothing preventing it to be, but as far as I know, there are no interpreters for it. Python on the other hand can be interpreted from source, and that's the default behavior, making Python an interpreted language. This makes Java a compiled language, even though it is compiled to machine code for a machine that doesn't exist. Java Byte Code is an assembly language, and in fact, Sun had at one point machines that were natively using Java Byte Code instruction sets. Now Java Byte Code is trickier. You could consider it to be interpreted or compiled or both. It is fair to say that in general it is interpreted, but it is just as fair to say it is in general compiled. What matters most though is to understand that modern JVMs make use of a JIT compiler and optional AOT compilers. In the latter mode, you can compile Java Byte Code to native machine executables ahead of time or pre-runtime and no JVM beyond that point is required. So you can distribute the app as a self-contained executable. In most cases though, this will be less performant in the average and peak performance, but it will speed up the worst case, such as start time. In the former mode, the JVM will analyze runtime behavior and based on the frequency of use of various code paths, it will either compile the code to native machine code (cache the compiled code), and then run the freshly compiled code block, or it will choose to interpret the byte code directly. This allows aggressive optimization from information which is only available or easily available at runtime when performing compilation.
    - deleted 7y ago
      [deleted]
  - deleted 7y ago
    [deleted]
datashaman 7y ago
It can be both. .ex files are compiled, .exs files are interpreted.

Existenceblinks 7y ago

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.

foobarbecue 7y ago
Sounds compilicated.
- TylerE 7y ago
  Aren't most things that actual survive encounters with the real world? Make it as simple as possible, but no simpler.
  - foobarbecue 7y ago
    It was a pun.
inferiorhuman 7y ago
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.

wolf4earth 7y ago

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 7y ago
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 7y ago
  >>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 7y ago
    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.
7y ago

owens99 7y ago

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