Hacker News Reader

Comment by adamnemecek | Hacker News Reader

Ok, for backend, I’m deciding between rust with actix, jvm (kotlin + akka/quasar) or elixir.

I kinda know the theoretical differences but I’m curious what hn thinks. Has someone actually deployed things in some of these.

I do have preference towards rust but maybe there’s something better.

View on HN

Erlang/Elixir's VM is gear toward high uptime, low latency, and highly concurrent.

https://stressgrid.com/blog/100k_cps_with_elixir/

What it's not good at is numerical computation.

As for the others I have no clue but I am sure jvm won't be as low latency as Elixir's VM since it's not a preemptive scheduler.

I think a lot of folks writing low latency code in C, or for the JVM, would be surprised at the suggestion a lack of preemptive scheduler makes their work futile.

If those folks enjoys writing low latency code in C for backend... I'm not going to stop them. I'll sit in a corner somewhere and enjoy Elixir.

There's a JVM vs BEAM VM comparison paper (http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.p...).

I believe section 2.2. ERTS of the paper talk about BEAM VM advantage for low latency.

> The per process heap architecture has manybenefits, one of which is that because each pro-cess has it’s own heap and there are presum-ably numerous process’s,...

update:

Ah... I think the relevant part is in 3.3 Lightweight threads.

> 3.3. Lightweight threads

> The effect is that Erlang is one of a fewlanguages that actually does preemptive mul-titasking. The reduction count of 2000, whichis sub 1ms, is quite low and forces many smallcontext switches between the Erlang processes.

Java will get lightweight threads soon. You can google "java fibers".

Fwiw we’ve had a lot of success with Golang (graph-gophers/graphql-go w/ dataloader). Running in prod for about a year. Worth noting is that any GQL server implementation not written in JS, will play catch-up to the JS/Apollo counterpart. The JS ecosystem just moves so much faster

Before having success with Go, did you try or consider any other languages for your GraphQL server? What about other GraphQL libraries in Go?

Our backend is mostly Go so we _had_ to make it work. Tried most of the available libraries, gqlgen etc. But eventually settled on this one because of the schema-first approach and nice resolver api. And the defacto golang dataloader lib is from the same author.

Makes sense. Thank you!

Dotnet Core is actually really nice as well, I think v3 is right around the corner. Something worth checking out if you're looking into beckend technologies.

I've been using it lately, coming from Node.js for the last few years, and it's been a really nice change.

I've been on the fence about trying dotnet core for perhaps too long. What do you like about it?

Anything .Net can be replaced by Java.

That really depends on what you're building.

When would erlang,jvm be preferable over actix.

rust is still figuring out async, so it's not as good a fit as say go or elixir.

If you are specifically making a graphql backend, idk why you would anything but node, since it has the most mature ecosystem.

I mean actix just hit 1.0 and I don’t think it impacted them one bit.

The ecosystem is not really mature.

They're all wonderful, established technologies and all very capable of making concurrency relatively painless. At this stage, you should go with whatever you would be most productive in: do you already know one of the languages? If so, go with that one (always be shipping!). If not, how much do you like the syntax of each? How much do you rely on static types? How mature are the third-party libraries you're going to be relying on?

I've been building software using the exact stack described in the linked article for the last three years. I don't think about my backend very much, it mostly just works. Most of the work is on the front end. Elixir/Phoenix/Absinthe have been almost completely frustration-free. I'm sure Rust and Kotlin are great too.

Reply on news.ycombinator.com