This is super cool. I would expect the same support for Rails after Ruby 3 release
Types will be part of Ruby 3 stdlib source
61–70 of 216 posts
Re: Types will be part of Ruby 3 stdlib source
#62The trend of adding type annotations to dynamically typed languages is now unstoppable. I wonder if some more exotic features (eg. side effects handling, monads or dependent types) will ever become mainstream in the feature.
Re: Types will be part of Ruby 3 stdlib source
#63I understand why PHP started to add support for type annotations as the hype around type annotations (Dart, Flow and Typescript) still was quite strong a few years ago.
By now I think it is quite obvious that type annotations aren’t as helpful as initially expected and that a library approach seems more pragmatic and more powerful. See Clojure + Spec.
The thing is dynamically typed languages with type annotations tend to no longer feel like dynamically typed languages as the annotations and the tooling spreads and spreads and spreads. Not easy to put up boundaries.
Re: Types will be part of Ruby 3 stdlib source
#64Earlier quoted context omitted.
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?
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 actu…
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.
Re: Types will be part of Ruby 3 stdlib source
#65Earlier quoted context omitted.
I don’t know but I hate it. Not sure if I’m in the minority but it sure feels like it. In an ideal world. I feel that types are something that should be dealt with at the IDE level. In fact, there so many things that can be done at that level, but no one has really been brave enough to do so I suppose.
By IDE level, you mean compile level. Types are at compile level.
No, types can be at compile level. They can also be checked without compiling any time you like. Or automatically. By an IDE, for example.
Re: Types will be part of Ruby 3 stdlib source
#66My concern about all of this is that it might lead to basically two ruby communities; Rails and Rails devs will mostly keep writing type free code (dhh has always indicated he's not a fan of types), but a lot of other rubyists will gradually introduce types into their code. This could create two different ecosystems with different gems, best practices, blogs etc etc etc. We will see how it plays out but I'm quite con…
Yes it is optional until it gets hard to find a job with typeless Ruby. And indeed split Ruby communities just as with Javascript. The bad thing is that static typing in dynamic languages is HOT, which means if you don't move over to the typed camp you will look old and stupid.
Re: Types will be part of Ruby 3 stdlib source
#67I recommend whatching "Ruby3: What's Missing?", a presentation Matz gave earlier this month: https://www.youtube.com/watch?v=cmOt9HhszCI This might be misleading. That is, jump to around the 29 minute mark where he talks about the type profiler and .rbi file stuff.
As a user of Homebrew, I just wonder if Ruby's ever going to have performance.
Yes and no. You need to basically fork the compiler and invent a new type of ruby that sacrifices certain things in favor of performance.
Re: Types will be part of Ruby 3 stdlib source
#68Earlier quoted context omitted.
Hi thanks for this! Could you shed more light on the last part where they show parts of Rails, Gitlab etc are already typed? How is this possible?
Sorbet has multiple Strictness Levels[1]. The two most relevant ones are `typed: false` and `typed: true`. `typed: false` is the default level and at this level only errors related to constants are reported, like this one: https://sorbet.run/talks/RubyKaigi2019/#/14 But we'd like to catch more than just errors related to constants, like those related to missing methods, or calling a method with the wrong arguments. E…
Can you comment something about the possibility of Ruby getting faster because of Sorbet ?
Can it be combined with DragonRuby or other compilers that would produce more optimized Ruby programs?
Re: Types will be part of Ruby 3 stdlib source
#69Ah yes, a last ditch effort to claw back an inferior language into the popularity again. This is nothing more than a knee-jerk reaction to loss of market-share to TypeScript / Python / Name your other buzz-language here (R)
Re: Types will be part of Ruby 3 stdlib source
#70Why is everything moving to types?
Generally no one uses dynamic typing for the abilities it gives you. Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you? If not then why are you using a dynamically typed language? If you're not using it's abilities then it doesn't sound like the right tool for the jo…
> Do you declare string variables to later assign them to numbers? Do you dynamically add new functions and properties to objects? Do you ever really need the flexibility that dynamic typing is giving you?
Yes, yes, and no. I do most of my work in languages that prevent the first two, but when I do have access to this kind of runtime trickery I do use it when useful.