4 ms·

I'm often curious as to what people are doing that makes them really think they need to venture outside their chosen scripting language. I use Ruby thinking I'l

I'm often curious as to what people are doing that makes them really think they need to venture outside their chosen scripting language. I use Ruby thinking I'll 'drop to Rust/Crystal' whenever I need to do something "serious", but that need never seems to manifest. Whatever I code in Ruby seems to just do the job and I can solve perf issues with asynchronous constructs like a jobs server, or something like caching. At this point I'm really starting to wonder if Ruby really is the One True Language and everyone's going to be using it in 100 years. Like how PG thought Arc would be the hundred-year language. Does static typing really offer that much more over dynamic? I'm not at all convinced that it does, when you get right down to it. Once Ruby gets a built-in typing system, we'll get to answer that question. I do believe that Ruby will eventually solve its perf problem and once it does, its pleasing syntax and semantics will just draw everyone back to it the same way it did the first time.

nlh 8y ago
I hear you, and I too love Ruby, and I too have yet to actually need the performance benefits of Crystal. But man, you don't realize how awesome static typing is until you actually start using it. There are whole classes of bugs that just get nixed before the program even runs. It makes you think more about how to structure things, how you're passing arguments, how you use variables, etc. Now maybe you're really really really good w/ Ruby and you don't make those mistakes anymore, but for an "advanced beginner" like myself, it's really helpful.
- vidarh 8y ago
  I came to Ruby from 20 years of working in statically typed languages, and I think it largely boils down to how you're used to working. E.g. you need test either way, and properly written tests reveal most of the same typing issues static typing does. I'd enjoy static typing if I didn't have to sacrifice the flexibility of Ruby, but so far I've yet to see a system with good-enough type inference to make up for the extra ceremony. I hope that will eventually change, but what I've seen of Crystal is not it.
  - tigershark 8y ago
    Which statically typed languages did you use in these 20 years? If you ever used Haskell/OCaml/F# it would seem a pretty strange declaration.
- vinceguidry 8y ago
  Yeah, I'm not saying it's not useful, and I can't wait to introduce static typing into my own programs and get those benefits. But every time I step away from Ruby I end up missing it more than the other language gives me. And this is after I figure out how the other language does what I'm trying to do. To me typing is something you don't want until you really want it, until then it's just boilerplate. That "class of bugs that just get nixed" isn't something that starts happening, once you're skilled anyway, until a certain point in the evolution of your application. There's a lot of code that I add to my Ruby classes that involves type-checking, and it would be nice to lean on a dedicated system for handling type abstractions rather than doing it ad-hoc every time I have to do it. For that reason, I'm greatly looking forward to Ruby's upcoming type system.
- crimsonalucard 8y ago
  He's more beginner then you. Calling ruby the one true language after it's been losing traction for years indicates to me he probably just started.
  - vinceguidry 8y ago
    I've been coding since I was 9 years old, made my first web page at 15, I'm 34 now, having been a pro web dev for 5 years. I'm no greybeard, but I'm definitely not a beginner. And I stand by my assertion. Programming languages come and go. I've been watching it happen for over a decade. Ruby's the one language that transcends the normal reasons why they do that. Other languages fit hardware or chosen domains better or worse, those are the reasons why you'd choose one or the other. Ruby's the only language that fits the mind better.
    - CrystalLangUser 8y ago
      Good thing Crystal based its syntax off of Ruby then. And it's statically typed, thank god. I do professional work in Ruby currently, but Crystal is just so much more pleasant to work with.
    - hota_mazi 8y ago
      But surely you see that Ruby has been on a steady decline for ten years, and with RoR falling out of grace, that decline is accelerating.
      - vidarh 8y ago
        For me the last decade has been one of seeing steadily increasing demand for my Ruby skills, and I don't do Rails at all. So if Ruby is "on a steady decline" someone forgot to tell my customers and employers.
        crimsonalucard 8y ago
        You live in a bubble. Look up some numbers. From an empirical standpoint ruby is dying. Of course your anecdotal experience trumps all the numbers so my point is invalid.
