Types will be part of Ruby 3 stdlib source

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).

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.

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

In certain basic blocks typed ints or floats can be unboxed, if they will not escape. This is what php7 made 2x faster. the stack will get much leaner. simple arithmetic ops can be inlined, using native variants. ops with typed vars cannot be overridden.

Quite a few large companies have found themselves in this situation: Very large codebases in a programming language without types stop being fast to develop in. Then you get to either rewrite everything, with the well documented risks, or start doing all kinds of other things to make programming safer, like banning certain parts of the language, until eventually dedicating a team to improve the language is the most cost effective way to go.

In this case, I am also pretty certain that the interaction with data started having informal types a while ago too.

What I find really interesting here is that what starts as a library to help a single company handle the subset of Ruby they were using in the first place now aims to be good enough for general purpose Ruby outside of said company. It's one thing to have problems with an experimental, home-made thing, and just get support via slack, but adding this to the language has a far higher barrier. This is also probably the reason it's not OSS yet: The code that is enough for production use in Stripe's approach to Ruby might not be the greatest in a random codebase with different opinions on how many dynamic methods you want to have.

So it's not that a team decides to add types to Ruby instead of just picking a language that already has the types: It's solving a private problem and, a while later, realize that accidentally the solution is very close to being good enough for the language.

Another feature of even optional types is creating uniformity to allow JIT optimization. A great real-world example of this is Typescript or ReasonML. It's converted to JS, but still winds up faster on average. The JS JITs have multiple tiers of optimization. Changing data types and function signatures are the biggest performance killers. If you can ensure a list is always strings or numbers, then the optimizer can reach the top tier of optimization. When lots of people work together on untyped languages, there tend to be small changes in the signatures and structures that drop you out of that top optimization level. Even partial types are useful for preventing this.

Related to that is the potential for runtime type warnings. Even though the types aren't used by the JIT, it should be possible to give a warning message if the received types don't match up. That could be a huge assistance in finding where a bug is located.

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.

People tend to forget this all to easily. For example most of the static type discussions for the past 10 years have taken place on a website built in a dynamic programming language, I'm talking about http://lambda-the-ultimate.org/ which afaik is built in Drupal (i.e. PHP).

I also feel that CL and Racket have embraced types a lot more. Doesn't CL have a fair bit of static typing already? And with Racket, Typed Racket has pretty much pioneered the concept of gradual typing now being applied to JS, Python and Ruby.

I know Racket also explored contracts, and has a lot of great ideas. But I feel overall it's missing the: "and we dog food it all on real business use cases in production" aspect that Clojure has.

And for CL, it doesn't seem to have as much in terms of contracts, data DSLs, immutability, simpler primitives, etc. It feels more like a traditional mutable, OOP, dynamic language. It has nailed down the interactive development part though. I don't want to put it down as I'm interested to try more of CL, but overall, it just doesn't seem as active or opinionated anymore. If anything, CL seems to lack any form of opinion, and goes more for the: we just add all features of every other language. Which is a quality on its own, but not driving the discussions forward either.

Clojure seems to have double downed on dynamism and runtime construct, away from static types. It seems to have made the bet that better software (less defects, cheaper to maintain and extend, more targeted to the users needs) is better achieved through:

* Simpler primitives * Immutability * Interactive development * Higher level constructs * Data driven DSLs * Generative testing * Contract specifications * Data specifications

Which are all very good ideas, but they're non traditional compared to formal static type systems and proofs.

They're used to be more drive behind these in the past, Common Lisp and Eiffel embody a lot of these ideas, but miss on others. So Clojure is like a new take trying to fit in all these ideas of interactive, dynamic, safe languages together a new.

And I just find it interesting, because it is counter current. As others have pivoted back to static types, Clojure went all in on dynamism.

Time will be the true test, and I'm looking forward from the learnings in all directions.

Java 10 and 11 introduced real type inference, at least for local variables and function parameters.

