←back to thread

511 points mootrichard | 1 comments | | HN request time: 0s | source
Show context
azinman2 ◴[] No.23990204[source]
Interesting. I’m surprised they didn’t opt to do this inline with the rest of the ruby code, because now they can diverge from each other. It’s a bit like a separate header file in C/C++/Obj-C, except in those cases the compiler will yell at you if the implementation doesn’t match the header. Having it blow up at runtime instead doesn’t feel like such a big change from the way it is now, other than helping out IDEs.
replies(2): >>23990400 #>>23990613 #
CarelessExpert ◴[] No.23990400[source]
> I’m surprised they didn’t opt to do this inline with the rest of the ruby code,

As they mention in the post, they followed typescript's approach, here. The benefit is it allows you to layer in typing into an existing codebase in a non-disruptive way.

replies(3): >>23990514 #>>23991134 #>>23994235 #
azinman2 ◴[] No.23990514[source]
But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.
replies(3): >>23990675 #>>23991579 #>>23994964 #
ativzzz ◴[] No.23990675[source]
Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.
replies(3): >>23990888 #>>23991368 #>>23993618 #
1. mekster ◴[] No.23991368[source]
So, why would a company with different use case than average ruby users implement stuff in the core to confuse many ruby users?