atombender 8y ago
Former Ruby developer here. I believe we will look back at this period where we eschewed static typing as a historical mistake. Back in the 2000s I was using mostly statically typed languages (Java, C/C++, ObjectPascal), and compared to those, Ruby and Rails seemed like incredible productivity boosters. But we quickly found that the lack of typing led to all sorts of issues. For one, you need really comprehensive tests to determine whether a change breaks anything. Refactoring becomes not just a chore, but genuinely psychologically stressful as you begin to worry about things breaking in production. And they frequently do. Duck typing is elegant, but it only works so far as you know the range of types to expect. I very quickly got tired of checking the validity of arguments in code and doing coercion such as Array(maybe_array_or_maybe_not). And the nils, ugh. I never created so many bugs as when I was writing Ruby code (though JavaScript is a close second). A language with a rich type system (Haskell, Swift and Rust come to mind) can eliminate entire classes of bugs. Not just by letting you validate the types of arguments and return values, but by letting you describe your program logic in terms of types. It's often said that Haskell programs rarely have bugs once they compile, and while there are no guarantees, it's often true. Give a statically typed language a try for a while, and you will probably change your mind. I don't know about Crystal, but Go is a decent entry-level language. (Many former Ruby devs seem to enjoy Go quite a bit.)
- vinceguidry 8y ago
  I'm looking forward to Ruby's upcoming type system. But for now I have no problems leaning on discipline for handling the problems dynamic typing introduces.
  - tigershark 8y ago
    You remind me of all the people that 10 years ago were saying that they don’t need tests because they have the discipline to write correct code...
- kjeetgill 8y ago
  > Refactoring becomes not just a chore, but genuinely psychologically stressful as you begin to worry about things breaking in production. And they frequently do. Beautifully put. The ability refactor confidently is so underrated. It's one of the places where a little bit of verbosity (i.e. Java) pays huge dividends. > Duck typing is elegant, but it only works so far as you know the range of types to expect. Go shines particularly well here. In Java code bases, interfaces occasionally accumulate too many methods or interfaces of interfaces start to get unwieldy. I like Go's approach of letting the function declare the relevant subinterface it really needs.
calibas 8y ago
In my opinion, "1" + 1 should throw an error, the compiler shouldn't try to interpret what you meant. Dynamic typing opens you up to all sorts of bugs that don't happen with static. That being said, I don't think dynamic typing is going anywhere, and with experience it's not that difficult to anticipate the problems that come with dynamic typing.
- deleted 8y ago
  [deleted]
- vinceguidry 8y ago
  It really isn't all that difficult. Coercion works fine for the case you cited, and especially Ruby has specific idiomatic coercion methods with the semantics you'd want. Ruby does in fact throw a TypeError when you call "1" + 1. The issue is that static typing purists want that error to be thrown at compile time. I don't see that as necessary. Either you have good discipline regarding types where you need it or you don't. And discipline in your coding extends to way more than just type errors. So anything encouraging to develop your discipline is a good thing. I think what it comes down to is, not having dynamic typing available to me when I want it is going to be more painful overall than not having a type system when I want it. I look at all the static languages today and I see so much validation of this idea that it's not even funny.
  - sullyj3 8y ago
    > Either you have good discipline regarding types where you need it or you don't. And discipline in your coding extends to way more than just type errors. So anything encouraging to develop your discipline is a good thing. I think this is maybe the crux of the difference of opinion between static and dynamic afficianados. I don't want to have to be disciplined. I want to be able to offload as much of the thinking as I possibly can onto my tools. The reason this is necessary is that I'm human, and I only have a human level capacity to not screw things up. If everything is the responsibility of the programmer, then we are limited in our ability to build large complex systems, to the ability of the programmer to manage this complexity. The only way to transcend this human limitation is to put measures in place to prevent things from falling over when humans turn out to be human after all.
