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

111–120 of 187 posts

Re: Stripe is building a Ruby typechecker

#111

Post by Kalium »

amelius wrote: post #108
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.

> boiling any number of oceans How many lines of code are we talking about here?

How many services do you think a big company like Stripe has? Let's be exceptionally conservative and assume fifty, with a minimum of a million LoC between them.

All of them need to keep working for the business to keep working.

Re: Stripe is building a Ruby typechecker

#112

Post by Kalium »

_pmf_ wrote: post #93
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.

> "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." Sometimes, if a baby is really, really ugly, it's OK to throw it out with the bathwater.

You're absolutely right! But just because it's OK doesn't make it pragmatic engineering or good project planning.

Re: Stripe is building a Ruby typechecker

#113

Post by Kalium »

vidarh wrote: post #75
Kalium wrote: post #63

Earlier quoted context omitted.

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…

Grafting a complete and safe static typing system onto a very dynamic language is a massive and complex one. But writing an advisory type checker (that just warns) with a specific code base as a starting point is a very different thing. Biggest question to me is if they support duck-typing. Secondly, if I was to do type checking for Ruby I'd start with parsing yard-style annotations, as a lot of libraries etc. come w…

You're right. An advisory system isn't incredible difficult or intimidatingly large and complex, and doing it for a small set of codebases is much easier than solving it as a general problem.

But uh, I didn't want to tell the commenter that they weren't thinking it through and were being utterly betrayed by their instincts. It's hard to get people to listen to that kind of thing. So I opted for telling them that they're right, implying that they have the opportunity to become more right, and reminding them of how right they are.

Re: Stripe is building a Ruby typechecker

#114

Post by edwinyzh »

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.

So it might (or not) be the best option for them at this point, but on the other hand, is it another case that shows a static-typed language is a better option for developing complex systems? IMHO, it is.

Re: Stripe is building a Ruby typechecker

#116

Post by emodendroket »

fouc wrote: post #84
klmr wrote: post #81

Earlier quoted context omitted.

> I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice e…

Ruby has the advantage of 'duck typing', due to its strong OOP foundations. Not quite sure what Python has that reduces the demand for static type declaration. I think part of the popularity of TypeScript could be down to a large proportion of javascript coders that have a background/preference for static typing. It could also be that certain classes of bugs are more prone to happen in JavaScript or it's harder to de…

JavaScript and Python also have "duck typing."

Re: Stripe is building a Ruby typechecker

#118

Post by emodendroket »

pmontra wrote: post #79
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.

I'm one of those people. I'm not sure I'd keep loving Ruby as much as I do now if the majority of Ruby developers end up using the type checker and I'll also have to. I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That was very welcome coming from C and Java in 2006. I prefer to lose time when I pass a type that I shouldn't have passed. It doesn't happen often (not every…

It's not just about preventing errors; it's also about making maintenance work much easier.

Re: Stripe is building a Ruby typechecker

#119

Post by ninkendo »

vidarh wrote: post #91
oelmekki wrote: post #88

Earlier quoted context omitted.

Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its interfaces (a type implements an interface if it implements its methods, so we can use interface as function parameter type). I don't get why we talk of duck typing about ruby : if I pass as parameter an object that does not quack like a duck, nothing will prev…

The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirem…

I wonder if this would be a good opportunity to use a typing system that's more like Go's, where you don't need to explicitly declare that a class implements an interface, but instead any class that has the right methods will implement the right interfaces automatically.

(In your example the method could be:

    def foo(source: Shiftable)
      dosomething(source.shift)
    end
where `Shiftable` is an interface that's something like

    iface Shiftable
      .shift(): T
    end
)

Re: Stripe is building a Ruby typechecker

#120

Post by Kalium »

edwinyzh wrote: post #114
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.

So it might (or not) be the best option for them at this point, but on the other hand, is it another case that shows a static-typed language is a better option for developing complex systems? IMHO, it is.

I think this shows that static typing becomes more desirable and a better investment as size and complexity of a codebase - and company - grow. This might not be the same as evidence that starting with static typing is preferable.
Post reply on HN