Hacker News Reader

Comment by bmacho | Hacker News Reader

All dynamically typed Ruby competitors like

  Python, Javascript (via Typscript), PHP, Elixir

have embraced Gradual Typing/Type Inference.

You use typed variables/typed function signatures when it's convenient, they give you some compile-time contracts, easy documentation and probably even speed. Otherwise they don't exist. I don't do Ruby, but Gradual Types/Type Inference is a no-brainer for dynamic languages, practically no drawback, only benefits. (And popular statically typed languages such as C/C++, Java, Rust support Type Inference, or are going there too.)

View on HN

Cool. People who want gradual typing can use those and leave Ruby alone.

> I don't do Ruby

So why have an opinion?

Languages I use: Ruby, C++, Odin, R. I'm not about to to around telling Rust, Python or Typescript people they're doing their languages wrong, even if there's things I hate about those languages. I just don't use them.

Ruby already has this with Sorbet. Nobody is forcing you to use it, are they?

It seems you have a lot of opinion here without really discussing your problem with type hints though. What is it you dislike?

I use Ruby regularly, have used it for more than a decade, and I wish it had something like a TypeScript equivalent (Sorbet is sorta this but not enough). Every time I work with a Ruby codebase without Sorbet, it’s a lot of guessing and praying that test coverage is good enough. It’s not fun having to find out in prod there’s dumb bugs that would have been caught by static analysis. Something I experience virtually never in TypeScript, the other language I’ve also used for a decade

> It seems you have a lot of opinion here without really discussing your problem with type hints. What is it you dislike?

It's runtime overhead (or you make a transpiler which then makes the language less dynamic), makes metaprogramming more annoying (other languages solve this with an "any" type which just defeats the purpose), and the "problem" it solves can be solved with tests which you should be writing anyway.

I do use statically typed languages BTW, I just prefer that if I'm going to go through the rigmarole of types that I'm going to get some actual benefit, namely an order of magnitude more performance.

My opinion is probably this since I don't work for a large corporation, I have my own startup, so I value my time a lot. I'm ok with trade-offs, I just think adding type hints to a dynamic language isn't a good trade off; it's almost all downside.

Edit:

> guessing and praying that test coverage is good enough.

You can always improve your test coverage...

For me, at least with TypeScript the single biggest advantage is the hinting you get from 3rd party packages/modules. This goes for building modules as well, you can use jsdoc directly, but it's even more cumbersome than TS imo.

It's kind of annoying that static type introspection has become the norm for language servers because live environments are so much better. With Ruby you have the REPL and there have been IDEs and tools that allow runtime reflection which is just so much better (think Lisp or Smalltalk). LSPs are nice for static languages but compared to live environments they're a step down...

Even after over a decade with TypeScript, I'm still kind of mixed on it... there are a lot of times where trying to wrangle typing is more painful than it should need to be... I'll often just cast to any, then I have to add a comment to suppress the error message with the default config. I use deno a lot and tend not to mess with the default configuration there. Even with node/npm, I still don't do much with the tsconfig beyond what a minimal need is.

It's not as painful as earlier versions and is generally okay to work with... but there are definitely times you need to work around the typing as opposed to with it. For example extending/using context in hono/oak/koa so you get hinting, but want your endpoint handlers in separate modules. It gets very messy, very quickly.

Reply on news.ycombinator.com