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

121–130 of 187 posts

Re: Stripe is building a Ruby typechecker

#121

Post by emodendroket »

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…

> A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby.

It probably won't be idiomatic (maybe just add interfaces?) but I think duck-typing is overrated anyway. Just because an object responds to a method doesn't mean it's going to do anything like what you expect. To take a contrived example, Array.Shift and Keyboard.Shift are probably unrelated methods.

Re: Stripe is building a Ruby typechecker

#122

Post by gmaster1440 »

Kalium wrote: post #120
edwinyzh wrote: post #114

Earlier quoted context omitted.

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.

To your earlier point, larger systems are harder to migrate. This suggests that starting off with an investment in static type systems is more tenable as a long-term strategy.

Re: Stripe is building a Ruby typechecker

#123

Post by emodendroket »

pg_bot wrote: post #87
Tehnix wrote: post #24

Earlier quoted context omitted.

What languages have you worked with before, with static types? If it's something like Java, C, C++, etc, then I can see your point, but if you pick any of the languages with type inference (like Elm, Haskell, PureScript, OCaml, F#, etc), then you rarely actually have to write types. Working with the type system is a different way of working. It's more beneficial to see the compiler as a helping friend, instead of an…

The languages that I've used with static typing are Java and Objective-C so perhaps those languages have negatively impacted my perception of type systems. I can do more research on other languages to see what they have to offer. I used to run into type errors when I first started programming but I've learned how to eliminate them by changing my programming style. I add a lot of constraints to how I program, and foll…

> I add a lot of constraints to how I program, and follow a system of naming conventions that make it obvious what type something is.

And you find it unbelievable that someone would prefer that the compiler simply enforce these conventions?

Re: Stripe is building a Ruby typechecker

#124

Post by qop »

chrisseaton wrote: post #74
qop wrote: post #60

Earlier quoted context omitted.

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?

> I think that ruby 3 could lend itself to bring transpiled to crystal relatively easily I think for this to be tractable you'd basically have to implement a complete Ruby interpreter in Crystal and then transpire the Ruby program to bytecode to be run by the Crystal interpreter. So not really a meaningful or useful transpilation any more, and certainly not fast. Even basic things like method dispatch do not have the…

We don't know very much about what ruby 3 types will look like or what other information we'll have.

Even a small subset of ruby being transpiled would be a useful thing for some developers.

You're much more aware of some of the constraints here than I am, as Oracle doesn't pay me to hack ruby for a living.

With a typed AST, there'd be enough information there to build a foundation for a rb2cr tool. I didn't say the two languages are best friends and it'll be a breeze.

Most of the ruby code I want to rescue isn't littered with string-based define_method nonsense. Most of ruby I think worth saving at all is outside of rails and exists in various tools or maybe some metasploit modules or stuff like that. The pieces of code that utilize the grossest dynamic elements of ruby, like define method or objectspace, that stuff doesn't need to survive.

Even getting 50% of a codebase in ruby compiled to reasonable crystal is a much better foundation than previously purported successors (elixir, scala, swift) can do.

If ruby gets a typed ast, I'll try and write a simple transform tool for the simplest ruby.

Re: Stripe is building a Ruby typechecker

#125

Post by Kalium »

gmaster1440 wrote: post #122
Kalium wrote: post #120

Earlier quoted context omitted.

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.

To your earlier point, larger systems are harder to migrate. This suggests that starting off with an investment in static type systems is more tenable as a long-term strategy.

All other things being equal, that's probably true!

Re: Stripe is building a Ruby typechecker

#126

Post by pg_bot »

emodendroket wrote: post #123
pg_bot wrote: post #87

Earlier quoted context omitted.

The languages that I've used with static typing are Java and Objective-C so perhaps those languages have negatively impacted my perception of type systems. I can do more research on other languages to see what they have to offer. I used to run into type errors when I first started programming but I've learned how to eliminate them by changing my programming style. I add a lot of constraints to how I program, and foll…

> I add a lot of constraints to how I program, and follow a system of naming conventions that make it obvious what type something is. And you find it unbelievable that someone would prefer that the compiler simply enforce these conventions?

I don't find it unbelievable, I just personally don't get the appeal because you have to do that work when you name things anyway. e.g. I would never expect a variable named "first_name" to be anything other than a string. It's also fairly easy to handle most type conversions so I would rather be permissive in what I accept (to a reasonable point) than be rigid.

Re: Stripe is building a Ruby typechecker

#127

Post by random3 »

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 think making Ruby typed is a cool endeavor. It's just that it's a bit hard to justify from a business perspective..

It's not like changing to typed Ruby wouldn't affect the code bases. They'll end up having something that will resemble Ruby, but likely won't be quite Ruby. It's unlikely they could automate it. They'll have to rewrite a lot of code and typically, when you do that you also want to refactor obvious problems, so you end up rewriting big parts. And that's in addition to the cost of trying to make Ruby typed.

Or you could leave the code base as it is and extract functionality out and rewrite it in something more manageable.

Re: Stripe is building a Ruby typechecker

#128

Post by olingern »

I was at RubyKaigi. This presentation was one of the best delivered, so kudos to the Stripe team for all the work put into it.

A question I didn't get to ask while there is -- will there be some sort of type sharing system introduced?

I've been a user of both Typescript and Flow (both great tools), but saw Typescript's popularity soar because of community written types.

Re: Stripe is building a Ruby typechecker

#129

Post by emodendroket »

pg_bot wrote: post #126
emodendroket wrote: post #123

Earlier quoted context omitted.

> I add a lot of constraints to how I program, and follow a system of naming conventions that make it obvious what type something is. And you find it unbelievable that someone would prefer that the compiler simply enforce these conventions?

I don't find it unbelievable, I just personally don't get the appeal because you have to do that work when you name things anyway. e.g. I would never expect a variable named "first_name" to be anything other than a string. It's also fairly easy to handle most type conversions so I would rather be permissive in what I accept (to a reasonable point) than be rigid.

Well what are the properties of config_options or app_user or objects like these? Is it even documented, or am I forced to scan the entire method trying to figure out?

Re: Stripe is building a Ruby typechecker

#130

Post by toasterlovin »

Kalium wrote: post #125
gmaster1440 wrote: post #122

Earlier quoted context omitted.

To your earlier point, larger systems are harder to migrate. This suggests that starting off with an investment in static type systems is more tenable as a long-term strategy.

All other things being equal, that's probably true!

If only all other things were equal...
Post reply on HN