3 ms·

I used to write Ruby professionally, and found the lack of any type system and duck typing to cause pretty severe problems. Not knowing if the variable you wer

I used to write Ruby professionally, and found the lack of any type system and duck typing to cause pretty severe problems. Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. But this kind of API where you have 'safe' operators that don't throw is a pretty good convenience, since forgetting that a variable might be nil is pretty common (or passing nil into a method that previously never accepted a nil and where the API was never tested for nil). There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly, which is much better than using 'unsafe' operators that just blow up and throw/panic if you don't think about the edge condition (So I wouldn't consider the Python alternative to be any better, you're just trading one possibly bad behavior of an edge condition for another possibly bad behavior of an edge condition and forcing programmers and code reviewers to constantly have them in their mind, and blaming them for when it goes wrong--with one group or the other feeling superior about their choice of when to blame the programmer for forgetting to handle the behavior). I think this is also roughly equivalent to languages like C# 8.0+ that have nillable/non-nillable types and static checking to make sure you're using them right.

vidarh 3y ago
> and found the lack of any type system I'm not surprised you found Ruby uncomfortable when you describe Ruby as not having a type system. It might just not be the right language for you. That's fine. > Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. Nothing stops you from declaring that you expect a given type in Ruby; it's just code, and not mandatory, though you can certainly write code to impose mandatory types with Ruby - there was a while when writing those seemed a rite of passage for Ruby developers, but the reality was that they buy far less than people think until they've tried writing one and/or spent some time using them. > There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly Nothing stops you from doing that in Ruby, and in fact there are several monad implementations for Ruby that provides building blocks for those kinds of patterns if/when you want to use them.
- lamontcg 3y ago
  > I'm not surprised you found Ruby uncomfortable when you describe Ruby as not having a type system. It might just not be the right language for you. That's fine. Thought we were supposed to "respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize" around here and not nitpick misstatements.
  - vidarh 3y ago
    I did not suggest you believe that Ruby does not actually have a type system at all, but your statement to me still implies a view about the way Ruby treats typing that suggests to me that it is a fairly natural consequence you will find Ruby uncomfortable. There's no value judgment in that, nor nitpicking or criticism. Just an observation that Ruby might just not be right for you.
    - lamontcg 3y ago
      I'll take your suggestion along with my 12 years of professional experience with Ruby under advisement.
berkes 3y ago
I too wrote Ruby fulltime and professionally. For over a decade. The sheer amount of code I wrote, just to protect against nil-errors is staggering. Every third function or method had guard clauses and/or tests. Just to ensure that the data was in the expected shape (that it quacked and walked like a duck). I spent, I think, hundreds maybe thousand hours debugging actual production "nil-errors" and weird conversion errors. That happened in production. Sometimes legacy database records, sometimes weird race conditions causing corrupt data, sometimes (most often) just stupid mistakes by me or another dev. All of these -all!- would have been caught by a typing system and type checker like e.g. Rusts'. All. Which then leaves just the huge category of stupid bugs that I'll make in the business logic. But now, working with rust, the LSP tells within ms that I overlooked something that In Ruby would've been a data-error. Often my Ruby test suite would find these after minutes of running. Sometimes we would find them after deploying to prod and seeing havoc. Sometimes they'd take weeks before popping up. I'm convinced rust makes me develop much faster because of this.
- vidarh 3y ago
  If you need to test again nil "every third function or method", then that reflects broken abstractions and/or very dated Ruby. For "maybe nil" situations, modern Ruby code will lean heavily into safe navigation, dig, or wrapping values, and sometimes monads or similar. If that's not enough for you, Ruby has optional type checkers available.
