Show HN: Ruby static type checker – proof of concept • Hacker News Board

Re: Show HN: Ruby static type checker – proof of concept

#21

Post by kazinator » Mon, Oct 23, 2017, 3:33 PM UTC

krapsna wrote: post #15

Perhaps this went completely over my head somehow? I'm not seeing why this is needed, other than people who find comfort in static typing think Ruby is broken without it. I've been programming with Ruby every day for 5+ years, and it performs and debugs just fine without static typing. My summary opinion is if static typing makes you happy go for it. Please don't try to force it into Ruby as a feature of the language…

If, without sacrificing any dynamic aspects of a language, we can be better informed about programs and expressions before they are executed, it's almost a pure win, and therefore a no-brainer. ("Almost" because we pay for it with some machine cycles and memory required to execute the checks.)

If you call a three-arg function with only two-args, it is more helpful to see a diagnostic than not to see a diagnostic, all else being equal.

Re: Show HN: Ruby static type checker – proof of concept

#22

Post by stereobooster » Mon, Oct 23, 2017, 4:12 PM UTC

krapsna wrote: post #15

Perhaps this went completely over my head somehow? I'm not seeing why this is needed, other than people who find comfort in static typing think Ruby is broken without it. I've been programming with Ruby every day for 5+ years, and it performs and debugs just fine without static typing. My summary opinion is if static typing makes you happy go for it. Please don't try to force it into Ruby as a feature of the language…

The reason is to fight with bugs, which are caused by type errors. Current approaches are:

1) use guards 2) add tests which check types 3) use error reporting software, like Sentry, and cath errors in production

Is there any reason you do not want not catch type errors without additional code and useless tests before you deployed it to production?

https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q...

Re: Show HN: Ruby static type checker – proof of concept

#23

Post by stereobooster » Mon, Oct 23, 2017, 4:17 PM UTC

hamandcheese wrote: post #13

If you’re interested in this, you might also be interested in the Crystal language. > Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs. > Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language cl…

Crystal is not Ruby. Please do not advertise it as a drop in replacement. https://github.com/crystal-lang/crystal/issues/4731#issuecom...

Imagine you have a big ruby project in production and you want to add static type checking. You won't be able to use Crystal for it, while the idea behind Diamondback Ruby is to be able to integrate it gradually.

Re: Show HN: Ruby static type checker – proof of concept

#24

Post by stereobooster » Mon, Oct 23, 2017, 7:16 PM UTC

xuejie wrote: post #19

stereobooster wrote: post #10

Earlier quoted context omitted.

But those are for dynamic typing. I was looking for static typing

Personally I feel we might never get static typing for Ruby anytime soon, at least it won't be widely adopted in the community, so I'd settle on dynamic typing like this. After all, Crystal is already quite good as a Ruby+static typing solution

Again Crystal is not Ruby. https://github.com/crystal-lang/crystal/issues/4731#issuecom...

> we might never get static typing for Ruby anytime soon

Yes we will not get type declarations as a part of Ruby syntax anytime soon, but this doesn't mean we can not have static type checking right now

Re: Show HN: Ruby static type checker – proof of concept

#25

Post by nine_k » Wed, Oct 25, 2017, 12:10 PM UTC

stereobooster wrote: post #23

hamandcheese wrote: post #13

If you’re interested in this, you might also be interested in the Crystal language. > Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs. > Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language cl…

Crystal is not Ruby. Please do not advertise it as a drop in replacement. https://github.com/crystal-lang/crystal/issues/4731#issuecom... Imagine you have a big ruby project in production and you want to add static type checking. You won't be able to use Crystal for it, while the idea behind Diamondback Ruby is to be able to integrate it gradually.

Crystal is closer to Ruby in many aspects than e.g. Rust or Haskell or Nim. It might be an easier step into the land of static typing for someone acquainted to Ruby.

It's not a static type checker for Ruby, though.