What's your actual backend language and why?

#15

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:

#16

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?

#17

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!

#18

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.

#19

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.

#20

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.

#21

Man. You’re really killing it until that line :frowning: I really need a good ecosystem for building a solid graphql server. I’m using node with reasonml right now and it just doesn’t feel right. the integration is broken and I only get half baked type-safety

#22

Yeah, I knew adding that parenthetical would weaken my argument around these parts. But just wanted to give full disclosure.

For better type safety in Elixir, I rely on pattern matching and guard clauses extensively. You can also do success typing (defining types with the @type and @spec directives and checking them with Dialyzer – which the VSCode extension can do automatically).

Absinthe GraphQL is an excellent library for GraphQL servers for Elixir/Phoenix and I’d still recommend at least looking into it combined with the IMO great Ecto database library for your resolvers. The docs (throughout the ecosystem) are thorough and the community (on elixirforum.com) is super helpful and friendly like the ReasonML community. There are also a lot of learning resources available (sites, articles, books, video courses, etc).

I really think you would find a lot to like about Elixir and it’s worth looking into. 13% of this poll’s respondents can’t all be wrong, right? :stuck_out_tongue_winking_eye:

Feel free to reach out if you have questions.

#23

Yep. I really literally like Elixir from what I’ve read. But the fact that’s a dynamic language is a big no for me

#24

You may be surprised, it’s a compiled language and from what I understand a lot of things are still caught at compile time.

#25

Oh. I didn’t know that. so it’s a compiled language. Interesting

#26

Yeah, compiled and strongly typed. afaik there’s no deep reason why it’s dynamic, beyond that the implementors were used to dynamic languages (though I think there are some minor issue re typing PIDs and the faff around defining types across processes, Overmind seems to have done a helluva lot of experimentation on solutions to this which is interesting if you want to dig through Elixir forum posts).

YMMV but lack of a type system isn’t a massive miss; safety guarantees come from the way you have to structure Erlang applications, being typed or not doesn’t really change that fact. Dialyzer is quite good, if extremely slow on first initialization as it builds the lookup table for the project (though it looks like there will be improvements to that soon). It’s definitely not a replacement for a good [H/M] type system though, it’s just [non-binding] contracts.

Alpaca seems to have the most traction w/r/t an ML-like typed language on the BEAM VM, but there isn’t dead simple interop between BEAM languages at the minute; programs need to be compiled into lib within an Elixir project, you can’t just mix and match elixir/erlang/lisp-flavored-erlang/alpaca/erlua/whatever files.

#27

The creators of Erlang mention that it has been designed as a dynamic language with a reason, so that OTP works as it works.

#28

Java/C++. Reason on the front. OCaml/Reason lacks value for the backend at the moment, and Rust is probably the up-and-comer for that.

Crystal language looks kind of nice tho. Admirable goals.

#29

In fact I have made backend in many languages “java/scala/kotlin/js/ts/c/c++/go/scheme …”, but Kotlin is the most flexible and productive right now in times of async IO, i think that with a little more DSL capable, ReasonML will be the best of all.

#30

i second elixir, once you get your head wrapped around it, it makes coding a joy and extremely easy. it makes you think about how your app works before coding it which reduces the number of bugs rewrites., logic errors. also helps reduces complexity and mental entropy as being able to build your software as a virtual network modeling your business process as actors and passing messages between themselves which is similar to calling up your friend domain expert on the phone and getting a reply on a interested topic. i find the observer second to none in so much as a look into the domain.

#31

I’ve used it every day for 3 years and I would still not do a big refactor with it. Its better than javascript, but with regards to refactorability with js at 0 and Elm at 10, Elixir is like a 2

#32

IMO, Reason has at least two strong points going for it as a backend language:

  1. Compile to JavaScript and have access to the NPM ecosystem with all the power of Reason/OCaml.
  2. Use the same language as your frontend, assuming that’s in Reason too ;-). This is not just for sharing types (which does not work as well as one would imagine due to the different intents and interests of backend and frontend systems) but just simply for easily switching between the different modules - assuming you work in an environment that does not strongly categorize people as either.
#33

Kotlin, using for a couple of years but I am thinking about to switch to something more popular.

https://wishfulbets.com/

#34

In the spirit of necroposting, this is now even more feasible with Dream:

sample

The main announcement is over in the OCaml Discuss (not sure if this forum is still officially alive or not). Among Dream’s many examples, there is one showing full-stack Reason with the Melange fork of ReScript (BuckleScript). It could also be done with the ReScript compiler, since it still supports Reason syntax.