raggi 3y ago
The position of “I regularly don’t know if I have a string or a uri” is indeed a commonly raised issue. It folds out to two other problems: It implies a lack of conventions around interfaces and variable names. The surrounding statement also implies that it was not easy to figure out quickly (hard to exercise that code synthetically). Highly successful workflows in loosely typed environments like this depend upon a strict culture to ensure both of these aspects are under constant improvement. This is difficult to scale, and improving these aspects in other languages also helps other workflows, but their impact in these environments is much higher. It’s part of the reason why you would hear _so much_, density wise, about code patterns, code health, testing and so on in the ecosystem in its peak era, all of those things were really just mechanisms to try to achieve the above factors.

vidarh 3y ago

> and found the lack of any type system I'm not surprised you found Ruby uncomfortable when you describe Ruby as not having a type system. It might just not be the right language for you. That's fine. > Not knowing if the variable you were dealing with was a String or a URI was great until it very suddenly became not so great. Nothing stops you from declaring that you expect a given type in Ruby; it's just code, and not mandatory, though you can certainly write code to impose mandatory types with Ruby - there was a while when writing those seemed a rite of passage for Ruby developers, but the reality was that they buy far less than people think until they've tried writing one and/or spent some time using them. > There's a better way to do it like what Rust does with Some()/None enums and forcing you to unwrap the value and handle the None value explicitly Nothing stops you from doing that in Ruby, and in fact there are several monad implementations for Ruby that provides building blocks for those kinds of patterns if/when you want to use them.

lamontcg 3y ago
> I'm not surprised you found Ruby uncomfortable when you describe Ruby as not having a type system. It might just not be the right language for you. That's fine. Thought we were supposed to "respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize" around here and not nitpick misstatements.
- vidarh 3y ago
  I did not suggest you believe that Ruby does not actually have a type system at all, but your statement to me still implies a view about the way Ruby treats typing that suggests to me that it is a fairly natural consequence you will find Ruby uncomfortable. There's no value judgment in that, nor nitpicking or criticism. Just an observation that Ruby might just not be right for you.
  - lamontcg 3y ago
    I'll take your suggestion along with my 12 years of professional experience with Ruby under advisement.

berkes 3y ago

I too wrote Ruby fulltime and professionally. For over a decade. The sheer amount of code I wrote, just to protect against nil-errors is staggering. Every third function or method had guard clauses and/or tests. Just to ensure that the data was in the expected shape (that it quacked and walked like a duck). I spent, I think, hundreds maybe thousand hours debugging actual production "nil-errors" and weird conversion errors. That happened in production. Sometimes legacy database records, sometimes weird race conditions causing corrupt data, sometimes (most often) just stupid mistakes by me or another dev. All of these -all!- would have been caught by a typing system and type checker like e.g. Rusts'. All. Which then leaves just the huge category of stupid bugs that I'll make in the business logic. But now, working with rust, the LSP tells within ms that I overlooked something that In Ruby would've been a data-error. Often my Ruby test suite would find these after minutes of running. Sometimes we would find them after deploying to prod and seeing havoc. Sometimes they'd take weeks before popping up. I'm convinced rust makes me develop much faster because of this.

vidarh 3y ago
If you need to test again nil "every third function or method", then that reflects broken abstractions and/or very dated Ruby. For "maybe nil" situations, modern Ruby code will lean heavily into safe navigation, dig, or wrapping values, and sometimes monads or similar. If that's not enough for you, Ruby has optional type checkers available.

raggi 3y ago

The position of “I regularly don’t know if I have a string or a uri” is indeed a commonly raised issue. It folds out to two other problems: It implies a lack of conventions around interfaces and variable names. The surrounding statement also implies that it was not easy to figure out quickly (hard to exercise that code synthetically). Highly successful workflows in loosely typed environments like this depend upon a strict culture to ensure both of these aspects are under constant improvement. This is difficult to scale, and improving these aspects in other languages also helps other workflows, but their impact in these environments is much higher. It’s part of the reason why you would hear _so much_, density wise, about code patterns, code health, testing and so on in the ecosystem in its peak era, all of those things were really just mechanisms to try to achieve the above factors.