danenania 8y ago
It completely depends on your goals. If your primary goal is to build a solid, reasonably scalable web app in a short amount of time, ruby and rails simply cannot be beat. But if you’re trying to push the envelope somehow on performance, concurrency, safety, number-crunching, or system design, or you need a portable binary, then it makes sense to choose a language that has tools and abstractions better suited for those tasks.
- vinceguidry 8y ago
  Ruby's poor at portability, but that's a solvable problem. For everything else, Ruby's got advantages. It really can't be beat regarding safety. Performance can be fixed with native extensions, which ironically are a large source of the portability problems. It's not as good at concurrency as say, Erlang, but it's got the primitives you need and they are first-class parts of the language. Number crunching is just an application and Ruby excels at application building. Just don't ask for a native interface, lol. Shoes is great and all, but it's just a baby.
losteric 8y ago
I think it's a toss up between Python and Ruby, but my bet is on Python. Python is simple by design. It has optional typing (as of 3.6), beautiful async constructs (ala ES6), nice integration with C/assembly (in CPython), comprehensive open-source software ecosystem, and many strong alternative interpreters. Ruby feels like it's playing catch-up in every area except metaprogramming... and, while I really enjoyed metaprogramming as an experienced engineer, I'm kinda glad Python lacks that complexity.
- bmarkovic 8y ago
  > I think it's a toss up between Python and Ruby, but my bet is on Python What on earth could make you people think Ruby is even a contender? Do you ever look at ANY language usage stats? If there is a toss-up in dynamic languages the toss-up is between Python and JavaScript and with JavaScript's dominance in the front-end and Python's in data science it's likely to be a turf divide rather than a toss-up.
  - filleduchaos 8y ago
    Do you have any idea what things use Ruby outside of web dev?
    - bmarkovic 8y ago
      That doesn't really matter to my arguments. I've used front-end and back-end web dev merely as examples of main drivers of each technology. What matters is that growth of Ruby and related technologies in recent years has been negligible (it has been in free-fall for the last few when considering relative figures actually), and the singular instance of it's major growth was during the 37Signals/Rails era ergo web dev.
