Don't get me wrong. I'm happy to see type declaration support in Ruby and have sorely missed it working on long-lived Rails codebases. But it is pretty funny that after years of rah-rah about how static typing was a pointless barrier to productivity, all the "duck-typing" languages have eventually added it after all.
Where is Ruby Headed in 2021?
61–70 of 360 posts
Re: Where is Ruby Headed in 2021?
#62Earlier quoted context omitted.
Yeah, Sorbet and the progress being made in Ruby-land makes me want to go back and give it a good look. I really like Ruby. I just really like writing silly in/out tests less.
I just really like writing silly in/out tests less. Were you writing a bunch of tests to make sure that A is passing arguments of the right type to B? I'm not sure that's a great use of time. If A is passing the wrong thing to B, B will throw a `NoMethodError` anyway once it tries to do anything with the arguments, which will make the spec test fail anyway. But maybe I'm misunderstanding what you mean by "silly in/ou…
You can get away with that if you're writing something for immediate delivery, though I think it leads to a lot of not-my-problem thinking in teams that have to scale. On the other hand, I write a lot of libraries, both for internal and external consumption, and there are a lot of operations, in that context, where you won't get a `NoMethodError`--serialization, for example. You can happily serialize an integer if it's passed instead of a string. That doesn't mean it makes sense, or whatever is consuming it is going to be able to make heads or tails of it, and having to run code in order to know whether you've made trivial mistakes is shitty and demoralizing to an end user when they have to divine what a `NoMethodError` means when it's thrown deep inside of a library.
It can also then create security issues around untrusted input; you should be sanitizing at module boundaries any time something might be sensibly used with rando input, IMO, rather than relying on web developers who may or may not be competent enough to duplicate other consumers' effort to do it.
Having to do less work to enforce sanity at module boundaries, and having it tied in with the type system when you do have to do it, is a powerful force-multiplier. For example: I use `runtypes` to create validators in TypeScript when I must handle untrusted input and it's smart enough to take the validator I specify and create a type of the same shape for use at compile-time, so users who aren't dealing with untrusted input just have the nice computer cross the T's and dot the I's for them.
Re: Where is Ruby Headed in 2021?
#63Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).
Probably they got sick of having to read a function body (and maybe a couple levels of indirection from there) to figure out what the hell a method returns while doing maintenance programming on a hoary old Ruby codebase.
Re: Where is Ruby Headed in 2021?
#64Earlier quoted context omitted.
This is a set of statements that strike me as pretty unreflective of the state of things these days. I have slung a lot of Ruby in my life and I literally-not-figuratively stopped the second I laid my hands on TypeScript because we've hit the point where gradual static typing is both easily available and super easy to work with . (And there's also Rust, which can scratch a whole different set of itches that I don't h…
> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch…
When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage.
The argument has always been whether or not the price of that correctness is too high.
But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do.
At least with TypeScript in VSCode.
Re: Where is Ruby Headed in 2021?
#65Earlier quoted context omitted.
Ruby isn't forcing you to use static types. That being said, I actually think something like Sorbet makes even solo/small teams more productive because it trades some additional time writing boilerplate for dramatically reducing the number of bugs you write.
A good test suite is better at keeping the code bug free. Not needing types is another benefit of good testing. That's my experience, at least.
I think people remembering to test all the typing-related corner cases is never going to come close to being as effective as something enforced by static checking -- and even if it did, it seems like I've lost all the time I saved and then some, if that's the price of not having to write the declarations.
Re: Where is Ruby Headed in 2021?
#66Earlier quoted context omitted.
Do you think it's possible for well used types to displace the need for some tests?
I'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice." What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing? You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tri…
> I suppose it could be useful in cases where you'd stubbed out B in your specs, but ehhhh.
You're talking like that's rare and not something people constantly do when writing tests in Ruby.
Re: Where is Ruby Headed in 2021?
#67Earlier quoted context omitted.
Ruby isn't forcing you to use static types. That being said, I actually think something like Sorbet makes even solo/small teams more productive because it trades some additional time writing boilerplate for dramatically reducing the number of bugs you write.
dramatically reducing the number of bugs you write. I would say that's a big overstatement.
Have you tried writing a Ruby app with Sorbet vs without? I have, within the last year, and that's been my experience.
Re: Where is Ruby Headed in 2021?
#68Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).
Java 11+ supports declaring variables with “var”...
Re: Where is Ruby Headed in 2021?
#69Don't get me wrong. I'm happy to see type declaration support in Ruby and have sorely missed it working on long-lived Rails codebases. But it is pretty funny that after years of rah-rah about how static typing was a pointless barrier to productivity, all the "duck-typing" languages have eventually added it after all.
I think it's less funny and more an endorsement of how good tooling has gotten over the last few years. Intellisense et al. have changed the game so that you can actually be more productive from the start with statically typed languages because the inference (and UX/DX to utilize those inferences) is so much better than with dynamic/duck typing.
Re: Where is Ruby Headed in 2021?
#70Earlier quoted context omitted.
> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch…
It’s not that they’re fashionable, it’s that their ergonomics have improved significantly over the past decade. I saw dynamic types as a response to cumbersome static type systems, but increasingly type systems are becoming more expressive and less cumbersome.
Yeah, this is how I see it, too. Sort of a gradual convergence.
On the static side, Java and especially C# are simply _better_ than they used to be. Type inference is great - I can just write var x = new List() rather than having to stupidly repeat the type e.g. List x = new List(). Add in generics, and lambdas, and about a dozen other things that have now become widespread, and it's really a different game than 10 years ago.
Coming the other way, I never expected to see Intellisense-like autocompletion for languages like Ruby or Python. It honestly feels magical. Refactoring has gotten much better to where I can pull methods up and down inheritance chains using PyCharm or other mainstream IDEs.
I actually think it's mobile that's pushed people back toward static. Swift, ObjC, Java, and Kotlin are all static and there's less emphasis on this "one language" idea that drove a lot of people toward trying to use the same language (JS/TS) for their React front-ends and node backends.