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

61–70 of 187 posts

Re: Stripe is building a Ruby typechecker

#61

Post by vinceguidry »

qop wrote: post #60
vinceguidry wrote: post #55

Earlier quoted context omitted.

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?

Syntax is only the first obstacle. You also have the object model and the standard library to deal with as well.

Re: Stripe is building a Ruby typechecker

#62

Post by sanderjd »

Kalium wrote: post #42

"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.

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!

Re: Stripe is building a Ruby typechecker

#63

Post by Kalium »

sanderjd wrote: post #62
Kalium wrote: post #42

"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.

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 completely right that this is an ocean to boil, and it's rarely easy to guess the size of any given one. Yet it's possible that the naive intuition - when boiling oceans, prefer fewer - might be reliable in this case.

Re: Stripe is building a Ruby typechecker

#64

Post by griffinheart »

sandstrom wrote: post #3

Interesting! Anyone with insight into the ruby core team know if Ruby may add typing (optional or mandatory) in the future?

Was at the Kaigi and on the opening keynote Matz talked a bit about it. He doesn't really support adding it since he feels like in 20/30+ years, advances in technology will make writing types "obsolete".

Re: Stripe is building a Ruby typechecker

#65

Post by Kalium »

qop wrote: post #60
vinceguidry wrote: post #55

Earlier quoted context omitted.

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?

You're absolutely right! Any Turing-complete language can be transpiled to any other.

That said, you can't always expect sensible or human-brain-friendly results if you're moving between two languages that work very different.

Re: Stripe is building a Ruby typechecker

#66

Post by ninjakeyboard »

Is the idea that you would take your existing code and add typesafety to it? A statically typed language is faster because it does type checking at compile time and does not need to do "if string, ok else throw exception", so adding a bunch of type checking to a dynamic language adds the development overhead without the benefit. I suppose there is a false economy in that statement as defects caught early save time vs late defect discovery, which in my experience, is very common due to type issues in dynamically typed languages.

I personally prefer working with statically typed languages but I've been working with elixir for the last 8 months or so and do not feel very compelled by the use of dialyze (type checker) in the dynamically typed language - you get used to the idioms and try to keep the code type-y but it seems unidiomatic to take type safety too far in a dynamically typed language when you don't get the performance benefits. You cover the things you're likely to get wrong but embrace it for the sake of development speed otherwise. For a new project the right question to ask is "why would we use this instead of a statically typed language." I suppose for an existing project the question this is trying to solve is "how can we reduce bugs now that we've made it to market."

Re: Stripe is building a Ruby typechecker

#67

Post by mmartinson »

masukomi wrote: post #38
CGamesPlay wrote: post #10

Earlier quoted context omitted.

My 100k LOC code base is already written in ruby though. I have to rewrite everything?

yeah. that's a pretty compelling reason, but on the other hand, there's a lot of value to be had from modularizing your codebase and microservices so... you could do all future dev in a new language, and if you wanted, gradually convert your existing modules. Sadly, few places think far enough ahead to see the values of modularity (even ignoring language switching) and end up with giant monolithic codebases so langua…

While you have some good points, I'm not sure monolith and modularity are mutually exclusive. Some places I'm sure think some places think far ahead, and determine that the cost of microservices isn't worth the later benefit while they're trying to bootstrap a project.

Re: Stripe is building a Ruby typechecker

#68

Post by mmartinson »

matchbok wrote: post #27
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…

I've heard the "mentally model" argument a few times, and tbh I don't quite understand it. You have to model the object regardless, either with types or tons of extra checks to make sure that object has what you need. I've seen so much javascript code do exactly that because the methods had no idea what they were going to be given. The contract of static typing eases that load, I think.

Ya for sure. Without getting a debugger into the application code, it sometimes seems completely impossible to look at a piece of dynamic code you're not already familiar with and decide if it's going to work. I've found this especially tough during code reviews for new stuff that make heavy use of abstractions, even when the abstractions are good.

Re: Stripe is building a Ruby typechecker

#69

Post by exolymph »

hendzen wrote: post #57
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…

Sure, that's possible, but we don't really have enough information to say either way.

Re: Stripe is building a Ruby typechecker

#70

Post by emilsedgh »

sanderjd wrote: post #62
Kalium wrote: post #42

"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.

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!

This might be as hard, but it's not as risky as rewriting the whole thing.

This approach, at worst, will just fail.

Rewriting the whole thing can have real big consequences if not done carefully and takes a real long time to bear fruit.

Post reply on HN