6 ms·

Interesting article, but to me it really defeats the point of Ruby. The hyper-dynamic "everything is an object" in the Smalltalk sense of the definition is muc

Interesting article, but to me it really defeats the point of Ruby. The hyper-dynamic "everything is an object" in the Smalltalk sense of the definition is much of what makes Ruby great. I hate this idea that Ruby needs to be more like Python or Typescript; if you like those languages use those languages. I get that a lack of types is a problem for massive organizations but turning dynamic languages into typed languages is a time sink for solo developers and small organizations for zero performance benefit. If I wanted a typed language to build web apps with I'd use Java or something. Hopefully Matz sticks to his guns and never allows type annotations at the language and VM level.

kodablah 1y ago
> I hate this idea that Ruby needs to be more like Python or Typescript It's not be more like those, it's be more like helpful, author-friendly programming which is very much Ruby's ethos. Every time I think about ripping out all of the RBS sig files in my project because I'm tired of maintaining them (I can't use Sorbet for a few reasons), Steep catches a `nil` error ahead of time. Sure we can all say "why didn't you have test coverage?" but ideally you want all help you can get.
- PaulHoule 1y ago
  As a Pythoner the most direct value I get out of types is the IDE being smart about autocompletion, so if I'm writing with db.session() as session: ... use the session ... I can type session. and the IDE knows what kind of object it is and offers me valid choices. If there's a trouble with it, it's that many Pythonic idioms are too subtle, so I can't fully specify an API like collection = db["some_collection"] collection.filter(lambda doc: doc["amount"].as_integer() > 500) collection.filter({"name": "whatever"}) collection.filter({"field": lambda f: f["subfield"] = jsonb({"a":1, "b":"2})}) not to mention I'd like to be able to vary what gets returned using the same API as SQLAlchemy so I could write collection.filter(..., yield_per=100) and have the type system know it is returning an iterator that yields iterators that yields rows as opposed to an iterator that yields rows. It is simple, cheap and reusable code to forward a few fetch-control arguments to SQLAlchemy and add some unmarshalling of rows into documents but if I want types to work right I need an API that looks more like Java.
  - maleldil 1y ago
    If I understand correctly, you can do this with overloads. They don't change the function implementation, but you can type different combinations of parameters and return types.
- jimbokun 1y ago
  > Sure we can all say "why didn't you have test coverage?" Well types are a form of test performed by the compiler.
- jaredsohn 1y ago
  LLMs can probably help maintain them so that probably could be solved if you start using LLMs more. This maybe already exists, but it would be nice if RBS or Sorbet had a command you could run that checks that all methods have types and tries to 'fix' anything missing via help from an LLM. You'd still be able to review the changes before committing it, just like with lint autofixing. Also you'd need to set up an LLM API key and be comfortable sharing your code with it.
jbverschoor 1y ago
It’s all about message passing. Why not allow a compile time check if something respond to a message. Types/interfaces are good. Failing early is a good thing. The earliest you can fail is during editing, and then compile/interpret time. In Objective-C, you also pass messages to an object, and it could be anything you want. But it would output warnings that an object/class did not respond to a certain message. You could ignore it, but it would always result in a runtime error obviously. [someObject missingMethod] Swift is a much nicer language in terms of typing, and I have started replacing some smaller Ruby scripts with Swift. Mostly out of performance needs though. (Single file swift scripts) The lack of proper typechecking is one of the main reasons I would not use Ruby, especially in larger teams. Unittests are fun and all, but they serve a different purpose.
- dismalaf 1y ago
  > The lack of proper typechecking is one of the main reasons I would not use Ruby, especially in larger teams. Cool. I'm using Ruby for a startup because it's 10x more productive for building a webapp versus a compiled language and because I'm solo. And when I want typing I use something like C++ because I don't want to lose productivity without a major performance boost.
  - corytheboyd 1y ago
    > I'm using Ruby for a startup because it's 10x more productive for building a webapp versus a compiled language I’ve been a Ruby/Rails dev for about 14 years. Just started working on Java projects at work and… holy shit, it slows down the entire organization and they don’t even seem to know how much of it is because of the terrible immovable object that is the mountain of Java code they made. Before this experience I had always assumed that rigid types alone would be a boon… oh how wrong I was. The rigidity just leads to people writing 10x more garbage to get simple things done, which causes a 10x worse maintainability problem. The rate at which I hear “oh lol just another NPE” is astounding, how is this constant occurrence not interpreted as a complete failure of the “type” system???? Maybe a crack team of Java Experts wouldn’t do this, but the reality of most software companies is that people of ALL skill levels are writing code. Poorly written Ruby is a whole lot easier to figure out (as an expert of Ruby) than 10x the amount of code in Java. I hate this.
Lio 1y ago
I respect this view but I can really see the utility of gradual typing as your project grows and matures. I also wonder if we’ll eventually be able to pass type information to the JIT. If that helps ruby grow I’m all for it.
- dismalaf 1y ago
  > I also wonder if we’ll eventually be able to pass type information to the JIT. It's not like Ruby doesn't have types and the JIT can't determine them. It just happens at runtime, literally the defining feature of dynamic languages.
  - Lio 1y ago
    That’s true but it would be useful to upfront specify exactly what’s in an array and exactly how big it will be for the entire life of the array.
__float 1y ago
> Hopefully Matz sticks to his guns and never allows type annotations at the language and VM level. Why? Just because they _exist_ doesn't mean you'd need to use them.
arp242 1y ago
I find types useful especially for smaller solo projects: because the test suite is much less complete, or even non-existent. Types give quick feedback for a bunch of silly but common errors. It's entirely unclear to me that types reduce developer velocity on small projects; it seems roughly the same to me. I certainly don't see how it's a "time sink". But in the end: if you don't like it, just don't use it? Ruby has never been about restricting how people use the language.

kodablah 1y ago

> I hate this idea that Ruby needs to be more like Python or Typescript It's not be more like those, it's be more like helpful, author-friendly programming which is very much Ruby's ethos. Every time I think about ripping out all of the RBS sig files in my project because I'm tired of maintaining them (I can't use Sorbet for a few reasons), Steep catches a `nil` error ahead of time. Sure we can all say "why didn't you have test coverage?" but ideally you want all help you can get.

PaulHoule 1y ago
As a Pythoner the most direct value I get out of types is the IDE being smart about autocompletion, so if I'm writing with db.session() as session: ... use the session ... I can type session. and the IDE knows what kind of object it is and offers me valid choices. If there's a trouble with it, it's that many Pythonic idioms are too subtle, so I can't fully specify an API like collection = db["some_collection"] collection.filter(lambda doc: doc["amount"].as_integer() > 500) collection.filter({"name": "whatever"}) collection.filter({"field": lambda f: f["subfield"] = jsonb({"a":1, "b":"2})}) not to mention I'd like to be able to vary what gets returned using the same API as SQLAlchemy so I could write collection.filter(..., yield_per=100) and have the type system know it is returning an iterator that yields iterators that yields rows as opposed to an iterator that yields rows. It is simple, cheap and reusable code to forward a few fetch-control arguments to SQLAlchemy and add some unmarshalling of rows into documents but if I want types to work right I need an API that looks more like Java.
- maleldil 1y ago
  If I understand correctly, you can do this with overloads. They don't change the function implementation, but you can type different combinations of parameters and return types.
jimbokun 1y ago
> Sure we can all say "why didn't you have test coverage?" Well types are a form of test performed by the compiler.
jaredsohn 1y ago
LLMs can probably help maintain them so that probably could be solved if you start using LLMs more. This maybe already exists, but it would be nice if RBS or Sorbet had a command you could run that checks that all methods have types and tries to 'fix' anything missing via help from an LLM. You'd still be able to review the changes before committing it, just like with lint autofixing. Also you'd need to set up an LLM API key and be comfortable sharing your code with it.

jbverschoor 1y ago

It’s all about message passing. Why not allow a compile time check if something respond to a message. Types/interfaces are good. Failing early is a good thing. The earliest you can fail is during editing, and then compile/interpret time. In Objective-C, you also pass messages to an object, and it could be anything you want. But it would output warnings that an object/class did not respond to a certain message. You could ignore it, but it would always result in a runtime error obviously. [someObject missingMethod] Swift is a much nicer language in terms of typing, and I have started replacing some smaller Ruby scripts with Swift. Mostly out of performance needs though. (Single file swift scripts) The lack of proper typechecking is one of the main reasons I would not use Ruby, especially in larger teams. Unittests are fun and all, but they serve a different purpose.

dismalaf 1y ago
> The lack of proper typechecking is one of the main reasons I would not use Ruby, especially in larger teams. Cool. I'm using Ruby for a startup because it's 10x more productive for building a webapp versus a compiled language and because I'm solo. And when I want typing I use something like C++ because I don't want to lose productivity without a major performance boost.
- corytheboyd 1y ago
  > I'm using Ruby for a startup because it's 10x more productive for building a webapp versus a compiled language I’ve been a Ruby/Rails dev for about 14 years. Just started working on Java projects at work and… holy shit, it slows down the entire organization and they don’t even seem to know how much of it is because of the terrible immovable object that is the mountain of Java code they made. Before this experience I had always assumed that rigid types alone would be a boon… oh how wrong I was. The rigidity just leads to people writing 10x more garbage to get simple things done, which causes a 10x worse maintainability problem. The rate at which I hear “oh lol just another NPE” is astounding, how is this constant occurrence not interpreted as a complete failure of the “type” system???? Maybe a crack team of Java Experts wouldn’t do this, but the reality of most software companies is that people of ALL skill levels are writing code. Poorly written Ruby is a whole lot easier to figure out (as an expert of Ruby) than 10x the amount of code in Java. I hate this.

Lio 1y ago

I respect this view but I can really see the utility of gradual typing as your project grows and matures. I also wonder if we’ll eventually be able to pass type information to the JIT. If that helps ruby grow I’m all for it.

dismalaf 1y ago
> I also wonder if we’ll eventually be able to pass type information to the JIT. It's not like Ruby doesn't have types and the JIT can't determine them. It just happens at runtime, literally the defining feature of dynamic languages.
- Lio 1y ago
  That’s true but it would be useful to upfront specify exactly what’s in an array and exactly how big it will be for the entire life of the array.

__float 1y ago

> Hopefully Matz sticks to his guns and never allows type annotations at the language and VM level. Why? Just because they _exist_ doesn't mean you'd need to use them.

arp242 1y ago

I find types useful especially for smaller solo projects: because the test suite is much less complete, or even non-existent. Types give quick feedback for a bunch of silly but common errors. It's entirely unclear to me that types reduce developer velocity on small projects; it seems roughly the same to me. I certainly don't see how it's a "time sink". But in the end: if you don't like it, just don't use it? Ruby has never been about restricting how people use the language.