Choosing Ruby on Rails for web development project in 2019

The first point is definitely a positive point for typing.

The second I feel is by design. A runtime exception is better than undefined behavior, which was the other option when many of these more abstract languages started taking hold. We're just reaching a point where languages with undefined behavior are being competed against by projects like Rust which offer similar performance without the same risks. Runtime exceptions become less attractive when you can avoid them and avoid undefined behavior with more comprehensive solutions.

> Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work.

Yes, this is exactly the problem. Ruby is so slow that you end up writing C extensions when you want to do any non-trivial computation. The documentation is bad, the tooling is bad, the build/CI complications are bad, and there's not much community info online about the process. And now your RoR developers have to support a C library, where a segfault can kill an entire Ruby interpreter.

I don't think most RoR apps run into these problems, which is why RoR is such a great thing in the first place, but we shouldn't brush aside how slow it is, and the implications of that when it becomes a problem.

Mostly interested in commenting on your last paragraph. But I think your first point of Django being more intuitive is probably due to your (I'm assuming here) background of growing with Django through time. As someone who has developed in both, I find that Django is basically RoR version (n-1). People claim that Django is too complex for them over Flask. I say it just takes time to learn all the features.

Anyway, as for the academic/scientific thing. I couldn't agree more. I feel like they are just perpetuating something silly. I can guarantee you that no one in academia is using Django for research. Probably some weird transitive logic like science => numpy/pandas => python => django.

But I think this stems from the target audience of the article:

""" The only person who won’t find much use for this guide would be a high-level master Ruby on Rails developer. If you’re not on that level yet, then you’ll definitely be able to learn something! """

That is, if it's useful for everyone, it's useful for no one. The whole comparison table is unsubstantial. As interpreted languages, they are going to be roughly the same performance especially on a single thread. If anything, Ruby might be better on multi threaded due to the GIL but then this is contradicted in the table where it claims that Django is more scalable which I think is more of a comment as to how project architecture is laid out in Django with everything supposed to be a separate app.

Re: Maybe it is the convention over configuration mindset which results in lots of magic

Yes, the "magic" is a double-edged sword. I find a similar problem with Dot-Net MVC: when the "helpers" work as intended, they are great. But when they don't, troubleshooting takes way too long. (MS-MVC is more or less a clone of R-on-R.)

Its auto-matching of URL's to controllers & methods etc. (routing) is an example of this. A bunch of IF or CASE statements to do the same thing would probably be much quicker to debug, even if it's more typing up front. (Or even put the mappings into data tables for bigger apps.) One can scaffold (auto-generate) IF/CASE statements for such if needed to reduce the original build grunt-work.

All these "magic helpers" are over-complicated and opaque. Yes, I know that once one gets used them they know how to cajole them, but the learning curve is unacceptable for things that should be relatively simple. The helpers are more trouble than they are worth because they try to fit too many application types and styles, and rely on reflection, which makes following the actual helper code a pasta factory visit.

Must it be that way? I want clear and logical processing, not a bunch of organic dark-grey boxes. Maybe I'm old fashioned and relying on a bunch of dark-grey boxes glued together is the proper "new way"? #Idontgeddit

Maybe it's better for big projects or large pool of devs where you hire plug-and-play specialists who know a specific technical area well such as routing or views. But in shops with smaller staff or that divide tasks by project or entity instead of tech specialties, this doesn't make sense. But orgs feel compelled to do it that way because "everybody else is": MVC-Lemmings.

Objects don't solve this. Untyped programming is more flexible, but are able to express less things about the domain explicitly than typed languages (not Java/C#, but rather OCaml/Haskell etc.).

> if a static analysis tool were able to point to the same issues, the reason would evaporate.

This static analysis tool is called the type checker. The experience of using a type checker is best when the underlying language has sound types. Sorbet, TypeScript, Typed Racket etc. bolt a type system on top of an existing language, and so don't have a choice but to be unsound, and so their qualitative experience isn't as nice as it could be. Even so, they're highly recommended for large codebases.

> It's like saying a language is better because it has a better community, which is practical but not intrinsic

Not at all. This is an intrinsic feature of programming languages and has a huge effect on how we think of programs.

It is however not a silver bullet and when building web applications, practicality - tooling, ecosystem etc. trumps everything else. However if you run into difficult problems which require deep attention to data modelling, and wish for a better tool to help frame the problem, then Typed Functional Programming might be a good try.