Friend: dude, JavaScript seems awesome. It looks so easy and there aren't any annoying compiler errors like in Java

Me: I know it sounds cool in theory, but it sucks in practice, trust me

Friend: no way, dynamically typed languages are the future

*Friend installs node*
*Friend writes a simple script*
*Friend gets undefined errors because of a few typos and has a hard time debugging it*

Friend: JavaScript is retarded

-_-

Tends to be my experience with dynamic languages 😂
I like using Python occasionally for scripts or small Lambdas. But so many of the errors I get are things Java would have caught in the IDE.

@LLAMS same, python only for small scripts and for web I use typescript whenever possible. Having developed a medium-sized SPA in JavaScript I can say that using dynamic languages for large projects is a pain. However, I'm curious about Ruby, since people seem to like it quite a bit.

@Root you like Ruby, right? Is it not a pain to work with on large projects?

Typescript changes everything. Just add a compiler and…

@neeno Everything is a pain on large projects. But to answer your question, I’ve found Ruby to be easier, honestly. It allows people to write extremely readable code which helps with maintainablity. You can also add or include methods on anything, meaning adding translations on builtins to specialized classes is trivial and looks natural. (Similar point with inheritance, but that’s normal now.)

Really what I like most is how nothing violates the principle of least surprise. Everything works as you would expect it to. And a good Ruby dev will name their classes and methods how you would expect, too, so you’ll often instinctively write working code without even knowing it could have required research.

Ruby is also a bliss to write in.

Rails... adds a lot of magic, which can make figuring out code paths incredibly challenging. Thankfully this is somewhat rare. But all of the above still applies.

@LLAMS
I use type hints in python extensively. I essentially treat it as a strongly typed language for any bigger projects

@Hazarth as long as you have strict linter and formatter in place, yeah

@Root thank you for the thorough answer! You restored my interest in Ruby.

@Root Ruby as a language I rather like. I'm not a fan of weak typing, but if I *had* to pick a language in that category Ruby would be it. Rails though - last time I worked with that I couldn't stand it. Way too much "magic" that mysteriously stopped working and was then impossible to debug. Admittedly the last rails project I was involved in was nearly a decade ago, but that was enough to put me off.

Ah, yes the innocent mindset of beginners who think that compiler errors make a programming language bad. And that everything should just fail silently. 😄

@Root Thats statement with code paths is a huge "wtf is this" for me as a rails beginner. Do you have a good resources that explain it? Otherwise I can really understand why you like it so much. It looks good and just works.

@JFK422 The rails docs are actually pretty good. Specifically for these, look into action filters/hooks, such as before_create, and polymorphism. Others involve routing (e.g. new_user_path) as these methods exist without apparently being defined anywhere. Same with some automaticity defined active record methods, like #{object_instance}.#{column}_changed? — but those you’ll only see rarely.

Polymorphism... you can have a polymorphic association on an object that points to one of multiple types of other object. Example: an Author has_many Publications, which can point to Book, Article, Paper, etc. As long as each class implements the same basic interface (such as through inheritance), you don’t really need to care which object types you get back, but if they differ, you can run into subtle bugs.

Depending on codebase complexity and craziness, there might be other magic, but there you should ask the person who wrote it. It’s incredibly rare to see, and often doesn’t exist for a good reason.

Example: on our codebase at work, objects both have_one and have_many of the same association. It took someone a lot of hacking to get that craziness to work and to convince Rails not to throw a fit. Why did someone implement it? The has_one points to the current “active” object (payment, schedule, whatever), and the has_many point to the remainder for archival and records keeping. I mean, it works, but there are definitely better ways to implement this.

Also reimplementing it in a new class is a pain. And figuring it out for the first time? Yuck!

The tl;dr version:
Rails magic usually isn’t difficult to understand, it’s easy to look up, and after a little while it’s pretty intuitive. But as with anything, people can and will muck things up and make something backwards and stupid. Scold/beat/murder them for it when appropriate/desired.

@irene agree it changes everything. adding typescript start getting compilation errors, slow compiling so can waist extra 5-20mins on pipline to compile and test all code. even better typescript compiliation bugs are cool. compiler written in javascript sounds promising on speed but it is like everything using javascript: amazing babel, webpack.. library which is 1 function or few lines of code.. what i love about typescript is pretending to be OOP language where devs are screaming that JS is great because it is not OOP but functional language so nothing is object, no interfaces, no rules..

tends to be my experience that normal people will learn and understand by trying, smart people will suspect/know you're right but will still want to experience a bit of it for themselves, and the rest are js devs.