You are not mean. 
It was a few years ago and was on an older Ubuntu and changing the server was non-negotiable. I can’t remember the details but I was left with some mild PTSD on the topic. 
Since then, and when working with Elixir, I am OK with sacrificing some performance and go with NIF-free dependencies. I am sure things have improved quite a bit in the meantime.
Thanks! 
I can understand the PTSD of that kind of work.
I started my last couple of side projects because there is a kind of rivalry at my company between Go Programmers and Elixir Programmers, and the main point that the Go programmers continuously make is performance. Of course the performance they are talking about is by using extremely optimized low level Go libraries like fasthttp instead of the more established and simpler to use web frameworks web frameworks, so I decided to start looking at libraries that leverage NIFs better, like Jiffy, to see how big the performance boost is, in order to prove that when used write and written well, Elixir/Erlang can be just as performant.
You guys should not have a rivalry based on speed, but on:
Code readability and long-term maintainability. Dunno about you but I regularly had to mentally squash 30 lines of Golang code to “oh, this does map with filtering, and then does a reduce” in my head. It’s exhausting and is not helping me want to learn more.
Fault-tolerance, which people only appreciate when they see how their language of choice does not have it. I prefer an Elixir server maxing out 50k / sec users that never makes a mistake and keeps everybody’s latency to acceptable levels, to 400k / sec users in Golang and having to periodically look for the reason of yet another abrupt panic (which happened several times in my previous Golang contracting but hey, I might just be an idiot, that’s a fair possibility as well).
Brevity. This is related to the first point. Less lines of code == less bugs, that’s basically one of the very few universally proven rules of programming. Most of the functional languages are pretty terse and that’s an asset.
I still dig Golang for a number of reasons but its verbosiveness and bad long-running services story are not appealing. You can also read the gaming streaming service Twitch.TV’s blogs on their adventures with Golang which are mostly positive – but they had some pretty tough fights to win along the way.
Jiffy is generally faster on single-threaded benchmarks, the difference is much less pronounced when you start running concurrent processes all doing JSON stuff - Jason being all Elixir means it uses schedulers better - Jiffy being in C has a bit harder time dealing with that. At least those were my findings when I was benchmarking it around the initial release.
Also - the fact that it is in C is problematic, especially on Windows. It raises the entry bar considerably if you need to compile C on Windows, which many beginners use. I can only speculate this could be a reason for Phoenix sticking with a pure-elixir library as a default.
Additionally, especially with encoding, Jason can be much faster in practice. Jiffy can only deal with simple data types - strings, integers, maps - you need to encode everything down to that before handing it off to jiffy - especially annoying with things like DateTime or similar. This usually means two-step encoding - from your application to simple terms and from that to JSON. Because Jason is based on protocols, in can do all of that in a single, extensible pass. Furthermore, with deriving and the macros in Jason.Helpers module, you can do some additional work at compile-time to speed up the encoding even further. I wouldn’t be surprised if all of that noticeably outperforms jiffy.
I also have some ideas that would make it possible to do single-pass decoding into more complex data structures - in a similar way this should give an edge to Jason over jiffy if you don’t need to go over your data twice. At the same time it’s hard to find an API that would be both fast and extensible. As a last point when it comes to performance, when initially writing Jason, I had plans to include some optional native code to speed up the hottest loops - but there wasn’t that much demand for it so far, so it’s waiting for better times 
.
Just a note, this is more of a friendly rivalry than a real one. Our main core of the company is being written in Golang, but we have legacy core services written in Elixir.
My argument for choosing a language is always going to be code readability and developer happiness, because at the end of the day if you want the best performance than just write everything in assembly.
Unfortunately, right now a large amount of our services are being written in Golang, so it is seeming to be where we are moving to right now.
Thanks for jumping in with this! I always love hearing from the core team members in the language to see what they think.
I agree that because jiffy is written in C it could be problematic, especially for Windows users. This is one of the beauties of working with Docker/containers, that way you don’t have to worry about the system you are using locally, just the one you’ll be using in the field.
What kind of benchmarks would you run to try and get more accurate results here? Mine were pretty simplistic, it’s just running encode/decode on the same input and that’s it. I’d love to start setting up benchmarks to see how various libraries deal with multithreading and schedulers, more complex data types, etc. Do you mind sharing the benchmarks and files that you use for checking Jason?
The benchmarks are in the repo - jason/bench at master · michalmuskala/jason · GitHub - it’s the same ones that Poison uses. With Benchee, you can also pass the parallel option to run concurrent benchmarks, but in that case the results are much, much less reliable. Running them on a real service is probably the only way to measure it reliably and check how it will perform in your use case.
We do what @michalmuskala suggests. We’ve benchmarked Jason and Jiffy with each of our individual services and we go with the one that makes the most sense.
But JSON is a garbage data format and we’re actively exploring alternative formats for our service communication layer.
In this same vein, I recently published serde_rustler, which tl;dr lets you serialize and deserialize Elixir terms within your Rust NIFs. To benchmark them, I transcode from Elixir term → serde → json string and vice versa, and compared it against the other JSON libraries I could find.
They look, lets say, promising. I’d appreciate if anyone could tell me if I did something wrong to get these results: encode, decode.
@michalmuskala can you explain why the parallel option would distort the results, when in production you’d be running your app with load from other parts of your code?