4 ms·

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 dea

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 fits that mold. So much of what I love about Ruby is what it doesn't make me do.

jolux 6y ago
Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.
- sparker72678 6y ago
  My point is that imposing a big ass type system on developers as a "solution" to a trivial number of actual problems is overkill. I'm sure there are developer/projects that both enjoy and benefit from static typing and strict type systems of various kinds. I just want Ruby to remain a place for those of us who aren't in those positions.
  - jolux 6y ago
    I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book. However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't think dynamically typed Ruby is ever going to die. Whether large enterprise codebases will standardize on requiring type signatures is a different matter, because the benefits always outweigh what downsides you see in static typing once you surpass a certain scale.
    - sparker72678 6y ago
      Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. > "Whether large enterprise codebases will standardize on requiring type signatures is a different matter" Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.
      - jolux 6y ago
        >Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.
        sparker72678 6y ago
        My biggest complaints all center around the intersection of custom types with protocols and extensions, especially when trying to get a generic approach to something working.
        jolux 6y ago
        Yeah, that's where I would expect the problems to be. I believe Scala has similar issues.
lmm 6y ago
> 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.
- sparker72678 6y ago
  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).
  - lmm 6y ago
    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.
    - sigmaml 6y ago
      Not the GP, but here is a scenario that I am interested in understanding from the perspective of types. A calculation that involves 21 parameters (in a particular insurance industry underwriting) yields a number. A threshold is read from the database. This threshold could change every month. Suppose that the current value of the threshold is 0.78. The calculation above can yield an `x` with the following cases: (i) x <= 0.78, (ii) x > 0.78. We have hundreds of test cases for the combinations of the 21 parameters, leading to hundreds of values for `x`. It is a bug for `x` to be > 0.78 when it should be the other way. Is there a way this can be encoded in types? That would be very interesting. Thanks.
djur 6y ago
You've never had a NoMethodError in Ruby?
- sparker72678 6y ago
  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.
imtringued 6y ago
Don't you see the irony in your own comment? If you never create type related bugs in ruby then you shouldn't encounter them in a typed language either because you are infallible. The truth is probably that you see all the type errors at runtime instead and don't see them as such.

jolux 6y ago

Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.

sparker72678 6y ago
My point is that imposing a big ass type system on developers as a "solution" to a trivial number of actual problems is overkill. I'm sure there are developer/projects that both enjoy and benefit from static typing and strict type systems of various kinds. I just want Ruby to remain a place for those of us who aren't in those positions.
- jolux 6y ago
  I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book. However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't think dynamically typed Ruby is ever going to die. Whether large enterprise codebases will standardize on requiring type signatures is a different matter, because the benefits always outweigh what downsides you see in static typing once you surpass a certain scale.
  - sparker72678 6y ago
    Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. > "Whether large enterprise codebases will standardize on requiring type signatures is a different matter" Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.
    - jolux 6y ago
      >Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.
      - sparker72678 6y ago
        My biggest complaints all center around the intersection of custom types with protocols and extensions, especially when trying to get a generic approach to something working.
        jolux 6y ago
        Yeah, that's where I would expect the problems to be. I believe Scala has similar issues.

lmm 6y ago

> 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.

sparker72678 6y ago
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).
- lmm 6y ago
  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.
  - sigmaml 6y ago
    Not the GP, but here is a scenario that I am interested in understanding from the perspective of types. A calculation that involves 21 parameters (in a particular insurance industry underwriting) yields a number. A threshold is read from the database. This threshold could change every month. Suppose that the current value of the threshold is 0.78. The calculation above can yield an `x` with the following cases: (i) x <= 0.78, (ii) x > 0.78. We have hundreds of test cases for the combinations of the 21 parameters, leading to hundreds of values for `x`. It is a bug for `x` to be > 0.78 when it should be the other way. Is there a way this can be encoded in types? That would be very interesting. Thanks.

djur 6y ago

You've never had a NoMethodError in Ruby?

sparker72678 6y ago
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.

imtringued 6y ago

Don't you see the irony in your own comment? If you never create type related bugs in ruby then you shouldn't encounter them in a typed language either because you are infallible. The truth is probably that you see all the type errors at runtime instead and don't see them as such.