10 ms·

Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's

Very cool! I didn't think this would happen, as Matz has expressed disinterest in adding type annotations. However, keeping an open mind and reconsidering one's positions are the hallmarks of a great leader :D I worked on a summer project to add type annotations to Ruby. Didn't get very far since I ran into some challenges with the internals of the parser and the parser library, Ripper. I'm extremely interested in seeing how the Ruby team designs the type system. It'll be gradual, of course, but also it'll be interesting what adaptations they'll have to make to accommodate existing code. JavaScript relied on a lot of stringly typed code, so TypeScript added string literal types. Perhaps Ruby's dynamic, block oriented style could lead to some interesting decisions in the type system. Not to mention, the types will most likely be reified as per Ruby's philosophy. Super excited for this. Between the JIT and types, Ruby could definitely see a renaissance in the near future.

darkdimius 8y ago
Indeed Sorbet does have literal types for strings and Ruby symbols. We're still figuring out the details and converging on a common type system for Ruby3, but we've found them super useful, as you rightly point out! And +1 on the Ruby renaissance! Super excited about all the exciting things that are currently being built!
- _hardwaregeek 8y ago
  I can't wait for Sorbet's open sourcing! Ngl I tried decompiling the wasm binary just for fun. Not that it ended up being readable haha
  - darkdimius 8y ago
    We're currently looking for beta users! Reach out to us at sorbet@stripe.com. If you describe your team&codebase in the email, it will help us figure out what cohort to include you in.
baybal2 8y ago
What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?
- coldtea 8y ago
  The rationale is that types are there to check correctness (types as proofs), not to improve performance. Speed is not the first and foremost benefit of types. Type checking is (and other stuff that comes with that, like better completions, self-documenting code, etc).
- webgoat 8y ago
  Readability most likely. Type checking tends to also reduce basic bugs from mismatched inputs as well.
- nurettin 8y ago
  so that you can gradually add types? now that ruby has an actual jit compiler, it could benefit from typing to optimize code further. And a gradual migration process will help people speed up parts of their code. Unless they mess it up like python where abstractions are costly.
- z1mm32m4n 8y ago
  Who's to say we couldn't use the types to make the runtime faster in the future? One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code. If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actually be run. If the signatures lie, then any runtime optimization made using the types would only be overhead, because the runtime would have to abort the optimization and fall back to just running the interpreter. [1]: https://sorbet.org/docs/runtime https://sorbet.org/docs/runtime
  - baybal2 8y ago
    I programmed C back in my high school years 14+ years ago. Today I am mostly using JS because it is the cash crop of the industry, and it made me quite some money when I was away from electronics business (my main occupation) for a year after getting troubles with Canadian visas. To me, it feels that there is a very thick wall in between high level languages and something with raw data access like C, C++, and D. You either completely throw out every convenience feature, or go all in on them. In C, a lot of data access turns into single digit number of load/store or register access instructions. It is easy to see that it is close to impossible to add fancy data access functionality on top of that without going from single cycles to kilocycles. I was once told "when your try improving a programming language performance, it eventually turns into C" P.S. on JIT - it is not given that a JIT language be automatically faster than a well written interpreter on a modern CPU. One of early tricks of making fast interpreters was to keep as much of interpreter in cache and data in registers as possible to benefit from more or less linear execution flow of unoptimised code in comparison to unpredictable flow of JIT made executable code. Today, with 16MB caches, I think the benefit of that will be even bigger.
znpy 7y ago
I honestly think that more than Matz reconsidering his own opinions, it probably turned out that having types is an instrumental thing to enable performance improvements. Keep in mind, Ruby development is headed towards a goal that the dev team has called "3x3" as in Ruby 3 aims to be three times faster than current Ruby implementation.
- olah_1 7y ago
  >it probably turned out that having types is an instrumental thing to enable performance improvements. I was disappointed to find out that adding more types in Perl6 actually slows down performance. I wonder what the differences are that adding types in one language speeds it up, while adding types in another language slows it down.
  - viraptor 7y ago
    It depends what do the type annotations do. I'm not sure how perl6 does it, but for example in python type annotations are completely ignored at runtime, so don't have any impact. We'll see how much / for what does Ruby 3 actually want to use the type information. Sorbet on its own is unlikely to affect runtime either.
    - lizmat 7y ago
      Type checking is runtime, although if the static optimizer can figure out that a certain call will never work at compile time, it will throw a compile time error.
      - joesb 7y ago
        On the other hand, if the static optimizer can figure out that a certain call will always work at compile time, it can remove the runtime check for that part.
    - fjp 7y ago
      Going to keep praying for type/performance optimizations in Python so we can all get past the "python is slow" thing. Async python is an absolute joy to develop with.

