Should I choose Elixir for web apps?

Questions / Help
, ,
21

I learn OCaml through ReasonML because I am more familiar with JS world. But thankfully, it is easy to convert from ReasonML to OCaml.

I learned Erlang through Elixir, because I am more familiar with the Ruby world :slight_smile:

But to focus on the question, I would add that Elixir is just the Backend part of a full web apps.

You might not escape JS world when dealing with Web. That’s the reaon to learn… ReasonML.

Unless You replace it with WebAssembly… and it will be a good time to learn Rust.

1 Like
22

@kokolegorille / @OvermindDL1 I was asking about backend OCaml usage though! :smiley:

Appreciate the remarks on BuckleScript / ReasonML. To me, the OCaml syntax is still alien but I really do like the idea of more preliminary contracts and would endure the learning process to [hopefully] have a class of bugs be eliminated by the compiler the moment your program is compiled successfully.

As for boilerplate: don’t the BuckleScript / ReasonML stacks offer macros or function calls that emulate the above kind-of-looking-verbose snippets? I’d naively assume so.

23

Oh on the backend OCaml rules. Just treat OCaml as a faster, safer Python and you are generally good to go. It has some great libraries for backend web work. :slight_smile:

24

And there is an OCaml GraphQL implementation, where type safety shines…

@dimitarvp I am not familiar enough with OCaml to answer your question. But as mentionned by @OvermindDL1 You need to declare this to ensure type safety.

1 Like
26

I have considered Ruby and I’ve noticed that lots of Elixir devs used to use Ruby or still do. I’ve learned a little bit of Ruby in the past and I like it a lot but I’ve personally never used Ruby for any projects. That being said, I love your idea about using Ruby for rapid prototyping and using Elixir for the real system.

I guess what I’m really trying to do is to just avoid using only one programming paradigm throughout the day. I want to stay fresh on OOP while using Elixir so using Ruby for prototyping and testing out ideas sounds like an excellent idea. Also, I actually like Ruby more than Python but was only going to go with Python because I have previous experience with it and because it’s a bit more popular right now.

Thanks for the ideas. I’m going to take your advice and go the Ruby and Elixir route and use TypeScript mainly on the front-end.

27

I don’t think one language does fit all.

Be prepared to learn the best tool, for a given situation.

For example, Python is an excellent choice if You work in AI.

1 Like
28

But I don’t think Ruby is any faster for prototyping than Elixir.

1 Like
29

Sure (the mods will probably want to move it though).

A (not so) little history first: the first language I learned in university was Caml, and second was OCaml a year later. Every student hated them because at that time the trend was C, Java and C++ (and the way it was presented, I think most students took Ocaml as a beginner language), but after learning those I missed the ability to be able to match on elements of a struct, and be reminded by the compiler that matches were off if I ever added or removed elements, among other things.
After a few years coding in Lua/JS/C++ I started coding a web server in C#, and even though many things were great and I enjoyed it, I still was not happy with all the runtime errors we always get because of a bad case or missing letter, and all the time lost because of that. I vented with a coworker (who is a fan of haskell) and kind of joked that if only there existed a webserver in Ocaml I’m sure it would take care of that at compile time and everything would be a breeze. He told me it was worth a look so I searched, and stumbled upon Ocsigen. That webserver, like Ocaml, was a thing of beauty that only cave-dwelling researchers can create. I was so happy! You change the number of fields in a form and forget to update the function handling the post? You link to a page you didn’t implement? You do a typo? The compiler will yell! Great! That’s what I had been waiting for years! Oh, and the ocaml code you wrote to check the form inputs? It’s going to be transcoded into JS so you can have client validation for free (and if you deactivate JS it works the same, unlike phoenix liveview :wink: )! You want to navigate to another page? It will diff the pages and send you just that. You could code your client side in ocaml too and share code between client and server. Etc.

There were three problems however:

  • the compiler doesn’t know how to yell constructively. It’s not as bad as in C++ were you can get pages of errors because you forgot a semicolon somewhere else, but not far. The errors I get when I try carving my way with Elixir make so much more sense, instantly: they were made to be read and understood (and are presented beautifully on the page to boot!). Not Ocaml errors… You get somewhat used to them after a while but be prepared to lose your hair.
  • this fantastic project felt more like a proof of concept than anything else (and indeed it was). The project website was not nice, there were dead links everywhere in the doc (it’s impossible to have dead links with Ocsigen within the project, but they stupidly put their example code in other projects. What’s the point then?), and the docs themselves were poor and unhelpful. You had to infer many things in order to have a working skeleton of a website (again not in the docs), and the lack of an active community as well as personal problems made me lose interest after trying to make a few small websites 4 years ago.
  • the JS generated by the project is huge. I have only one small website still up using Ocsigen, and the bare JS is almost 5MB. Mostly static site, not even forms. That was the last nail in the coffin for me, as I was pondering about the strengths of Elixir/Phoenix at that time as well.

In short, the main issue with Ocaml is not Ocaml itself. Great minds built it, but those people are no marketeers nor web people. They do not think they have to be, and I understand that, as their focus is on industrial projects.

3 Likes
30

