[stefanchrobot]

Quite surprising take on the languages.

> When to use Python or Ruby

> Python and Ruby seem to me to be pretty similar in that they’re scripting languages and dynamically typed and seemed like the greatest thing in the 00’s. You use them when speed is more important than legibility or debugging.

I'd say you pick them when productivity and time to market is important. I personally find dynamic languages far more legible (unless you're doing metaprogramming-heavy stuff).

> Haskell or Erlang maybe I would use if I were doing something that required a very elegant or mathematical functional approach without a lot of business logic.

I think it's a mistake to throw these two into the same bag. I'd say Haskell is functional and comes from academia. Erlang is concurrent (with functional aspects) and comes from engineering background. You'd want to pick Erlang if you want to build scalable backend systems.

> my guidelines for JS are:

> Try to push as much logic as possible to the server. If the front end weren’t super complex, I would consider something like Phoenix instead which actually pushes everything to the server.

Phoenix is a web framework for Elixir and Elixir is a Ruby-like syntax on top of the amazing Erlang VM, so this kind of contradicts the suggestion above. Either way, Phoenix LiveView might be a game changer when it's applicable and for people who don't find the whole JS thing very exciting.

[faizshah]

People overrate the elegance and readability of languages. You can write elegant and inelegant Java. I've seen python code that is totally unmaintainable and python code that's some of the most elegant out there. You can find Rails code that is some of the most indecipherable spaghetti out there despite Ruby being such an elegant language (the project had Fat Controllers, Fat Views and Fat Stored Procedures...yikes). There's a lot of elegant C code out there then there's C code where you don't wanna touch anything because you're not sure what anything does.

I think the general rule of thumb for languages is pick whichever language has the best community, learning resources and packages for your project.

For example R excels at analyzing data because of the wealth of packages from industry and academia for analyzing data and the tutorials dedicated to statistical analysis in R. Python excels at high performance data driven products because of the wealth of packages for ML, scientific computing, etc and the wealth of resources on doing these things in python.

The exception to this is JS and your point about Phoenix LiveView. Potentially it could be better to pick a single language for frontend and backend to limit context switching while developing frontend and backend.

I haven't used Clojure or Haskell yet so I don't know what they excel at. I also haven't dived into Erlang and Go enough to know which situations either is better for scalable backends.

[jiveturkey]

> People overrate the elegance and readability of languages. You can write elegant and inelegant Java.

It's not what you can write, it's what the next guy can write.

You can write elegant Perl. But the language isn't suited to that. The next guy is going to use a more typical write-only style of Perl. Extreme example, but you take my point.

[keithwhor]

> People overrate the elegance and readability of languages.

> The exception to this is JS

JavaScript is beautiful. You're crazy.

[faizshah]

I think I was unclear. I meant that the exception to picking a language based on community, resources and modules are JS and Phoenix Liveview where there is an additional benefit of using a single language for frontend and backend. In these two examples you might forego using a separate language for frontend and backend (that could have a better community, resources or modules for what you are building) because you can use the same language for both (which offers the unique advantage of having to use and learn less tools for a fullstack app).

[twic]

> I personally find dynamic languages far more legible

Maybe you're a 2xer though.

[mozey]

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" -Brian Kernighan

Over time I've come to appreciate this sentiment. Banging out clever code super fast isn't that important... Spending some time up front thinking about types and architecture pays off in the long run. Especially for server side code. Far from being annoying, error messages from the compiler make me feel warm and fuzzy inside.

On the other hand, for quickly prototyping user interfaces, some "stream of consciousness" Javascript might just be good enough.

[wonderwonder]

I very much like this quote. Used to work with a team of contractors out of Eastern Europe. They were exceptional programmers but wrote code using obscure language features and in such an odd way that now that they are gone, every time someone has to debug some of their code its a very frustrating process. There are definitely times to use 'clever' coding practices but nine times out of 10, just write it simply and focus on readability. Your team will thank you and you will thank yourself a couple years down the road.

[wolco]

We all used to do this (ii feels right) until we got burned or had to upgrade and rewrite. Now I try to make everything as simple and straightforward. Really helps you scale because yesterdays work doesn' t need to change.

[JackFr]

Me? I’m a fan of Blub.

[twic]

I liked Blub before the 3.0 release ruined it with all those new features.

[freewilly1040]

Well written code in dynamic languages is legible. The problem is when you encounter poorly written, illegible code in a dynamic language, the lack of strong types kneecaps your ability to figure out what it is supposed to do.

I loved Ruby until I inherited a project that was poorly written Ruby.