Stripe is building a Ruby typechecker • Hacker News Board

Re: Stripe is building a Ruby typechecker

#51

Post by transfire » Mon, Jun 04, 2018, 2:51 AM UTC

ptarjan wrote: post #49

taf2 wrote: post #31

This looks really nice... i wish it was just part of the language to be able to write ruby with type information e.g. instead of having a separate more verbose sig method that's called before each method signature... ``` class Foo extend T::Helpers sig( # Both positional and named parameters are referred to by name. # You must declare all parameters (and the return value below). foobar: Integer, widget: String ) .ret…

(one of the authors here) We'd love that too! We're chatting with the Ruby folks to see if anything like that is feasible. We experimented with lots of other syntaxes (comments, yarddoc, .rbi files, monkey-patching stdlib classes to be callable) and the `sig` syntax seems to be the easiest for folks to use inside Stripe. After writing sigs for the past few months, I don't dislike it as much as I thought I would. You…

Tomdoc?

Re: Stripe is building a Ruby typechecker

#52

Post by ptarjan » Mon, Jun 04, 2018, 2:56 AM UTC

mslate wrote: post #14

Is this analogous to mypy?

It is a similar idea, yes.

Re: Stripe is building a Ruby typechecker

#53

Post by sankha93 » Mon, Jun 04, 2018, 3:11 AM UTC

Any reason why existing typecheckers for Ruby didn't make the cut? There are projects like RDL [1] which provide similar functionality. I know for certain that people from Stripe were taking a look at it last year from the issues they had raised.

Disclosure: I am a grad student, recently started working on RDL.

[1]: https://github.com/plum-umd/rdl

Re: Stripe is building a Ruby typechecker

#54

Post by freedomben » Mon, Jun 04, 2018, 3:38 AM UTC

masukomi wrote: post #39

parvenu74 wrote: post #13

Earlier quoted context omitted.

Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project -- just lacking type definition? If Crystal can do that then I think adoption of Crystal would benefit greatly.

As @chrisseaton said, no, BUT some ruby is valid Crystal. I think it would be more accurate to say that a subset of Crystal is valid Ruby, and a subset of Ruby is valid Crystal.

That's correct. You can run your Crystal programs with the Ruby interpreter, but you can't compile your Ruby to Crystal (simple scripts usually work, but bigger things that use use gems probably won't).

Re: Stripe is building a Ruby typechecker

#55

Post by vinceguidry » Mon, Jun 04, 2018, 3:46 AM UTC

exabrial wrote: post #40

Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?

Crystal is a completely different language with a different architecture and object model that only superficially looks like Ruby. Porting code from Ruby to Crystal is somewhat easier than, say, porting the same code to Python, but is still an act of porting. You can't use any kind of automated drop-in process to rewrite Ruby code to Crystal. They're just too different.

A good type system for Ruby is very much needed. Matz himself has stated that a type system is very much on the horizon for Ruby. Can't wait.

Re: Stripe is building a Ruby typechecker

#56

Post by freedomben » Mon, Jun 04, 2018, 3:48 AM UTC

iamleppert wrote: post #17

People created dynamic languages for the exact reason of not having to define types. Now the trend is to bolt on type checking to dynamic languages because people don’t want dynamic behavior. Most developers I’ve encountered who seek to add types to dynamic languages will never truly understand dynamic languages, closures, concurrency passing or functional programming for that matter. If you want a statically typed l…

I'm not sure how well you understand functional programming either if you think it needs dynamic typing. The king of functional programming languages (Haskell) is statically typed.

Re: Stripe is building a Ruby typechecker

#57

Post by hendzen » Mon, Jun 04, 2018, 4:15 AM UTC

sankha93 wrote: post #53

Any reason why existing typecheckers for Ruby didn't make the cut? There are projects like RDL [1] which provide similar functionality. I know for certain that people from Stripe were taking a look at it last year from the issues they had raised. Disclosure: I am a grad student, recently started working on RDL. [1]: https://github.com/plum-umd/rdl

I'm sure they will come up with some plausible reason like the project having incompatible goals, or embracing a different design architecture than the one they wanted.

Truthfully, these 'prestige' projects are done for reasons other than actually improving the development standards. They probably didn't use RDL because it was more fun to write their own then figure out someone else's thing.

For all we know they may not have even had a real need for a new typechecker. Stripe could have a valued engineer who seemed bored so engineering management gave him or her an intellectualy interesting project to do - even if it wasn't that important to the business.

Re: Stripe is building a Ruby typechecker

#58

Post by jashmatthews » Mon, Jun 04, 2018, 4:19 AM UTC

masukomi wrote: post #9

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/

It’s not just compiled Ruby, but a completely different language with a superficially similar syntax. You can’t really port anything.

Re: Stripe is building a Ruby typechecker

#59

Post by djur » Mon, Jun 04, 2018, 4:26 AM UTC

freedomben wrote: post #54

masukomi wrote: post #39

Earlier quoted context omitted.

As @chrisseaton said, no, BUT some ruby is valid Crystal. I think it would be more accurate to say that a subset of Crystal is valid Ruby, and a subset of Ruby is valid Crystal.

That's correct. You can run your Crystal programs with the Ruby interpreter, but you can't compile your Ruby to Crystal (simple scripts usually work, but bigger things that use use gems probably won't).

You can't run a lot of Crystal code in Ruby, either. They implement keyword arguments completely differently (Crystal does it more like Python, where all arguments can be specified by name or position) and of course Ruby doesn't support Crystal syntax relating to types. Crystal also has a tuple type with a literal syntax ({1, 2, 3}) that isn't valid Ruby. But otherwise it's fairly close.

Re: Stripe is building a Ruby typechecker

#60

Post by qop » Mon, Jun 04, 2018, 4:27 AM UTC

vinceguidry wrote: post #55

exabrial wrote: post #40

Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?

Crystal is a completely different language with a different architecture and object model that only superficially looks like Ruby. Porting code from Ruby to Crystal is somewhat easier than, say, porting the same code to Python, but is still an act of porting. You can't use any kind of automated drop-in process to rewrite Ruby code to Crystal. They're just too different. A good type system for Ruby is very much needed…

With Ruby getting an AST, and potentially a type system in the future, I think that ruby 3 could lend itself to bring transpiled to crystal relatively easily, depending on exactly how much type information there is, how difficult / possible it is to correlate that with the AST.

Scala 3 is doing the typed AST thing, so hell, why not?