It looks like they've conflated type with class. If so, that's the antithesis of duck typing. The impedence mismatch to Ruby seems to me an overwhelming contraindication.
Care to explain the difference for the sake of the dimwitted such as myself?
Types will be part of Ruby 3 stdlib source
141–150 of 216 posts
Re: Types will be part of Ruby 3 stdlib source
#142All of these beneficial refinements are meaningless if increasing performance optimization in the runtime isn't made more of a priority.
Re: Types will be part of Ruby 3 stdlib source
#143Learning from the clojure.spec success story, what might make/break Sorbet is its runtime capabilities, aka reification.
* Can I emit typed REST API docs out of sorbet types?
* Can I coerce HTTP params out of sorbet types?
* Can I emit ActiveRecord columns? ActiveModel validations?
* Can I emit generative tests?
You can do all of those (and whatever else you imagine) with clojure.spec in a DRY manner, i.e. types are defined once, and reused in a variety of contexts.
As a Rails dev, I would greatly value all of those, particularly because they're practical things directly related to my webdev activity. Ensuring the type safety of the codebase is great, but also implicitly exercised by an adequate test suite.
Re: Types will be part of Ruby 3 stdlib source
#144Ruby already had types, no? This is about static typing.
My thought too. Interesting what the definition of "static" will turn out to be in the context of something so inherently dynamic as Ruby.
Re: Types will be part of Ruby 3 stdlib source
#145Fascinating to see the circle turn further back towards strong / static typing. One of the major things that has kept me using Groovy over the last 10 years was the reluctance to leave optional / gradual typing behind. Now, nearly every major dynamic language has given in and introduced types, so it seems like this idea of hybrid dynamic/typed languages is now fully mainstream. The problem of course, is they are all…
I get what you mean, but dynamic typing is a feature, just like static typing is. Some languages are better from a static POV, and offer some auto features. Some languages are better from a dynamic POV and offer some hinting feature. You don't want to type your code to do data exploration and analysis, but you may want to extend the original project later to something bigger and move on to types. There is no such thi…
> There is no such thing as the perfect language for everything anyway.
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).
Re: Types will be part of Ruby 3 stdlib source
#146Partnering with Ruby Core is a bit dubious for a project which is still closed source. Why the privacy? Are programmers too dumb to understand something is a beta? What if in the end adoption is marginal and Ruby Core's time was wasted? Best adoption is organic, not hyped up.
From the slides that are linked in the tweet in the tweet: https://sorbet.run/talks/RubyKaigi2019/#/45
Re: Types will be part of Ruby 3 stdlib source
#147Very 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 se…
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.
>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.
Re: Types will be part of Ruby 3 stdlib source
#148I 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 ten…
> I 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.
PHP started added type hinting (aka specifying types for function arguments) in 5.0.0, back in 2004. Dartlang didn't exist until 2011, TypeScript until 2012, and Flow (I assume you mean the FB tool) didn't exist until 2014, as best I can tell.
>By now I think it is quite obvious that type annotations aren’t as helpful as initially expected
My only take away from this is that you obviously haven't used PHP's type system.
Re: Types will be part of Ruby 3 stdlib source
#149Earlier quoted context omitted.
Well I am skeptical about performance improvements due to type annotations as well. Other languages have similar different systems and didn't get faster. Dart had gradual types but didn't enforce them at runtime because of performance. The PyPy devs don't believe that type annotations help them for performance ( http://doc.pypy.org/en/latest/faq.html#would-type-annotation... ). Also there is no JS engine that uses Ty…
Dart has long changed.
True, that's why I wrote "Dart had".
Re: Types will be part of Ruby 3 stdlib source
#150Earlier quoted context omitted.
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.
>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.
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.