Types will be part of Ruby 3 stdlib source • Hacker News Board

Re: Types will be part of Ruby 3 stdlib source

#171

Post by Arubis » Fri, Apr 19, 2019, 3:05 PM UTC

znpy wrote: post #135

_hardwaregeek wrote: post #6

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

My recollection is that 3x3 is a goal to be 3x faster than Ruby 2.0–presumably many of those gains have already been realized, so best not to depend on tripling _current_ performance.

Re: Types will be part of Ruby 3 stdlib source

#172

Post by darkdimius » Fri, Apr 19, 2019, 3:19 PM UTC

hibikir wrote: post #155

baybal2 wrote: post #47

Earlier 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?

The story didn't start as 'add types to Ruby'. It starts from someone having a codebase in the hundreds of thousands of lines of Ruby, dedicated to financial software, and the costs that they had by trying to keep said codebase from costing a lot of money: In those situations, you can go as far as toevaluate how much each bug deployed to production cost you. Quite a few large companies have found themselves in this s…

A lot of great insight in this comment.

The only difference is that Stipe has foresaw the problems and has been working on productivity for quite a while, with a dedicated group of people who help our engineers by building tools and abstractions. For example https://youtu.be/lKMOETQAdzs is done by the same org couple of years ago.

Re: Types will be part of Ruby 3 stdlib source

#173

Post by DCoder » Fri, Apr 19, 2019, 3:50 PM UTC

black-alert wrote: post #127

DCoder wrote: post #98

Earlier quoted context omitted.

I started using TypeScript back when it was 0.8, before it even had generics. Does that make me a fanboy? I have a project with about 45k SLOC of TypeScript (using Knockout.js for presentation). There is really no way I would maintain that same project without types. > For my work I look at horrible code bases, perfectly typed and strictly formatted by tslint. There is no language that can stop people from producing…

> There is really no way I would maintain that same project without types. That's bold. Do you think no developer would be able to manage it without TS? In that case you must be a fanboy! And honestly, are you not using 'any'? And do you think your app cannot crash because of a type error at runtime? And do you trust all the third party libraries you are using that they always provide you with consistent types, also…

I'm sure some developers would manage such a project without TS. Good for them. I wouldn't maintain it that way because:

1. I don't have the mental capacity to keep every single function's argument/return shape in my head, or to manually check it every time I make a change. Unit tests can't deliver 100% code coverage in practice.

2. Nor do I want to perform refactorings with stone age tools like s/setFoo/setBar/g. Setting up type information lets my IDE understand which calls to .push() deal with a native Array and which ones deal with my own class, so it can rename the latter ones when I ask. I can also use tools like "Find References" and avoid false positives.

3. I'm not a one-man-band. My coworkers need to deal with this project too, and new developers need to be introduced to it from time to time, and types serve as documentation and guard rails for them much better than jsdoc or regular comments. (This also serves as a significant barrier against using anything more esoteric like Elm, because nobody around would be familiar with it. TypeScript adds just enough syntax on top of regular JS to keep JS users comfortable.)

---

I do use `any` (and `unknown`), I have no doubts that an edge case can crash my app because I didn't validate something, and I never expect third-party code to work flawlessly whether it has types or not. Rejecting TS completely because "but run time loopholes" is throwing the baby out with the bathwater (or to put it in a more hyperbolic way, being an anti-vaxxer because vaccines are not 100% safe from side-effects). TS and types are an additional safety net/force multiplier†, not a silver bullet. (That said, what is a silver bullet? Because I'd sure like one.)

---

† Only applies to a project that has passed its initial rapid prototyping phase. During wild prototyping rides, types can indeed slow you down. But that's really the same debate as RDBMS vs NoSQL.

Re: Types will be part of Ruby 3 stdlib source

#174

Post by simplify » Fri, Apr 19, 2019, 3:53 PM UTC

techsin101 wrote: post #168

cageface wrote: post #89

Earlier quoted context omitted.

Types are massively helpful with JavaScript. I’ll never write untyped JS again if I can help it. Switching to typescript has done wonders for my productivity and code quality.

Tell me few .. to me types were useful for hinting in ide but vscode already gives good hints

Types are not just for autocompleting, but also for making illegal states unrepresentable[0].

For example, let's say you have Question model with two types: MultipleChoice and ShortAnswer. In TypeScript you can model it like this:

    type MultipleChoice = {
      mode: 'mc'
      body: string
      choices: string[]
      expectedAnswer: number
    }
    type ShortAnswer = {
      mode: 'sa'
      body: string
      exampleAnswer: string
    }

    type Question = MultipleChoice | ShortAnswer

TypeScript's compiler will then enforce data structure consistency across your entire codebase. For example, if you were rendering a question in React:

    type Props = {
      question: Question
    }
    const MyComponent = (props: Props) => {
      props.question.body // Ok, since all questions have a body
      props.question.choices // Type error, since only MC has choices

      if (props.question.mode === 'mc') {
        props.question.choices // Ok now, since we checked the mode of question
      }
    }

