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

71–80 of 187 posts

Re: Stripe is building a Ruby typechecker

#71

Post by tsycho »

unfunco wrote: post #35
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…

The second version would be difficult, maybe impossible currently due to keyword arguments, since: def foo(foobar:Integer) end is already valid, and I think the lexer might struggle with the ambiguity; but I'm not 100% certain. Edit: I seemingly missed the last line of your comment where you state something similar.

If foo:SomeType is problematic, let’s just use foo::SomeType instead. I agree with the parent that inline types are much nicer and more intuitive than he sig based approach.

Re: Stripe is building a Ruby typechecker

#72

Post by kjeetgill »

pg_bot wrote: post #6

I don't understand the appeal of static typing. It always feels like I'm adding overhead without receiving any benefits. I've worked in some fairly large dynamically typed codebases and have never run into issues with type errors. Static typing does not alleviate the need to test your code, which is a more effective way of reducing bugs in your system than annotating your methods/functions.

You've gotten a lot of responses but let me throw one more idea at you: bad or mediocre code bases. Or old codebases that have the scars of years of tweaks, fixes, and hacks. Thats where I think static types shine the most.

Comparing my Python and Java experience, jumping into the middle of a codebase and correctly untangling a few particularly problematic spots or reworking and refactoring packages without introducing errors is dramatically easier with static typing.

It's feels like the difference between untangling actual wet noodles vs solving a sliding block puzzle. It's just more mechanical.

Even BEFORE running tests there is a lot of confidence that you haven't overlooked something. Hell, you can't catch typos in python without 100% code coverage. The sanity bar is just that much higher before you even get to unit tests.

Re: Stripe is building a Ruby typechecker

#73

Post by chrisseaton »

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

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.

Re: Stripe is building a Ruby typechecker

#74

Post by chrisseaton »

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?

> 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 same semantics in Crystal as in Ruby, so almost nothing could be tarnspiled 1-to-1.

Re: Stripe is building a Ruby typechecker

#75

Post by vidarh »

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…

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 with that as part of generating their documentation (and if not, writing them means you're now writing comments a lot of tools can generate documentation from.

Re: Stripe is building a Ruby typechecker

#76

Post by zxcvhjkl »

pg_bot wrote: post #6

I don't understand the appeal of static typing. It always feels like I'm adding overhead without receiving any benefits. I've worked in some fairly large dynamically typed codebases and have never run into issues with type errors. Static typing does not alleviate the need to test your code, which is a more effective way of reducing bugs in your system than annotating your methods/functions.

For me, static typing actually makes it easier and faster to write code. It’s like someone looking continuously over my shoulder for mistakes.

I am the least efficient when I write code in JS.

On the other hand with Ruby, and meta programming, I can do stuff that would be impossible to express in the most popular type systems.

Re: Stripe is building a Ruby typechecker

#77

Post by zxcvhjkl »

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…

> People created dynamic languages for the exact reason of not having to define types.

Not having to define types is not the biggest merit of dynamic languages.

The biggest benefit is to be able to do things that you couldn’t do if you had a type system. You can do some crazy stuff with Ruby’s meta programming.

Re: Stripe is building a Ruby typechecker

#78

Post by vidarh »

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?

The type system is the least of your problems. Ruby's type system is fairly simple and straight-forward.

The problem is that the ruby execution model is fundamentally incompatible with ahead-of-time compilation without making a lot of decisions about what occurs before compilation and what is deferred until later. E.g. a lot of Ruby programs execute code to determine which files to "require" (e.g. iterating over all files in a directory is a common pattern). In some cases that is a convenience for developers. In others it's meant to e.g. provide "plugin" abilities at runtime. In both cases the included code can totally change the behaviour of large parts of your code base.

Those decisions are possible to make, but you must make them and you probably can't make them satisfactorily without providing a mechanism for the developers to specify intended behaviour. If your decision is to defer everything until after compilation, you'll basically end up JIT-compiling most of the code at runtime, and all type information from before that point is suspect.

Re: Stripe is building a Ruby typechecker

#79

Post by pmontra »

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 year) vs at every single method definition.

To understand if this project could have a future outside Stripe, how popular is Python 3.6's optional static type declaration?

Re: Stripe is building a Ruby typechecker

#80

Post by pmontra »

mping wrote: post #15
matchbok wrote: post #8

Earlier quoted context omitted.

Not sure I've ever heard anyone say static typing removes the need for testing. Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one. Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have. And, most modern type systems (Typescript,…

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…

Actually the only language I used autocomplete was Java, mainly because it's almost impossible to work in Java without a IDE. However sometimes I turned autocomplete off because those long menus are a pain to see. I don't use a real autocomplete in Emacs with Ruby, Python, Elixir, JavaScript. I use pabbrev which remembers the words I type. It's usually enough not to make typos and it helps to remember the methods/functions.
Post reply on HN