Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe is building a Ruby typechecker

medium.com

Post reply on HN
Print view View original

181–187 of 187 posts

Re: Stripe is building a Ruby typechecker

#181

Post by hderms »

jrs95 wrote: post #36
mping wrote: post #15

Earlier quoted context omitted.

It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases t…

At this point I don’t think anyone sane is seriously advocating for the adoption of Scala.

What alternatives are there to what Scala provides? What newer language would a 'sane' person advocate?

Re: Stripe is building a Ruby typechecker

#182

Post by qop »

Willamin wrote: post #136
qop wrote: post #50

I think the most fascinating thing that Ruby 3 could approach is an approach similar to Dart 1's optional types. That way a fast unchecked mode could be available for developing, and REPL usage, and then a separate switch could be flicked for building a release. Seeing the Ruby devs take compatibility so seriously is such a confidence builder for me, either way. Ruby is such a joy to program in, and for certain proje…

A lot of people that love Ruby and dislike Crystal seem to dislike Crystal for reasons like what you mentioned. I'm pretty sure that you can get a sorted list of methods in Crystal (not with the same syntax unfortunately) at compile time in macros. I'm not sure why you would ever want to dynamically get a sorted list of methods at runtime... unless you're adding methods at runtime.

I use it in the repl for classes I'm not familiar with. I use Ruby for duct taping a lot.

Re: Stripe is building a Ruby typechecker

#183

Post by chrisseaton »

sankha93 wrote: post #171
chrisseaton wrote: post #73

Earlier quoted context omitted.

What's the next step for RDL? It seems like Hummingbird is much more powerful than Sorbet, but it's hard to tell without them publishing a paper yet.

There are a bunch of interesting stuff coming along. I don't know if you have seen the Refinement types in Ruby paper based on RDL recently published in VMCAI [1], this opens the window to verification of Ruby code. [1]: https://arxiv.org/abs/1711.09281

Thanks I added that to rubybib.org - please encourage your colleagues to create PRs when they publish papers so the whole community can find Ruby research more easily.

Re: Stripe is building a Ruby typechecker

#184

Post by jrs95 »

hderms wrote: post #181
jrs95 wrote: post #36

Earlier quoted context omitted.

At this point I don’t think anyone sane is seriously advocating for the adoption of Scala.

What alternatives are there to what Scala provides? What newer language would a 'sane' person advocate?

Unless you really need it for a platform like Spark where there aren't many other options, pretty much any other statically typed language is likely to be more productive in the long run, once you account for the costs of Scala's complexity. Java, Kotlin, C#, whatever. And if you don't need or want the benefits of statically typed languages, then the same is also true for most major dynamic languages. It's difficult to be more specific than that because I don't think there's a very compelling case to use Scala to begin with.

Re: Stripe is building a Ruby typechecker

#185

Post by rurban »

Kalium wrote: post #63
sanderjd wrote: post #62

Earlier quoted context omitted.

This seems like boiling oceans as well. It's hard to guess which oceans are bigger or harder to boil. Clearly Stripe thinks this is the easier way to go. That wouldn't have been my instinct. Maybe they made a really good estimate for how it will be though. I'd be very curious to see their full analysis!

You're absolutely right! Building probably was a lot like boiling an ocean. Grafting static typing onto a very dynamic language is a massive and complex undertaking. That said, it's one item that can be built greenfield. In some senses, that makes it easier to apply to other codebases once the tool is in a working state. It also means one thing to work on, rather than N, which is much easier to plan for. You're compl…

It's only massive if you are doing it wrong. All examples I found so far were doing it wrong. For cperl (perl5 with classes and types) I did it right instead. It took about half a year, with most parts improving the rest of the system and signatures. Ruby already has signatures, so thats out if the way. Python eg did it completely wrong, PHP is doing it right.

The goal is catch type violations with optionally declared types and constant literals, and help the compiler and optimizer to specialize ops on types, and do array and loop bounds checks, essentially moving runtime checks to compile-time checks. A good type checker should make overall code faster and safer, what you see out there are rudimentary and not scalable efforts to make it safer, but not faster.

It certainly looks like ocean boiling if you look at all the horribly bad efforts out there, comparable to pypy, unladen swallow, perl6, ... But if you look at proper type checkers and optimizers it's trivial, really.

Re: Stripe is building a Ruby typechecker

#186

Post by didibus »

klmr wrote: post #175
didibus wrote: post #161

Earlier quoted context omitted.

You'll have to justify this: "Prior studies were riddled with inadequacies in controlling for confounders and outright methodological errors." Your recent study is pay walled, so I can only go by the abstract, but it doesn't sound any more rigorous to me. I also find its comparing very different things. It says bugs in release, but it sounds like they consider commits to be releases, which would be very unfortunate.…

> You'll have to justify this: "Prior studies were riddled with inadequacies in controlling for confounders and outright methodological errors." That topic has filled whole blog posts. But in a nutshell, no previous study was able to compare directly the effect of typing disciplines due to confounders that they couldn’t control for in their experimental setup. For instance, virtually all previous studies compared dif…

> If done well, statically type checked Ruby could be an amazing language, with the added benefit of static typing at (as shown) virtually no cost.

I think this is where I feel the jump in causation to be too high. No one knows why Ruby and Clojure match up to Scala and Haskell. The prior study couldn't isolate the impact of a particular feature, but it did a pretty good job, at least similar to your study in finding overall defect rates.

Ruby with types, if we take your conclusion, should end up even outperforming Haskell by almost 10% in overall defect rates. That just doesn't sound believable to me.

I fear types are not independent variables. They affect other variables. And that's where I argue that they might in fact come at some cost which we still do not understand.

I still strongly feel they should have added types without knowing the bug. There's many ways to type data, those choices do matter. There's code that can't be typed precisely, or requires considerable efforts to type, there's even code that can not be typed at all, and must be rewritten differently to be typed.

Now I'm not going to argue JavaScript doesn't benefit immensely from static type checking. What I argue is that doesn't mean every language will see benefits from static types.

That said, I'm a big fan of gradient typing, especially when it can add runtime contracts over boundaries between typed and untyped. But, I'm not sure how successful they would be in Ruby. They've failed in Clojure, while no real analyses was performed, the community rolled back most adoption of it due to their impression of it not providing any value while adding extra effort. Obviously, the Clojure gradient typing system isn't as well maintained as Flow and TypeScript, so maybe that played a role.

Re: Stripe is building a Ruby typechecker

#187

Post by wtetzner »

markmark wrote: post #47
wtetzner wrote: post #43

Earlier quoted context omitted.

If that’s the case, then why not have the compiler check them as well?

Yes, that's exactly my point. Right them down in your program so that the compiler can check them rather than holding them in your head.

Sorry, I misunderstood your comment.
Post reply on HN