Hacker News Reader

Comment by sparker72678 | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

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.

Yeah, that's where I would expect the problems to be. I believe Scala has similar issues.

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

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.

Sure. Create a type that represents x being <= that threshold, with a private constructor. Only allow constructing it via a factory method that requires it to be an x that should be <= the threshold. Then whenever you have a value of that type, you know that it's legitimately <= the threshold, and the bug becomes impossible.

This description doesn't quite make sense. If the threshold is regularly changing, the calculation can output the same result number for the same 21 parameters and have it be a bug or not a bug from month to month, depending on the threshold. How can you write a test for that without locking in the threshold? Indeed, without hard-coding the threshold in the calculation itself?

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.

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.

Reply on news.ycombinator.com