I agree that most popular dynamic are quite terrible. But, honestly, I think the real problem is not the particular implementations, but the whole idea of dynamic typing. At first it did make sense, but now that compiler writers have figured out "cheap" and general type inference, I don't see the point anymore.

However, I use Python on a daily basis because I have no decent alternative for the libraries I use.

If it's not, why not leave these solutions in gems?

Btw, I don't think static typing alone is Ruby becoming all things to all people. In recent history, it's also aliasing `Enumerable#filter` to `Enumerable#select`, numbered block arguments, a shorthand special notation for `Object#method` -- it feels like a trend of "hey these other languages do this, we should too". I'm not convinced that's always the case.

also for some reason homebrew really likes to updates its index all the time (I think it got tamed in the newest version), but setting HOMEBREW_NO_AUTO_UPDATE to 1 helps a lot.

But I personally wouldn't hire someone who maintained that dynamic typing produced as good results and was reasonable for an even mid-sized project. They've either never had a long running project or they've never dealt with a big enough code base at that point, or they're simply being dishonest or lack self awareness. None of those are good signals. Not having worked on a project that goes on for long enough is fine, but having opinions on software maintenance in that case is foolish.

It was a design decision that all type annotation arguments be named as opposed to positional. As one example why, it makes the error messages better. You can always say "You're missing a type declaration for parameter 'foo'" as opposed to "You have four positional arguments and 3 types".

We could probably still bikeshed our annotations inside the `sig { ... }`. I'm not sure we'd make constants with unicode like BigMap‹Address→Account› for generics, though, how do you even type that? :)

   sig {params(new_value: T.nilable(Integer)).void}

   sig Integer?                  # or
   sig [Option.of(Integer)]=>[]  # longest form in sruby
   sig [Integer?]=>[]            # same as Integer?

I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

Depending on your type system, a well-typed program can eg run faster, because the compiler / interpreter can elide certain runtime safety checks that would be necessary in untyped code.

If your type system is crazy enough, you can even track the runtime complexity of your program at the type level, including whether your program runs in finite time. See eg Dhall (https://dhall-lang.org/) whose type systems only allows programs running in finite time.

But honestly, if you're asking your IDE to do it, that means you're asking your IDE to do static analysis of your code - and type-checking in a lot of ways is just another static analysis technique. And for a lot of us (myself included) we prefer to catch as many of these bugs as possible using static analysis, instead of waiting for someone to get paged when it causes an outage.

Yes, there's a trade-off, and types can be obnoxious (Java imports being probably one of the worst offenders, C++11 introduced `auto` for a reason), but that's the cost we pay.

So, please, be brave and evaluate a 100kloc codebase+deps that may contain a top level `rm -rf ~/`

Now the JS fanboys discovered and moved (from Coffeescript to Babel ESxx) to Typescript they apparently think that they can write beautiful and bugfree software just because of static type checking! Let them please move to C++ or whatever statically typed language and shoot themselves in the foot by making all those mistakes that have nothing to do with static type checking at all! Oh, and of course hitting the wall because they are missing their precious 'any' keyword!

I totally agree that type checking for dynamic languages should be done in the IDE, tooling. But static typing in the dynamic language world is a hype at the moment, so we'll have to go through a wave static type checking frenzy. For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint..

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.

The issue is not "Do you purposefully do those things?", but rather "Do you have a call stack where you can't guarantee it won't happen by accident?" Type checking is not relevant when you know what will happen and want the dynamic/ducktyping behaviour.

Another issue is: I'd use a different framework which doesn't use Ruby, but this was the most productive framework at the time the codebase was started, and nobody will port that many lines of code to a non-dynamic language now. So the best course of action is to validate the current code is not overly-dynamic.

One buys into eco-systems, not language features bullet point list.

And there isn't something like an universal eco-system for any kind of business case, hence multiple languages.

In a duck-typed language, type is defined by the willingness of a message receiver to receive that message. Class, inheritance, composition are all means to achieve this, but the type of an object is determined by its signature, not its ancestor chain.