| > 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. |
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.