@TKS asked me to create this poll on Discord because he can’t do it.
0 voters
If so, I’m kinda mixing with Reason and Node, Reason compiled to JS tho. But really wanting to go full native with ReasonML/OCaml
Whoa, I didn’t even know Discourse had polls. Of course, having just found out about it five seconds ago, I’m already wishing the poll was multi-choice!
I answered Scala, but we’re slowly getting some Haskell in there too. I don’t work on the backend though.
I chose Javascript, but I have used Python even more, I thought there are multiple options 
Currently working on quite a NodeJS backend infrastructure with a lot of moving parts and a very scary and powerful GraphQL endpoint, which is used to manage server infrastructures and user access via SSH keys…
Especially changing things on the API is scary! Just moving around IF statements for permission checking makes me question the decision on doing this in JavaScript.
I am pretty sure, if I have to maintain this for a longer time, I would go for gradually introducing Reason… luckily I built the server in a way so that it’s easy to replace file by file later on.
Thanks for all the answers ! (I’m TKS)
I’m using Javascript, with a lot of GraphQL and some other basic stuff. Right now, I don’t see the value of ReasonML as a backend language. I’m looking FP (Ocaml, Clojure & Haskell) right now for a replacement.
(Haskell, 0% though 
)
I think right now Reason’s value proposition is pretty clearly for the frontend, especially with JSX. On the backend it should be possible to use either Reason or OCaml syntax, there’s a rather high-quality GraphQL server: https://github.com/andreas/ocaml-graphql-server for native.
Really goes to your requirements though, OCaml is definitely not a clear winner in the backend (yet).
Node. Because sometimes the familiar choice is the best… also because of great graphql support.
Elixir comes in at #3 but nobody said why they are using it. I’d be curious to hear (never having used Erlang, I’m not sure of the great advantage of it). This also reminds me of an interesting article, which talks about agile, functional vs OOP, and compares OCaml, Erlang, and Golang:
Few days ago I tried graphql_ppx and once I added a query for the first endpoint type system found 2 errors in my backend schema. go's graphql implementation is unsound due to no-generics thing and also it’s super verbose so it’s easy to make a mistake. I looked around one more time on other backends and found that juniper (rust's graphql implementation) looks pretty sweet. I just run dummy server and it feels really really good: graphql’s data types nicely match rust’s data types and implementation is sound. Has anyone experience w/ rust graphql servers? How it feels like in real apps?
Hi @vonwao,
For the backend, Erlang/OTP brings excellent concurrency through the BEAM virtual machine and the actor model in a dynamic battle-tested functional language. The backend scalability it brings is (I believe) unmatched allowing millions of worker “processes” to be cheaply and easily spawned per server scheduled on all of your cores and distributed among many nodes. You can find many articles discussing how services such as WhatsApp and Discord (and others) cheaply scaled using it.
Elixir brings a Ruby-ish syntax and excellent documentation, tooling, curated standard library, metaprogramming capabilities, and community to Erlang/OTP. Phoenix (web layer) was inspired by Rails but is much more explicit with less magic but still “productive” (and a lot faster). It can be used as a traditional MVC SSR solution emitting html from templates or as a REST/GraphQL API server and has good channels/websockets functionality. Ecto is the excellent database layer in the ecosystem. The ecosystem is smaller than Ruby/Rails but I’ve found it’s big enough to have good libraries for everything I’ve needed so far.
Elixir brings a more Ruby-ish syntax to a >30 year old rock solid language and ReasonML brings a more JS-ish syntax to a >20 year old rock solid language! Purists may disagree but I think syntax and familiarity definitely matters for adoption!!! Elixir doesn’t have the awesome inferred static type system we get from OCaml (as a dynamic language) but we can do success typing, liberally use guard clauses, and love using |> everywhere.
To more directly answer the question… I (and many others) have come to Elixir/Phoenix from Ruby/Rails and appreciate the more explicit, faster, and immutable/functional approach. I think many of us are at least experimenting with ReasonML since there have been many long threads on elixirforum.com talking about Bucklescript, OCaml, ReasonML, and Bucklescript-TEA.
Many in the Elixir community advocate for Elm as a JS alternative but, for me, the far better JS interop (with human readable output from BS), lightning fast compiler, more pragmatic/open ecosystem, and the familiar C/JS-ish syntax of ReasonML seals the deal.
If anyone wants to look for a fresh functional backend alternative to JS/Node, I’d definitely recommend giving Elixir/Phoenix a try!
Ruby on Rails is my default backend choice. I suppose it’s mostly because I’m familiar with it, and happy with how well it works. The framework is mature, it has tons of community support, and with its recent trend towards embracing Javascript (via webpacker), I’m not missing anything. I can even write ReasonML instead of Javascript in Rails now - I haven’t tried that yet, though.
The biggest back-end project I have written was in Perl. It had to do a lot of text munging, and Perl is very good at that. Also, was written several years ago.
We use Elixir for 99% of our back end, and imo it’s ridiculously good at its job. It’s extremely nice to program in, learning resources are of very high quality, the tooling is phenomenal (with a fairly large caveat regarding releases - the tooling was built to be user friendly rather than making releases easy which has caused some issues, these are currently being fixed for the next version due this year). The VM is a marvel.
Use case is long-lived applications [with lightweight message passing between the application processes/nodes/etc]. I use it for web backends and it absolutely blows Node et al out of the water. Set up correctly, it’s pretty much rock-solid. It’s most similar to Go I guess, but it has a very different approach to concurrency.
There are a fair few warts/downsides, as with any platform. In particular it can be [very] difficult to grok if you’re not familiar with how OTP (the framework that is one of the three parts to Erlang along with the VM and the language) works. Erlang syntax is, umm, peculiar if you haven’t encountered it before (Elixir isn’t so peculiar). It’s not typed. String handling in Erlang itself is pretty nasty (however string handling in Elixir is imo better than any other language, so, yknow, swings and roundabouts :shrug:). There isn’t vast ecosystem (though that tends to be less of an issue than it might seem at first glance). It’s not particularly fast (though that tends to not be a particularly relevant measure, you exchange speed for latency and robustness, and it automatically load balances work from discrete processes across cores). It works best within an Erlang infrastructure; having services in other languages and calling into them from a system written and controlled by Erlang is pleasant, other way round you lose many [most?] of the benefits of Erlang. Programmers are thin on the ground. It’s crap for computationally intensive stuff (you can use Rust/C/etc without losing many the benefits of Erlang though). It’s not great for scripting.
On the upside, it ridiculously robust. Once you grok it, it’s very simple, there is no magic. The [focus on] documentation is terrific. It’s isn’t very big, there isn’t much to learn, and there is a focus on keeping the language as lean as possible. Systems feel very rapid when used in the situations where Erlang excels (web backends for example). It’s exceptional for stateful applications. The actor model is extremely nice. You can do fun stuff like: today we needed to force through some activity on our system that had failed first time round. We remote shelled into the [running] app by connecting an Elixir REPL process to the running process on the remote server, modified the [running] code on the server, reloaded it while it was running, reran the activity.
You can do almost anything you can do on Erlang using other platforms, gluing together various other disparate services, but you then lose the simplicity and consistent interface and tooling.