[sparker72678]

My preferred language (Ruby) happens to be dynamic, but at this point in my career (Staff-level) I've come to believe that the whole static vs. dynamic argument is way overblown.

90% of the issues that come up on the teams I've been a part of are caused by developers who are lacking architecture (and related) skills, regardless of the language we're working in. They struggle to find the core metaphors for the problem space they're working in, they struggle to name things, they struggle to find clear and effective refactor points, they struggle to consider the medium and long term implications of their decisions, they struggle to organize code well, etc.

(The other 10% of issues are constantly changing business requirements.)

Static vs. Dynamic has nothing to do with those problems — they all exist in both worlds.

Personally, my most recent stint with a statically typed language (Swift) was hella frustrating. I felt like I was fighting the type system all the time. (Several of my biggest complaints have been address since I moved on from Swift, to be fair). But some people just love it — and good for them!

For me, Ruby is the closest language to how my brain works. It has the least friction between Idea and Running Code. I hope to write in Ruby (or similar) for the rest of my life.

If I really want a static analyzer for my Ruby, I can try Sorbet. If I desperately need to be running a compiled binary for speed or flexibility, I'll have to choose something else. These are just the tradeoffs.

The world is a big place. I'd want everyone to be able to find a niche where you can write the code you want in the language(s) you want.

[tome]

> core metaphors for the problem space they're working in

> find clear and effective refactor points

> organize code well, etc.

> Static vs. Dynamic has nothing to do with those problems — they all exist in both worlds.

It's interesting because, having converted from Python to Haskell, I find a powerful static type system helps tremendously for those three things.

[r-s]

I am at a similar level / write a lot of Ruby. I have pretty mixed feelings. I do enjoy writing Ruby and echo the low friction between an idea and running code.

However, on very large Ruby projects I have inherited I do see a common flaw of a large (often insane) amount of exceptions being thrown due to type errors. Undefined method blah on nil class. Some of these apps have had 100s of developers working on them of various skill levels. For mission critical code paths I am often the biggest proponent of Sorbet.

While my personal projects involve heavy use of meta programming and taking advantage of duck typing, I have altered my writing style and opinions for large projects.

Part of my frustration with Ruby type system could be explained by the fact great Ruby developers are becoming pretty hard to come by and I have often had to work with developers who are picking it up.

[mountainriver]

Typing is also documentation. If you are documenting your code you’ll need to document the types for it to be useful so why not just type it and save yourself a whole bunch of runtime errors?

[nunez]

absolutely love ruby. beautiful language. so easy to write clean code with.

[pavelevst]

Thanks