darkdimius 8y ago

Indeed Sorbet does have literal types for strings and Ruby symbols. We're still figuring out the details and converging on a common type system for Ruby3, but we've found them super useful, as you rightly point out! And +1 on the Ruby renaissance! Super excited about all the exciting things that are currently being built!

_hardwaregeek 8y ago
I can't wait for Sorbet's open sourcing! Ngl I tried decompiling the wasm binary just for fun. Not that it ended up being readable haha
- darkdimius 8y ago
  We're currently looking for beta users! Reach out to us at sorbet@stripe.com. If you describe your team&codebase in the email, it will help us figure out what cohort to include you in.

baybal2 8y ago

What is the rationale of adding types to a language that will still retain all performance penalties from the need to have dynamic typing code to interact with non-typed data?

coldtea 8y ago
The rationale is that types are there to check correctness (types as proofs), not to improve performance. Speed is not the first and foremost benefit of types. Type checking is (and other stuff that comes with that, like better completions, self-documenting code, etc).
webgoat 8y ago
Readability most likely. Type checking tends to also reduce basic bugs from mismatched inputs as well.
nurettin 8y ago
so that you can gradually add types? now that ruby has an actual jit compiler, it could benefit from typing to optimize code further. And a gradual migration process will help people speed up parts of their code. Unless they mess it up like python where abstractions are costly.
z1mm32m4n 8y ago
Who's to say we couldn't use the types to make the runtime faster in the future? One of the reasons why Sorbet does both runtime checking[1] more than just static checking is so that we can know that signatures are accurate, even when a typed method is called from untyped code. If the signatures are accurate, a future project could take advantage of method's signatures to make decisions about how the code should actually be run. If the signatures lie, then any runtime optimization made using the types would only be overhead, because the runtime would have to abort the optimization and fall back to just running the interpreter. [1]: https://sorbet.org/docs/runtime https://sorbet.org/docs/runtime
- baybal2 8y ago
  I programmed C back in my high school years 14+ years ago. Today I am mostly using JS because it is the cash crop of the industry, and it made me quite some money when I was away from electronics business (my main occupation) for a year after getting troubles with Canadian visas. To me, it feels that there is a very thick wall in between high level languages and something with raw data access like C, C++, and D. You either completely throw out every convenience feature, or go all in on them. In C, a lot of data access turns into single digit number of load/store or register access instructions. It is easy to see that it is close to impossible to add fancy data access functionality on top of that without going from single cycles to kilocycles. I was once told "when your try improving a programming language performance, it eventually turns into C" P.S. on JIT - it is not given that a JIT language be automatically faster than a well written interpreter on a modern CPU. One of early tricks of making fast interpreters was to keep as much of interpreter in cache and data in registers as possible to benefit from more or less linear execution flow of unoptimised code in comparison to unpredictable flow of JIT made executable code. Today, with 16MB caches, I think the benefit of that will be even bigger.

znpy 7y ago

I honestly think that more than Matz reconsidering his own opinions, it probably turned out that having types is an instrumental thing to enable performance improvements. Keep in mind, Ruby development is headed towards a goal that the dev team has called "3x3" as in Ruby 3 aims to be three times faster than current Ruby implementation.

olah_1 7y ago
>it probably turned out that having types is an instrumental thing to enable performance improvements. I was disappointed to find out that adding more types in Perl6 actually slows down performance. I wonder what the differences are that adding types in one language speeds it up, while adding types in another language slows it down.
- viraptor 7y ago
  It depends what do the type annotations do. I'm not sure how perl6 does it, but for example in python type annotations are completely ignored at runtime, so don't have any impact. We'll see how much / for what does Ruby 3 actually want to use the type information. Sorbet on its own is unlikely to affect runtime either.
  - lizmat 7y ago
    Type checking is runtime, although if the static optimizer can figure out that a certain call will never work at compile time, it will throw a compile time error.
    - joesb 7y ago
      On the other hand, if the static optimizer can figure out that a certain call will always work at compile time, it can remove the runtime check for that part.
  - fjp 7y ago
    Going to keep praying for type/performance optimizations in Python so we can all get past the "python is slow" thing. Async python is an absolute joy to develop with.