If you only work in small teams, or small projects, I could see this opinion getting formed and maybe agree.
But having worked on large projects... Types are fucking great. So much value exists in simply having a tool that highlights everywhere in the codebase my change impacts.
It makes refactoring at scale possible and expedient in a way that is simply better. Period.
I can be fearless changing things, because I don't have to wonder about all the places my change might have broken - it literally gives me the exact set of files and lines I need to go fix. I don't even have to rely on tests.
It's... Better. It's better even for my personal projects, and it's unimaginably better for my 300 engineer org.
What I don't understand is why, with the myriad of Java-like languages out there (types and all), corporate types still want to Java-ify languages like Ruby... Like, just use Java, Go, Typescript, etc...
It's nice that there's still a language and framework that optimizes for solo devs/small teams and startups.
> It's better even for my personal projects
Does your personal project make money and/or need to be launched quickly? I've also got personal projects in statically typed languages (been playing around a lot with Odin/Vulkan) but those have no due date or expectations. Also declaring types only prevents a very small amount of bugs. And it's not like Ruby doesn't have linters, tests and other tools. Direct feedback from the REPL also makes it easier to write correct code.
Better is also a meaningless word when it comes to software. Does better mean you can ship faster? Or that it's more performant? Unfortunately no language has given us the productivity of a dynamic language with compiled language performance, so everything is a tradeoff...
Corporations don't just blip into existence overnight. Startups use a prototyping language fixing the problems and then suddenly you realize you need types and rewriting is a waste of time, money, and a risk to the business.
> Does your personal project make money and/or need to be launched quickly?
This makes it clear that you understand why the language would be chosen in the first place, so not sure why it's not clear that eventually requirements change and you need a way to iteratively improve things while still shipping things.
> so not sure why it's not clear that eventually requirements change and you need a way to iteratively improve things while still shipping things.
I've said this a bunch of times in this thread, so here goes again: when I'm at the point where my app is somewhat mature, instead of adding types to it that don't really do anything, I'd rather rewrite parts in a compiled language where the tradeoff actually buys you more performance. Say, Rust, Go or C++.
I started off in data science/stats/econ, where you'd write programs in R then when you hit a bottleneck, rewrite in Fortran or C++. I like that strategy with Ruby too.
I've tried Typescript, it's simply too annoying versus ES6 (which is actually very pleasant). If I were to pick a JS-adjacent language, it would probably be Haxe, because at least the server end could be compiled to native code and sped up (also I wrote small games in it way back). Plus Haxe is actually nice.
My current favourite language is actually Odin, but I know I'm not writing a web app in it. Not when Ruby/Rails gives so much for free and is so productive (thanks to a bunch of "magic" made possible by Ruby's dynamic nature).
I don't disagree with the idea that types languages are nice, I disagree with the idea that bolting a type checker onto a dynamic language is a worthwhile improvement when you already have so many other tools to prevent bugs.
Rewriting hundreds of thousands of lines of code just isn't really feasible honestly. Maybe you just mean the actually bottle neck can use C bindings or whatever. Or, maybe you can migrate some microservices and hope it goes smoothly. But, typing does more than performance.
It basically helps a ton of engineers work together efficiently which honestly is bigger than the compute cuz you can always throw more compute at all problem these days anyway.
I don't think typing is necessarily to prevent bugs either. It's to reduce the cognitive load of writing code. Others mention that intellisense and LLMs work better with types. Types do a lot more than catching a runtime error of a method not existing.
I am curious about Odin, I'm mostly a go dev so getting something without the GC and go schedule that writes similarly is really interesting to me.
> curious about Odin, I'm mostly a go dev so getting something without the GC and go schedule that writes similarly is really interesting to me.
It's very pleasant. Reminds me a lot of Pascal, but modern and even nicer to write. There's some Go inspiration
but I'd say it's more like Pascal than Go. More full featured than Pascal or C, simpler than C++ or Rust. C bindings are super easy to use. Has array maths, Fortran style... I use it whenever I have an excuse to (not often enough). Super fun, just missing a large ecosystem (but it's also got bindings to enough stuff for a young language).
Perhaps Devil's advocate, but my rebuttal would be that we're not necessarily comparing similar gains to correctness as to optimisation, and that perhaps the correctness gains can be better attained another way where the optimisation gains cannot.
(Personally I find a type checker tremendously valuable for communicating with myself - and my team, I suppose - about assumptions being made in other parts of the program, which can probably be accounted "correctness".)
Also what's good for enterprise isn't good for everyone.
I get that orgs probably like TS so that newbie devs don't do crazy things in the code, and for more editor hand-holding. But it's not valuable for everyone, if it was actually better than everyone would be using it, not just some people.
I'm a professional developer with 20 years of experience and I wouldn't dream of starting a new side project—even with myself as the only developer—without types.
I've learned by hard experience that past me was an idiot and future me is clueless. Types are executable documentation that I can leave behind for future me so that future me can get instantaneous feedback while refactoring the project that past me wrote.
Any reason you stick to ruby? Why not use any statically typed language which offers this feature out of the box? We don't argue against typing. We argue about typing like it is done in ruby rbs/sorbet.
This is just a rehash of the discussions people were having about Smalltalk/Lisp 20 years ago... All the Java/C++ IDE people who were wondering how people survived without those tools, forgetting that Smalltalk/Lisp have live-coding, REPLs, and their own tools. Ruby is the same, the terseness + REPL/live-coding makes it easy to be productive and write bug-free code.
I know I'm far, far more productive in Ruby versus, say, C++ or Odin (my newest hobby language).
