RBS, Ruby’s new type signature language • Hacker News Board

Re: RBS, Ruby’s new type signature language

#251

Post by Jweb_Guru » Thu, Jul 30, 2020, 1:07 AM UTC

amw-zero wrote: post #172

mekster wrote: post #135

Earlier quoted context omitted.

How hard is it to imagine that you need to keep 2 files in sync, and that you can't type anything inside a method. I was even hoping to use ruby as a main language having used it before but I'm about to lose any interest in the language when its reality is a bit decoupled from the rest of the world.

Have you ever worked with a language that has header files (C/C++) or a language that can use them optionally (Ocaml)? In practice, keeping the files in sync isn’t difficult. In fact, it ends up being better (for me) in terms of readability, because I can look up the type definitions in one place, store them as context, and then read code that isn’t littered with type annotations. Type annotations add quite a bit of…

Not to anecdote too hard, but the practice of doing type signatures out-of-line that you are describing is my absolute least favorite part of OCaml, which is otherwise a very lovely language. As for C++, it has enough other stuff going on that I probably can't say the header files are my least favorite feature, but they certainly don't make life easy. I think it makes sense to challenge that decision from an ergonomics standpoint, even if it makes sense within the constraints the Ruby core team has decided upon.

Re: RBS, Ruby’s new type signature language

#252

Post by mekster » Thu, Jul 30, 2020, 1:31 AM UTC

rosywoozlechan wrote: post #200

fimbulvetr wrote: post #101

Earlier quoted context omitted.

I don't use ruby, I am genuinely interested - why is it great? I'm assuming if it were ever allowed, it would be a use-at-will feature and wouldn't affect anyone who didn't use it. Typescript has probably doubled if not more my speed and accuracy since I've adopted it - yet I still do plenty of things in normal javascript. These days I'm usually unhappy when something does not have typings because it can make it terr…

> Typescript has probably doubled if not more my speed and accuracy since I've adopted it TypeScript hasn't ever done anything for me than give me 3rd party dependency integration headaches. I love strongly typed languages and compile time checking, but TypeScript has never seemed worth the trade off due to its broken interoperability with normal JavaScript and the terrible state of crowd sourced typedefs. I'm either…

What editor are you using?

It's about having things auto completed and you get to see errors before you run.

And what kind of library are you using to complain that third party typings are the source of your concern?

Re: RBS, Ruby’s new type signature language

#253

Post by djur » Thu, Jul 30, 2020, 1:42 AM UTC

etxm wrote: post #250

dragonwriter wrote: post #244

Earlier quoted context omitted.

> Anything is better than a separate file. I dunno. Massive breakages of backward compatibility in an established language may not be better than that.

It is a major version change, right? It seems like the best time to introduce some breaking changes for the betterment of the language.

Syntax changes of this magnitude would make the Python 3 migration timeline look quick and painless.

Re: RBS, Ruby’s new type signature language

#254

Post by djur » Thu, Jul 30, 2020, 1:46 AM UTC

sparker72678 wrote: post #120

zeptonix wrote: post #95

Earlier quoted context omitted.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

A-fucking-men. In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs. Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics. If you want strong typing, then good for you. Just pick a language that…

You've never had a NoMethodError in Ruby?

Re: RBS, Ruby’s new type signature language

#255

Post by kgilpin » Thu, Jul 30, 2020, 1:49 AM UTC

amw-zero wrote: post #174

RangerScience wrote: post #106

Earlier quoted context omitted.

Why would you need to? Edit: Like, seriously. Either the local var is populated by something coming in externally (which is then typable) or, unless your code is too complex / large, it should be easy to see everywhere it's used, and then why would you need that additional typing info?

Because when you see the benefit of type annotations (I’m not saying that’s objective, just if you do go that route) you want to add type information to as much as possible. Leaving them off because you want to is one thing. Not being able to is an unnecessary limitation.

The point is that the type of a local variable can almost always be inferred based on what it’s assigned to.

Re: RBS, Ruby’s new type signature language

#256

Post by sixstringtheory » Thu, Jul 30, 2020, 1:49 AM UTC

vemv wrote: post #218

sixstringtheory wrote: post #215

Earlier quoted context omitted.

I'm glad we agree that adding type annotations to code is a good thing. You aren't arguing against that–you are just arguing implementation details. If I'm designing a 5 9s service tasked with processing gigabytes of data every unit time, I don't want to pay the runtime cost of checking the types for every mundane operation like measuring the length of a string.

Design by contract (which the mentioned libraries excel at) isn't a new thing, and the mentioned one is a solved problem. https://en.wikipedia.org/wiki/Design_by_contract#Performance...

It is evidently not a solved problem. Why would large financial services companies be working on these things we're talking about if that were the case?

Do you know what solves the problem of checking every type of every thing you want to use before you use it, where the checks don't incur any performance penalty at runtime? Static type checkers!

Modern compilers usually don't even require any explicit type declarations, as they can infer at assignment. So they provide more safety for less code than your examples.

Re: RBS, Ruby’s new type signature language

#257

Post by castwide » Thu, Jul 30, 2020, 1:52 AM UTC

I'm still trying to make sense of this announcement. With a lack of type annotation in the Ruby core, I chose to build off YARD to make gradual type safety work. Now I don't know if there will be a standard that supports type safety or if I should continue down the path I'm already following. Help me, Ruby core developers. You're my only hope.

(edit: I should have explained that I'm talking about the type checking features I'm developing in Solargraph: https://solargraph.org/guides/type-checking)

Re: RBS, Ruby’s new type signature language

#258

Post by mekster » Thu, Jul 30, 2020, 1:56 AM UTC

symlinkk wrote: post #189

lovetocode wrote: post #177

As an avid Rubyist I have no interest in introducing types into a dynamic language. I would just rather use C# or Java. I never understood why people are trying to make a round peg fit in a square hole.

It’s insane to me that people are still arguing against static types. TypeScript has proven that you can add the safety of static types without taking away any of the flexibility of dynamic typing. Every time you dive deep into source code to figure out what a field is called or what a function expects, remember that you could have eliminated that completely with static types.

Perhaps if people have not used JS and TS, they would think that typings are in their brain memory but typings are a lot more than scalar and return value typings like defining a structure of a hash and apply that dynamically depending on parameter value or give string an enum like behavior limiting what could be assigned.

Re: RBS, Ruby’s new type signature language

#259

Post by floatboth » Thu, Jul 30, 2020, 1:58 AM UTC

untog wrote: post #159

CarelessExpert wrote: post #131

Earlier quoted context omitted.

> They didn't, though! That's what's confusing me. Sure they did. It's the 5th paragraph in the post: "We defined a new language called RBS for type signatures for Ruby 3. The signatures are written in .rbs files which is different from Ruby code. You can consider the .rbs files are similar to .d.ts files in TypeScript or .h files in C/C++/ObjC. The benefit of having different files is it doesn't require changing Rub…

They've described part of TypeScript's approach. .rbs files: have types .rb files: no types .d.ts files: have types .ts files: have types It's a pretty significant difference. So they didn't "follow typescript's approach" here.

Well, .rb types won't have the standard type signatures (that could be consumed by various typecheckers) but could still have a particular typechecker's custom annotations…

Re: RBS, Ruby’s new type signature language

#260

Post by mekster » Thu, Jul 30, 2020, 2:02 AM UTC

ativzzz wrote: post #29

azinman2 wrote: post #15

Earlier quoted context omitted.

But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.

Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.

That use case is not for most of us yet the way those companies with large code base goes into the core? I guess ruby itself already has a large code base, so it seems they got aligned but they forgot to align with the rest of the world.