Will Amber Framework (Crystal) perform better than Phoenix?

I like Crystal, but I personally see it more as a tool for number crunching. I think I read that Soundcloud are one of its early adopters.

With regards to performance - what do you mean specifically? Phoenix pre-compiles/caches templates by default so on serving pages it is incredibly fast (micro seconds). Thanks to the BEAM, it also offers massive concurrency and parallelism along with fault tolerance (there’s no point being able to serve so many requests if your system fails because of a problem).

I heard Crystal folk say they want to implement something like the Actor model that Erlang has, but I’ve also heard @joeerl (I think in relation to Java stuff) say something along the lines of that sure, anyone can implement a similar model to Erlang - but then they’ll need 20 years to get to where Erlang is at. Erlang wasn’t just built and then stayed the same - it was worked on, tweaked, enhanced over a couple of decades to get it to where it’s at today :slight_smile:

There’s also another thing worth mentioning. I think for anything to be ‘better’ than Elixir and Phoenix, after having been inspired by it, is for those trying to better it to actually know more about it than on a superficial level… because the more you know about Elixir and Phoenix the more you realise what’s truly special about them :003: (and by that stage, they’ll probably want to stay with Elixir :lol:).


Great reply! Did you notice that Amber creators perceive Phoenix as a popular web framework? :slight_smile: It’s really heartwarming, especially for @chrismccord I guess :wink:


I think you mean microseconds, since RAM access is in the order of nanoseconds. :sweat_smile:


Haha thanks! I think it’s awesome (and inevitable :lol:) that new frameworks are going to be inspired by Phoenix …because Phoenix is so damn awesome :003:

On a quick look, I see they’ve borrowed pipelines and have ‘Crecto’ (their version of Ecto) :slight_smile: I wonder what other influences they have from Phoenix?

Haha I always get those two mixed up :blush:


It IS pure ruby with optional type annotations compiled to an actual binary, statically linked to its own runtime system and its dependencies.


I’ve had to bug fix a couple of crystal sources, wow that is hairy unreadable to me, no sense of code flow… It might have just been the author of those files but it really turned me off from learning crystal thus far… >.>


Phoenix is awesome! I agree that performance is not everything. I would have to disagree with the quote :point_up:

There are huge advantages that Crystal offers for those who embrace OOP, and not functional styles, I would say from my experience working with Crystal is that is almost a low level language with a high level API. Crystal was born out of an experiment to make Ruby faster, but soon the experiment took a different direction giving birth to the language.

Crystal is NOT Ruby it feels like and it looks like but it is nothing like Ruby; Type System, Null checks, Macros, Concurrency and the fact that is similar and feels like Ruby, makes Ruby developers feel at home, not afraid, and for people that complained about ruby not being fast, type checked, etc is the language that they have been waiting for. Crystal is faaster than Ruby with better memory management, and it sits almost on par with GO and yet there is no parallelism built in. It is true, Crystal not yet popular, not yet 100% complete but it is very promising.

Now Elixir, was beautifully design and developed, on top of the battled tested Erlang hard to compare to, almost not fair. Phoenix a framework to admire, beautiful docs, concepts and great community. Lets not forget that inspirations comes from everywhere. The same way Amber got some inspiration from Phoenix, the latter got from Rails (I guess this is how things evolves)

For those who care about speed I would consider the TechEmpower benchmarks of great importance since it has standardized bench-marking frameworks, consistently, with a thorough testing process, unbais to any language, with a rigorous PR review.

Let’s not judge for the cover of the book, when the true story lies within the pages.


Except for that the TechEmpower benchmarks have lots of issues including but not limited to:

  • Improperly made libraries
  • Testing libraries of different ‘levels’ in the same results
  • Not testing failure conditions
  • Among many others…

I agree we are running into some issues with that ourselves, where we expect the results to be 25%-30% closer to raw Crystal.

1 Like

Crystal is great and Amber looks nice Elias :023:

What kind of user is it targeted at and what kind of apps does it excel at?

Yes :smiley: I am a staunch critic of the TechEmpower benchmarks (as a way to compare frameworks. They are likely useful as a development tool for a particular framework to find some performance bottlenecks). I have given reasons why in other posts.

They should not be used to compare frameworks. They even state so themselves. Plus the way they conduct the benchmark only makes them useful if you want to know how fast a specific framework can theoretically be with the wind in the back on a slight downhill slope. I’ve tried some of the faster frameworks in a more realistic scenario and they actually behave quite poorly and the benchmarks led me down the wrong path to even explore them at all.



In regards to which kind of app it excels at? We are hoping that it can be use for any type of Apps really, since it supports cluster, concurrency soon to add an api generator and more. I mean you can even create a “sinatra” style kind of app. So if you want go with bare-bones see https://github.com/amberframework/online-docs/pull/36 you can or if you want something more robust you can as well.

1 Like

Crystal aims to be a much wider scope language (and most certainly NOT just for numbers crunching!) than elixir and I am rooting for them as I like what they are trying to achieve. I guess a certain amount of “my toys are and will always be shinier than yours” is natural but I have never found it helpful or rational with technology.

As great as Elixir and Erlang are Many highly concurrent based operations have been stable without it so there are always multiple tools for the job and ALWAYS a good thing when you have options. saying one optionwill always be the best is a strange thing for anyone who has watched technology For any amount of time to say. I already envy Crystal for their choices in web frameworks. Eliixir at this point seems married to Phoenix which I can live with but am not a huge fan of. Frankly I think If they get to 1.0 Crystal is likely to take off and bigger than Elixir.

Hi, everyone!

