RBSup dawg. I heard you like type signatures, so I created a file format called .rbs, so you can alt-tab while you code.
More like ctrl-tab in the same editor.
RBS, Ruby’s new type signature language
261–270 of 340 posts
Re: RBS, Ruby’s new type signature language
#262As 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.
As another avid Rubyist, I have great interest in my editor autocompleting code in Rails.
Re: RBS, Ruby’s new type signature language
#263Earlier quoted context omitted.
> still not there And never will be.
Not sure what you're saying. What are places where Node isn't caught up to Ruby and can never catch up to Ruby? Ruby on Rails seems like a kneejerk response, but then again it doesn't exist because nobody really wants it, not for technical reasons. For example, Python has all the ML/math stuff. Nothing comes to mind for Ruby.
> it doesn't exist because nobody really wants it.
Clearly not true, as there's two separate fullstack frameworks being actively developed[0][1], not mentioning the ones in the past (sails.js, meteor.js).
[0] https://github.com/blitz-js/blitz [1] https://github.com/redwoodjs/redwood
Re: RBS, Ruby’s new type signature language
#264Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :) It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a .d.ts file - as that allows for different type checking implementations to use the same system under the hood. This was a big problem for Flow, and why it lost the fight as soon as Typ…
> I'm surprised that it does not seem to have syntax for type definitions in code This is a big disappointment to me, one of the main advantages of static typing is that it can make code much easier to understand when types are added to non-obvious method parameters.
It also leaves a big question-mark over how this fits into the REPL, and how we might create type definitions dynamically, since many classes in a running Ruby application are conjured by frameworks.
Re: RBS, Ruby’s new type signature language
#265Earlier quoted context omitted.
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…
> Type issues are about 0% of my Ruby bugs Doubt. In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.
Maybe we just work on different kinds of problems.
70%+ of bugs I deal with are business logic issues that no type system could solve.
Sure, as I code I run into an occasional nil object or NoMethod error, but those last as long in Ruby as they do in Swift (about 2-5 minutes while working on that specific part of the code).
Re: RBS, Ruby’s new type signature language
#266Earlier quoted context omitted.
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?
Sure, and I get compile time errors in Swift. Each last about 2-5 minutes.
The actual bugs I have to fix are nearly always business logic issues. Edge cases around 3rd party integrations, incomplete implementations, unintended side effects, etc.
Re: RBS, Ruby’s new type signature language
#267Re: RBS, Ruby’s new type signature language
#268Earlier quoted context omitted.
> It must be a very easy next step to allow type declaration inline with the code Updating Ruby’s already notoriously complex syntax to support type annotations while keeping existing Ruby code valid with it's existing semantics is...not a very easy step, I suspect. Annotations in documentation is a more viable way of integrating type definitions into program source files.
This is the first I have ever heard of ruby syntax as notoriously complex. If anything it’s usually the opposite. I would love to read why people say that about ruby.
Ruby is human-friendly at the expense of a machine-friendly syntax. Writing a machine parser for Ruby is awful.
I guess a language on the opposite side of the spectrum would be Lisp-likes, which are brain-dead simple to come up with a generative grammar for, but a little hard on the eyes.
Re: RBS, Ruby’s new type signature language
#269Earlier quoted context omitted.
I read parent’s “bonkers” in a positive way. Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name: String)“. In ruby it’s of course already taken, in no small part because there are 3 or 4 different ways to declare hash parameters. I’d imagine most decent syntax candidates had similar issues, due to ruby’s syntax versatility.
The worst part of ruby imo is the fact that a hash can have both string and symbol keys. Countless times I have encountered issues where a function takes an options hash and the callers use both string and symbols for the same key depending on which caller it is. I end up calling the function to convert to symbols all the time.
This is why ActiveSupport (Rails) has Hash#with_indifferent_access and people use it all over the place.
Re: RBS, Ruby’s new type signature language
#270Earlier quoted context omitted.
> Type issues are about 0% of my Ruby bugs Doubt. In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.
Maybe we just work on different kinds of problems. 70%+ of bugs I deal with are business logic issues that no type system could solve. Sure, as I code I run into an occasional nil object or NoMethod error, but those last as long in Ruby as they do in Swift (about 2-5 minutes while working on that specific part of the code).
I've worked across a wide range of industries over several years, and it's always been pretty similar. You should be building the business constraints into your types so that errors in the business logic become errors in the types - in my experience if you actually work with the type system then most errors become type errors. If you've got examples of the kind of errors you're talking about then I could try to be more specific.