I think about this a lot, as someone who loves Ruby and loves Rust. I think it’s because we do a bad job of looking at the total costs. It feels like you can knock something out really quickly in Ruby. And in some sense, you can! But the time you spend debugging later doesn’t get factored into the way that it feels when you’re just cranking out features.
Yes, and, just to keep this clear: that debugging (or unit-testing-for-typos) time is coming out of your prototyping budget. Your Ruby program will fail to run for stupid reasons the first time you run it, which is not the experience Java and Go and Rust programmers have. I just remember when I first picked up Go, after about 5 years writing Ruby exclusively, how amazing it was that all my Go programs "worked" the first time I ran them. Obviously, they had bugs. But they didn't blow up for stupid reasons.
I'd been a C/C++ programmer for about 10 years! I guess I just forgot that compilers can catch typos if you let them.
> Your Ruby program will fail to run for stupid reasons the first time you run it, which is not the experience Java and Go and Rust programmers have.
I know exactly the feeling, but I don't think it's just the types that give it but that it's compiled. I similarly moved on from ruby after 5 years but to Elixir and was similarly surprised to (re-) learn that a simple compile step catches so many braindead typos, misnamed variables, not imported function calls, and the like.
Types go above and beyond this, but I think there's a huge step up just going from interpreted to compiled.
I know a lot of people in the Ruby community tend to believe in using text editors with limited (or no) semantic understanding of the code. I've found that using, for instance, JetBrains Rubymine tends to make typos and related bugs apparent as they happen. Not to mention providing autocomplete that usually feels like using a statically typed language.
New to Ruby, veteran Java/C++, while I'm liking what RubyMine adds, it's nowhere near what I get from a simple language with a simple type system like Java.
I think this is a Ruby thing more than a dynamic languages thing. (Not exclusively a Ruby thing mind; Javascript code is also always full of weird edge cases and gotchas.)
I wouldn’t necessarily recommend it, but I have written 500-line Python programs without executing/testing any functions along the way, that “just worked” the first time I ran them with no serious bugs. And not because I am especially clever or have an amazing memory or unusual attention to detail, but just because the code is easy to make clear and straightforward.
(But this was just with basic data types and a few standard library modules; dealing with other people’s poorly documented / confusing APIs makes this gets a lot harder.)
You never had a go program fail to compile, only to fix the problem then try to compile again? Replace 'run' with 'compile' and you could still type a bunch of go code and have to make changes before you deploy or no?
Tooling makes this argument moot. I use Ruby and TypeScript, both with VSCode. The experiences are vastly different. Ruby is slow and difficult to work with, and TypeScript is a breeze. I don’t have to wait for my TypeScript to compile before it tells me about the typo I have, the editor tells me immediately after typing the word.
It's odd to complain about the first run not working, when the first run is significantly earlier. I'd also say the interactivity of Pry and binding.pry more than compensates for anything lost by not having a compilation step.
100% going from Java+IntelliJ to Ruby+VSCode was shocking. In regards to tooling, the developer experience is way behind with Ruby. Sure there’s a lot more boilerplate to look at, but with tolls you don’t actually end up writing much. And then you get refactoring tools that are actually super useful and robust.
Prototyping in Java is as fast as prototyping in Ruby once you understand how to use the tools equivalent to Pry in Java, and standard types instead of rolling your own types. JIT isso fast today the 20ms required to JIT what you type is immaterial.
Not strictly Java, but Groovy is a great environment to prototype on the JVM. Prototyping was lightning fast and turning it into Java code was pretty quick too. There’s great IDE support for it too (IntelliJ’s Groovy scratches).
These days Kotlin is also pretty good. Perhaps not quite as fast to prototype but there’s little need for converting afterwards.
Yes, add an environment like BeakerX [1] (essentially, Jupyter notebooks) and it's quite amazingly good to figure out your approach even if you intend to write Java.
I inherited legacy Python projects at work and I'm shocked by the time I'm wasting fighting with the lack of types. Most of the time I have no idea (and my IDE neither) what methods and properties are available on variables and function parameters. And what's the most insane to me: I'm sitting next to people with LOT of experience in Python and I see them losing as much time as me when maintaining and debugging some basic piece of code they have written not even 2 weeks ago.
> Most of the time I have no idea (and my IDE neither) what methods and properties are available on variables and function parameters.
If I am really this lost with a piece of code in Python or Ruby, I usually start an integration test with an added line to call the debugger.
With introspection you can then easily see what methods a given object has.
> And what's the most insane to me: I'm sitting next to people with LOT of experience in Python and I see them losing as much time as me when maintaining and debugging some basic piece of code they have written not even 2 weeks ago.
That is insane. What kind of code coverage do you have and what kind of tests?
It is true that you have to write more tests in a dynamic language than in a static typed language but as tests often convey the information of what was intended to be done much better than code, I don't consider this a drawback.
But if the tests are lacking, you are at a much greater loss than with static typed languages.
> With introspection you can then easily see what methods a given object has.
With VS and C#, I can hit ctrl+space and get a list of absolutely everything that's in the contextually relevant public API. So much faster than introspection. If I'm using an object initializer to instantiate something, I can hit ctrl+space inside the object initializer to get a list of all the available public properties -- no typing the names required. No having to remember the order of arguments of methods, or even their types. Autocomplete means I can usually get away with somewhere between zero and three keypresses to get exactly what I want highlighted in the intellisense.
Forget efficiency via vim/emacs keybindings. Static typing + a strong intellisense/intellisense clone lets me code literally at the speed of my thoughts most of the time. I end up feeling like I'm stuck in molasses the few times I have to write some JS.
> It is true that you have to write more tests in a dynamic language than in a static typed language but as tests often convey the information of what was intended to be done much better than code, I don't consider this a drawback.
I understand your point, but for me, the extra tests I write in dynamic langs just end up making me feel like I've duplicated the work of the static checker in other languages, and in a non-reusable way.
I am a ruby developer who tried rust. I don't think its the language thats the issue, its the libraries and tooling. I tried rust with rocket and I spent a week trying to get the rust app to connect to postgres because of having to deal with so many things like connection pools and setting up the ORM. I eventually just gave up and used rails where you just tell it the username and password for your database and you are pretty much good to go.
This is an advantage depending on the projects and organisation.
For instance if features need to be demonstrated or prototyped on a test env. for some time before they are green lighted to be fully baked, loosely typed languages are ideal. You get the speed of prototyping, and all the heavy cost comes after the main parts have been validated.
It's less painful than having to do prototypes after prototypes in a more rigid language.
But of course this advantage disappears when working more in small waterfall iterations, where everything is basically set in stone from the start.
