What's your actual backend language and why?

#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.