I contributed the Elixir code to that benchmark. I do not speak for the project, but I can comment a little about it. The Brainfuck 2.0 benchmark compares the performance of a naive BF interpreter that is structured in a certain way written in different programming languages. This is unlike what you see in, say, The Benchmarks Game where the participants end up with wildly different code in different languages. It ensures a certain kind of parity between the languages (no performance optimizations unrelated to the choice of language are allowed), but the structure fits some languages better than others. The result is that the Elixir implementation is slower than it could be. If you compiled BF programs to Elixir modules, which is what I would call an idiomatic solution, and applied a few simple optimizations, you’d end up with a considerably faster BF implementation. Source-to-source compilation gets you decent performance even on platforms slower than BEAM (see, e.g., my example in Tcl).

All that said, Crystal is faster than Elixir at single-threaded computational workloads. My own experience is that I tried doing image processing in both Crystal and Elixir (parse an uncompressed image file, apply a transformation to the pixels, save the result) and found Crystal to be about an order of magnitude faster at it. However, Crystal’s Fibers (green threads) are N:1 for now, so Elixir has the upper hand at parallelism.

Egads! I just looked into that, the code in a variety of languages is just horrible! Like the C++ code, like what on earth is going on with the Op structure in the BF2 listing, it is fat, like it’s going to take up dozens of bytes in the best case, each, in addition to a growing vector, plus there is no point to encode ‘yet another’ vector inside a vector when indices would work far better. In addition the C++ code takes up a lot more space per element because of the fat Op structure compared to most of the other languages, seemingly for no reason! And this is just a couple of the many C++ issues I see, and I’ve not even mentioned the other languages… o.O

1 Like

That’s precisely where I would like to use Crystal. I would use Elixir as the core of the app - because the app needs to do lots and lots of things at the same time - and languages like Crystal for specific things where they excel (such as image manipulation)… but only when actually needed.

I like the analogy where Elixir is the brains (of an app) and other languages can be organs. The brain ties everything together, communicating instructions, receiving messages, interpreting them and then passing on other commands, etc.

The great thing is you can do most things with Elixir/Erlang (with common libraries such as ImageMagick) and only drop into other languages for very specific things when you actually need to; the core of your app, or the overall system, is unlikely to change. It’s one of the reasons I love the Replaceable Component Architecture (and love Elixir for making it so easy).


I’ve written about Phoenix’s super-fast view rendering, but IMO the killer performance feature of any BEAM-based web application is cheap processes and pre-emptive multitasking.

I don’t know how Crystal handles concurrency, but if you’re running (say) Rails with 10 Unicorn processes and you get 10 expensive requests, all your processes are now busy. Any additional requests must get in line to be processed, and those users will see the site as having very high latency. If it takes 3 seconds before a request even gets to Rails, Rails may tell you that it handled that request in 200ms, but that’s only part of the story.

By contrast, every request to Cowboy gets its own BEAM process immediately, and because the BEAM uses preemptive multitasking (just like your operating system does), a process with a lot of work to do has very little effect on ones that don’t. I’ve explained how this works in a blog post, “Concurrency vs Parallelism and the Erlang Advantage”. Also, Saša Jurić’s talk “Solid Ground” has a very nice demo.

I would use Elixir as the core of the app - because the app needs to do lots and lots of things at the same time - and languages like Crystal for specific things where they excel (such as image manipulation)… but only when actually needed.

This seems like a great strategy: the BEAM in charge at the top level, delegating to languages with more raw speed for specific tasks.


A typical bad benchmark, it just tests more or less bad ports of an algorithm.
One might even think that there is some intended outcome coded into the ports … even ruby could be faster than ASM … if you try hard enough to get a real bad port to ASM.
If one would realy try to make a benchmark fast, he would use all tricks the language provides … why on earth should an implementation in C++ be ever slower than in C ? They may even be identical, if C++ does not help to make it faster …


Yeah this is something I’ve mentioned a lot. There is absolutely no reason for any C++ code to be slower than any C code, at worst it will be equal, at best C++ will be able to generate MUCH better code mostly due to templates.

1 Like

I just discovered the TechEmpower benchmark , as I was considering a new (for me) framework / langauge for a personal project . Basically debating between sticking with Ruby ( and Rails or Padrino), or trying our Elixir / Phoenix or Crystal / Amber.

The benchmark empressed me enough that I wanted to see how well it would perform for my one of my use cases: large number of requests to a JSON endpoint that pulls a (random) row or a set of 10 from MariaDB table of half a million rows.

My conclusion - real life application is way different from a benchmark.

Also for my case I needed a full framework not a micro framework ( hence not Sinatra or similar). Because of the number of different features I need that I would need to implement - I would end up with a fairly large app anyways, so might as well save some time.

I ran wrk2 against all setups .
So bottom line - Amber was only about 3x times faster than Rails 5.2 . Padrino performed about the same as Rails. Phoenix was about in about the middle of the pack. Once I added a bit more juice to my test VM, Phoenix actually was able to scale up much better and overtake completion.

So my conclusion here is that while Rails is slowest of the bunch - it’s well within my requirements of being able to handle ~200 req per second under 100ms response times on a low-end VM on digital ocean or vultr.

However as I was going through these benchmarks I realized that I will need a lot of libraries that I’m dont know if Crystal / Elixir have, and I know very well how to optimize hosting for Rails, but it took me a bit of time to do it for Elixir and Amber ( and chances are I still didn’t do it right, since I’m still learning ). Also it has a massive advantage of a huge number of gems that’s will save me time, as a one-man side project (Crystal and Elixir also have a growing ecosystem, but’s it not there yet, it seems?)

I I’m still considering building out an simple api in Phoenix or Amber just for the fun of learning either one , and building Rails/Elm frontend for it .

My point here is that those benchmarks are not very useful, because they don’t take into consideration very important real life considerations, requirements and constrains