You can also use these types to force certain code to always be correct. For example, if you wanted to display a human-readable version of a Question's mode, you could write:

    const prettyQuestionType: Record = {
      mc: 'Multiple Choice',
      sa: 'Short Answer',
    }

and now TypeScript will force prettyQuestionType to contain keys for all modes. That includes when you add a new Question mode later.

Once you learn how to lean on the type checker, you think less about such details, and your mind becomes freer to think at a higher level, increasing your overall productivity. There is a learning curve though, so be aware.

[0] https://fsharpforfunandprofit.com/posts/designing-with-types...

Re: Types will be part of Ruby 3 stdlib source

#175

Post by didibus » Fri, Apr 19, 2019, 4:14 PM UTC

cutler wrote: post #102

didibus wrote: post #10

It's an interesting turn of event that Ruby, Python and JavaScript are all getting types. Meanwhile, I've gotten myself more and more into Clojure. Which now that other dynamic languages seems to move closer to types, seems to be in a niche in that Clojure is moving further away from types. It'll be interesting to see what happens at both extremes and in the happy middles.

>Clojure is moving further away from types What about clojure.spec?

I feel Spec is a part of that "move away from types" which I was talking about. It's an approach to software documentation, specification and verification that is at the other end of the spectrum from types.

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.

Re: Types will be part of Ruby 3 stdlib source

#176

Post by didibus » Fri, Apr 19, 2019, 4:26 PM UTC

xvilka wrote: post #31

didibus wrote: post #10

It's an interesting turn of event that Ruby, Python and JavaScript are all getting types. Meanwhile, I've gotten myself more and more into Clojure. Which now that other dynamic languages seems to move closer to types, seems to be in a niche in that Clojure is moving further away from types. It'll be interesting to see what happens at both extremes and in the happy middles.

Why not a standard Common Lisp istead? Or even Scheme/Racket?

Well, I'm not seeing as much activity on CL. But for me, it's mostly a practical reason. I can easily use Clojure or sprinkle some around in most enterprise context because it runs in a symbiosis with existing platforms like the JVM, the CLR, and the various Javascript VMs. So it's much more usable in my day to day.

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.

Re: Types will be part of Ruby 3 stdlib source

#177

Post by abhorrence » Fri, Apr 19, 2019, 4:29 PM UTC

bfung wrote: post #41

eru wrote: post #27

Earlier quoted context omitted.

I thought the ML family of languages showed that long ago? I guess TypeScript popularized the notion.

ML family has "type inference", which means the compiler figured out the type even if not explicitly written into the code. However, the language spec is still statically typed - an int will not turn into a string and vice versa (ex: "1"). Javascript and ruby, the underlying types can change depending on where the code is in execution - a variable holding a 1 can turn into a "1" and back (implicit type conversion - t…

> a variable holding a 1 can turn into a "1" and back

This is true of Javascript, but not of Ruby.

  irb(main):001:)> 3 * "3"
  TypeError: String can't be coerced into Fixnum

People commonly conflate dynamic typing with weak typing, Ruby has the former, but not the latter (with some explicit exceptions, e.g. to_ary and friends).

That's not to say you can't still end up with some interesting problems though -- if we just slightly change your example:

  a = 3
  b = 3
  # later...
  a = "oops"
  product = a * b
  # product is now "oopsoopsoops"

But this isn't due to automatic "weak types" style coercion -- just that Ruby lets you build a repeated string by multiplying a string by a number.

Re: Types will be part of Ruby 3 stdlib source

#178

Post by 59nadir » Fri, Apr 19, 2019, 4:34 PM UTC

black-alert wrote: post #66

joelbluminator wrote: post #33

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

If anything, dynamically typed languages (without special tooling) is for super smart people or people who are lying to themselves/others about the limitations of the human mind.

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.

Re: Types will be part of Ruby 3 stdlib source

#179

Post by jashmatthews » Fri, Apr 19, 2019, 4:47 PM UTC

nevertoolate wrote: post #123

joelbluminator wrote: post #74

Earlier quoted context omitted.

I think most rubyists do benefit from dynamic types. How easy would it be to build rspec and Rails in java? The whole dependency injection thing in Spring is in part a by product of types making it way harder to test things. That's just one example.

Can you give a concrete code example you are talking about? What is your problem with DI with spring? Why do you feel it is a problem with static type checker?

DI for testability adds complexity to code and reduces readability. In Ruby it's almost always unncessessary to use DI because in Ruby you can stub at runtime.

In other statically typed langues like Rust the type system itself eliminates the need for a lot of these tests but at the cost of mental overhead of expressing your logic in a way which will satisy the type system.

Re: Types will be part of Ruby 3 stdlib source

#180

Post by fjp » Fri, Apr 19, 2019, 4:53 PM UTC

viraptor wrote: post #150

olah_1 wrote: post #147

Earlier quoted context omitted.

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

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.