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

31–40 of 187 posts

Re: Stripe is building a Ruby typechecker

#31

Post by taf2 »

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
  )
  .returns(Symbol)
  def foo(foobar, widget: nil)
    (foobar.to_s + widget).to_sym
  end
end ```

I'd love it if we could write this as :

``` class Foo

  extend T::Helpers

  def foo(foobar:Integer, widget:String:nil):Symbol

    (foobar.to_s + widget).to_sym

  end
end

```

Not sure the best way to handle default values... e.g. widget:String:nil is kind of awkward... but still i'd be better this way then the additional method call 'sig'

Re: Stripe is building a Ruby typechecker

#32

Post by eropple »

pg_bot wrote: post #12
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,…

I would disagree with the statement that coding is faster in statically typed projects. The ease of onboarding new devs is solely based on the code quality of the project. Well written programs are easy to understand regardless of typing. Terribly written programs are opaque regardless of typing.

Those Scotsmen are pretty untrue, huh?

The claim is pretty facially silly at a glance besides, though. You literally don't know the fields and methods, to say nothing of what they actually give you, on a Ruby object without opening either the code or pulling up Pry and doing `ls`. Which I have done, often enough, to fail rather stunningly to miss doing so when in Kotlin or when using TypeScript. Checked that one? Good news--now you get to drill down into the next one, and the next one. I hope that isn't coming from another library, too, 'cause jumping from library to library in Ruby or Python is a chore. And even if not? God help you if you're using ActiveRecord, I hope you enjoy scanning your database migrations or describing tables just to learn method names.

It is a bad scene. And don't get me wrong; I like Ruby quite a lot. But I won't make excuses for it.

Personally, with the actual tooling available to modern systems, I write TypeScript much, much faster--we're talking probably twice as fast--than I do even ES6, which I otherwise quite like. And TypeScript can't even assert whether something is a whole number or not, unlike better languages. It has replaced Ruby for me on the strength of that alone.

Re: Stripe is building a Ruby typechecker

#33

Post by naiyt »

masukomi wrote: post #9

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/

For me it would have the same things that make Typescript appealing:

- Full access to a large and mature ecosystem (one that Crystal doesn't quite have)

- The ability to gradually add typing to an existing Ruby codebase. No need to rewrite an entire application. Just gradually add types to new code and during refactors.

If I was starting a new project I would definitely be considering Crystal, but I still feel like something like this would be great. Typescript has been a godsend for my frontend development life, and I would love to have something like this for my backend Ruby development.

Re: Stripe is building a Ruby typechecker

#34

Post by bastawhiz »

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.

I started working with TypeScript over vanilla JS a year or so ago. It's completely changed the way I work. Having autocomplete, pointing out silly errors (forgetting to return a value, forgetting to set a prop on a React component, forgetting to add a member to an object) before I refresh the page, and being able to pick up old code without having to reread through it to figure out what the hell it actually spits back out is a godsend. The latter has sped up my productivity significantly; being able to get the output from a library, hover over the variable, and see the exact shape of the output saves an incredible amount of time when doing mundane day-to-day tasks.

Re: Stripe is building a Ruby typechecker

#35

Post by unfunco »

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.

Re: Stripe is building a Ruby typechecker

#36

Post by jrs95 »

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…

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

Re: Stripe is building a Ruby typechecker

#37

Post by spitfire »

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…

For some reason that reminds me of Pascals interface/implementation split...

For those not in the know Pascal units had to declare the function (procedure) prototypes before implementing them.

Re: Stripe is building a Ruby typechecker

#38

Post by masukomi »

CGamesPlay wrote: post #10
masukomi wrote: post #9

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/

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 language switching just isn't an option without a complete rewrite.

Re: Stripe is building a Ruby typechecker

#39

Post by masukomi »

parvenu74 wrote: post #13
masukomi wrote: post #9

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/

Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project -- just lacking type definition? If Crystal can do that then I think adoption of Crystal would benefit greatly.

As @chrisseaton said, no, BUT some ruby is valid Crystal. I think it would be more accurate to say that a subset of Crystal is valid Ruby, and a subset of Ruby is valid Crystal.
Post reply on HN