Glad to be of help. Another item to take into consideration is that in some languages you can program in more than one paradigm, e.g. C++. Also, the next version of Java will incorporate more “functional” features to the language. But again, for web development Elixir and Ruby will allow you to cover all the basis.

Cheers

1 Like
31

Good point. I was thinking that the OP (like most developers) has more experienced in OO languages and that Ruby will allow him to develop faster. But you’re right, that’s not so much about the languages in question

32

This is very understandable and they have my respect for it. I myself was a bit of a specialized programmer in my first 5-6 years of career and then moved on to being a generic CRUD web coder… which I don’t at all appreciate nowadays. -.-

That being said, I feel that languages like OCaml can really make a dent in the current foggy mire of half-specced – and poisoned by corporate tech lobbies – technologies like HTML, CSS and HTTP.

Thanks for the fantastic reply. :023:

1 Like
33

I forgot to say, but of course, being in OCaml, when you build a page with Ocsigen the compiler will ensure that the html tag tree is valid :slight_smile:

I wish! The language is great, but for it to come out of its niche a lot of work needs to be done on the tooling and docs especially (also, find a way to centralise the community a little bit in order to be able to drive the mammoth). New languages are often half-specced indeed, but at least their creators understand that appearance and ease of approach matter, and they matter a lot!

Edit: you should have a look Multi-tier programming for Web and mobile apps
I see that they upgraded their website. Good! And they support reasonML. Actually I hope that reasonML and the hype people @ facebook will make the tooling that the Ocaml community has always lacked. They have the money and know that stuff like this matter for a wider adoption.

2 Likes
34

Yeah, Ocsigen is a fascinating idea, but apparently more of a research project than a practical production-ready system.

35

@nodemodule provides good reasons for choosing OO; better chances to land in a job or build a team. There is not much choice when you start looking for work with elixir, moreover a lot of job offerings are for blockchain and chat-things. Nice to learn the language building those type of applications maybe, but very very limited. I think it is a good language for the regular administrative sort of applications I have been building for 20+ years. I for me am distracted by the inheritance of what seems to be the ruby culture; the influence of agile guru’s http://darkagilemanifesto.org/dark-side-of-agile-janes-succi-splash-2012.pdf (some of those who signed the manifesto have been part of the ruby community). Name an agile elephant in the room: TDD, paste what a renowned scientist said about it https://archive.li/2zZKy#selection-293.30-305.209 here and silence is your answer. Afraid to hurt the believers? No good answer, just wanting to move on with TDD? Bashing OO: no problem, “now we can talk!”. I see it in a lot in elixir job offerings: “experience in TDD appreciated”; enough for me to lose interest. Programming for some time in a functional language helps learning to write better code in OO languages. A lot of those evolved to multi-paradigm.

36

I faced a similar decision in late 2016. I was choosing between Elixir/Phoenix and Elm, and studied both for several months. I’d come from Ruby on Rails, where I built an app for my business from 2010-2015. For that, I’d avoided Javascript (even peppering) as much as possible.

Elixir’s forthcoming LiveView (or current alternatives) might have tipped the balance, but I went for Elm because I wanted to have a more dynamic user interface. Where I need a backend server, I’m using AWS Lambda, but I’m still studying Elixir and expect to still find uses for it.

I think both Elixir and Elm are great choices if you want a language that is “fun, productive, and that is easy to scale”, and the two complement each other well. And both are in a stable phase right now, with Elm recently getting a much-improved compiler (in terms of speed and code size).

37

Elixir/Phoenix and Elm are not competing in the same category. Elm is typically Frontend, while Elixir/Phoenix are more Backend.

You do not really avoid JS when using Elm, You are writing JS, but with another syntax.

Elm is not really good in interop with JS, it is hard to take advantage of the numerous JS libs available.

2 Likes
38

Given how the opening post is phrased I would say that recommending Elixir in this case would be irresponsible. So I didn’t. The most appropriate response had already been made:

I simply pointed out that the mainstream choice has challenges of it’s own that its proponents often gloss over. And I think Garrett Smith’s talk sheds some light on why BEAM based development isn’t more popular today.

Other than that development by slogan and some of the BS that results from it whether it’s associated with TDD, Agile(trademark) or whatever is an industry wide phenomenon. The market’s desire for quick fixes seems to attract a lot of snake oil salesmen.

Programming for some time in a functional language helps learning to write better code in OO languages.

Yes, but many people believe that using functional features in imperative languages is good enough but they don’t get away from place oriented programming until they are forced to deal with, for example, immutability.

A lot of those evolved to multi-paradigm.

It should work but it often doesn’t. The promise of multi-paradigm languages often isn’t realized as the paradigm choice is often a reflection of the organization’s/developer’s comfort zone rather than its appropriateness to solving the problem at hand.

There simply is no Be-all and End–all way of doing things.

1 Like
39

If that’s not one of the best descriptions of the IT area I don’t know what is. :023:

:024:

1 Like
42

Did you quote me by accident here? Not understanding your response?

43

I was merely quoting you (rather than responding to you).

I was just taking the position that I didn’t need to reiterate a point that you had already made in response to the topic before I made my first post.