dragonwriter 8y ago
> Does static typing really offer that much more over dynamic? Yes, but it comes with a heavy trade-off if you have an insufficiently expressive type system and/or an excessive need for explicit incantations to the type checker.
flavio81 8y ago
As a user of Common Lisp that is lately learning Ruby, i am amazed at how weak the type system is and how many stuff that would immediately cause a compiler error in Lisp (like asking values from class members that don't exist) simply pass silently with no error (not even at runtime) in Ruby. Since every call is a method, and a method belongs to an object, the type of this object is significant. Base Ruby language gives you no way to declare that object X shall be of class C. So, well, there are dynamic languages and there are dynamic languages.

nlh 8y ago

I hear you, and I too love Ruby, and I too have yet to actually need the performance benefits of Crystal. But man, you don't realize how awesome static typing is until you actually start using it. There are whole classes of bugs that just get nixed before the program even runs. It makes you think more about how to structure things, how you're passing arguments, how you use variables, etc. Now maybe you're really really really good w/ Ruby and you don't make those mistakes anymore, but for an "advanced beginner" like myself, it's really helpful.

vidarh 8y ago
I came to Ruby from 20 years of working in statically typed languages, and I think it largely boils down to how you're used to working. E.g. you need test either way, and properly written tests reveal most of the same typing issues static typing does. I'd enjoy static typing if I didn't have to sacrifice the flexibility of Ruby, but so far I've yet to see a system with good-enough type inference to make up for the extra ceremony. I hope that will eventually change, but what I've seen of Crystal is not it.
- tigershark 8y ago
  Which statically typed languages did you use in these 20 years? If you ever used Haskell/OCaml/F# it would seem a pretty strange declaration.
vinceguidry 8y ago
Yeah, I'm not saying it's not useful, and I can't wait to introduce static typing into my own programs and get those benefits. But every time I step away from Ruby I end up missing it more than the other language gives me. And this is after I figure out how the other language does what I'm trying to do. To me typing is something you don't want until you really want it, until then it's just boilerplate. That "class of bugs that just get nixed" isn't something that starts happening, once you're skilled anyway, until a certain point in the evolution of your application. There's a lot of code that I add to my Ruby classes that involves type-checking, and it would be nice to lean on a dedicated system for handling type abstractions rather than doing it ad-hoc every time I have to do it. For that reason, I'm greatly looking forward to Ruby's upcoming type system.
crimsonalucard 8y ago
He's more beginner then you. Calling ruby the one true language after it's been losing traction for years indicates to me he probably just started.
- vinceguidry 8y ago
  I've been coding since I was 9 years old, made my first web page at 15, I'm 34 now, having been a pro web dev for 5 years. I'm no greybeard, but I'm definitely not a beginner. And I stand by my assertion. Programming languages come and go. I've been watching it happen for over a decade. Ruby's the one language that transcends the normal reasons why they do that. Other languages fit hardware or chosen domains better or worse, those are the reasons why you'd choose one or the other. Ruby's the only language that fits the mind better.
  - CrystalLangUser 8y ago
    Good thing Crystal based its syntax off of Ruby then. And it's statically typed, thank god. I do professional work in Ruby currently, but Crystal is just so much more pleasant to work with.
  - hota_mazi 8y ago
    But surely you see that Ruby has been on a steady decline for ten years, and with RoR falling out of grace, that decline is accelerating.
    - vidarh 8y ago
      For me the last decade has been one of seeing steadily increasing demand for my Ruby skills, and I don't do Rails at all. So if Ruby is "on a steady decline" someone forgot to tell my customers and employers.
      - crimsonalucard 8y ago
        You live in a bubble. Look up some numbers. From an empirical standpoint ruby is dying. Of course your anecdotal experience trumps all the numbers so my point is invalid.

atombender 8y ago

Former Ruby developer here. I believe we will look back at this period where we eschewed static typing as a historical mistake. Back in the 2000s I was using mostly statically typed languages (Java, C/C++, ObjectPascal), and compared to those, Ruby and Rails seemed like incredible productivity boosters. But we quickly found that the lack of typing led to all sorts of issues. For one, you need really comprehensive tests to determine whether a change breaks anything. Refactoring becomes not just a chore, but genuinely psychologically stressful as you begin to worry about things breaking in production. And they frequently do. Duck typing is elegant, but it only works so far as you know the range of types to expect. I very quickly got tired of checking the validity of arguments in code and doing coercion such as Array(maybe_array_or_maybe_not). And the nils, ugh. I never created so many bugs as when I was writing Ruby code (though JavaScript is a close second). A language with a rich type system (Haskell, Swift and Rust come to mind) can eliminate entire classes of bugs. Not just by letting you validate the types of arguments and return values, but by letting you describe your program logic in terms of types. It's often said that Haskell programs rarely have bugs once they compile, and while there are no guarantees, it's often true. Give a statically typed language a try for a while, and you will probably change your mind. I don't know about Crystal, but Go is a decent entry-level language. (Many former Ruby devs seem to enjoy Go quite a bit.)

vinceguidry 8y ago
I'm looking forward to Ruby's upcoming type system. But for now I have no problems leaning on discipline for handling the problems dynamic typing introduces.
- tigershark 8y ago
  You remind me of all the people that 10 years ago were saying that they don’t need tests because they have the discipline to write correct code...
kjeetgill 8y ago
> Refactoring becomes not just a chore, but genuinely psychologically stressful as you begin to worry about things breaking in production. And they frequently do. Beautifully put. The ability refactor confidently is so underrated. It's one of the places where a little bit of verbosity (i.e. Java) pays huge dividends. > Duck typing is elegant, but it only works so far as you know the range of types to expect. Go shines particularly well here. In Java code bases, interfaces occasionally accumulate too many methods or interfaces of interfaces start to get unwieldy. I like Go's approach of letting the function declare the relevant subinterface it really needs.

calibas 8y ago

In my opinion, "1" + 1 should throw an error, the compiler shouldn't try to interpret what you meant. Dynamic typing opens you up to all sorts of bugs that don't happen with static. That being said, I don't think dynamic typing is going anywhere, and with experience it's not that difficult to anticipate the problems that come with dynamic typing.

deleted 8y ago
[deleted]
vinceguidry 8y ago
It really isn't all that difficult. Coercion works fine for the case you cited, and especially Ruby has specific idiomatic coercion methods with the semantics you'd want. Ruby does in fact throw a TypeError when you call "1" + 1. The issue is that static typing purists want that error to be thrown at compile time. I don't see that as necessary. Either you have good discipline regarding types where you need it or you don't. And discipline in your coding extends to way more than just type errors. So anything encouraging to develop your discipline is a good thing. I think what it comes down to is, not having dynamic typing available to me when I want it is going to be more painful overall than not having a type system when I want it. I look at all the static languages today and I see so much validation of this idea that it's not even funny.
- sullyj3 8y ago
  > Either you have good discipline regarding types where you need it or you don't. And discipline in your coding extends to way more than just type errors. So anything encouraging to develop your discipline is a good thing. I think this is maybe the crux of the difference of opinion between static and dynamic afficianados. I don't want to have to be disciplined. I want to be able to offload as much of the thinking as I possibly can onto my tools. The reason this is necessary is that I'm human, and I only have a human level capacity to not screw things up. If everything is the responsibility of the programmer, then we are limited in our ability to build large complex systems, to the ability of the programmer to manage this complexity. The only way to transcend this human limitation is to put measures in place to prevent things from falling over when humans turn out to be human after all.

danenania 8y ago

It completely depends on your goals. If your primary goal is to build a solid, reasonably scalable web app in a short amount of time, ruby and rails simply cannot be beat. But if you’re trying to push the envelope somehow on performance, concurrency, safety, number-crunching, or system design, or you need a portable binary, then it makes sense to choose a language that has tools and abstractions better suited for those tasks.

vinceguidry 8y ago
Ruby's poor at portability, but that's a solvable problem. For everything else, Ruby's got advantages. It really can't be beat regarding safety. Performance can be fixed with native extensions, which ironically are a large source of the portability problems. It's not as good at concurrency as say, Erlang, but it's got the primitives you need and they are first-class parts of the language. Number crunching is just an application and Ruby excels at application building. Just don't ask for a native interface, lol. Shoes is great and all, but it's just a baby.

losteric 8y ago

I think it's a toss up between Python and Ruby, but my bet is on Python. Python is simple by design. It has optional typing (as of 3.6), beautiful async constructs (ala ES6), nice integration with C/assembly (in CPython), comprehensive open-source software ecosystem, and many strong alternative interpreters. Ruby feels like it's playing catch-up in every area except metaprogramming... and, while I really enjoyed metaprogramming as an experienced engineer, I'm kinda glad Python lacks that complexity.

bmarkovic 8y ago
> I think it's a toss up between Python and Ruby, but my bet is on Python What on earth could make you people think Ruby is even a contender? Do you ever look at ANY language usage stats? If there is a toss-up in dynamic languages the toss-up is between Python and JavaScript and with JavaScript's dominance in the front-end and Python's in data science it's likely to be a turf divide rather than a toss-up.
- filleduchaos 8y ago
  Do you have any idea what things use Ruby outside of web dev?
  - bmarkovic 8y ago
    That doesn't really matter to my arguments. I've used front-end and back-end web dev merely as examples of main drivers of each technology. What matters is that growth of Ruby and related technologies in recent years has been negligible (it has been in free-fall for the last few when considering relative figures actually), and the singular instance of it's major growth was during the 37Signals/Rails era ergo web dev.

dragonwriter 8y ago

> Does static typing really offer that much more over dynamic? Yes, but it comes with a heavy trade-off if you have an insufficiently expressive type system and/or an excessive need for explicit incantations to the type checker.

flavio81 8y ago

As a user of Common Lisp that is lately learning Ruby, i am amazed at how weak the type system is and how many stuff that would immediately cause a compiler error in Lisp (like asking values from class members that don't exist) simply pass silently with no error (not even at runtime) in Ruby. Since every call is a method, and a method belongs to an object, the type of this object is significant. Base Ruby language gives you no way to declare that object X shall be of class C. So, well, there are dynamic languages and there are dynamic languages.