12 ms·

Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or somet

Honestly I don't get why some people want to move to static types. Ruby is a dynamic language, that's the point of it... Giant orgs can just use Java or something. We need some languages to stay productive for those of us who work solo or in small groups. If I wanted static types I'd use Java, Go or something (probably Haskell).

muglug 5y ago
By the time they get giant with [interpreted language], the giant org cannot pivot to Java without sacrificing a year of forward momentum on product development. It's far easier for them to adopt a static analysis tool that mimics the type safety that Java provides than to migrate their codebase.
mwint 5y ago
Mostly, I really want Rails in a typed language.
- Mikeb85 5y ago
  There's a reason it didn't come from a typed language... It uses a lot of dynamic features and metaprogramming.
- kayodelycaon 5y ago
  That would be nice. There are so many attempt to clone it and the clones are always missing some important piece of what makes rails rails. Lack of good, heavily integrated libraries is a universal failure of all of the ones I’ve seen.
- truly_not_next 5y ago
  Redwood does this in TypeScript
- abstract_put 5y ago
  This is the most frustrating part - having worked in an enterprise Rails project, I wouldn't wish that on anyone valuing their own time. At the same time, it is the most complete offering I've used by a long shot for getting started. I was writing a web app in Rust (I want to be cool!) and only after a couple hours of implementing CRUD did I realize I'd effectively made an inconsistently implemented rails scaffolding. The default opinionated round trip for DB -> application -> UI for CRUD is still really slick.
eropple 5y ago
This is a set of statements that strike me as pretty unreflective of the state of things these days. I have slung a lot of Ruby in my life and I literally-not-figuratively stopped the second I laid my hands on TypeScript because we've hit the point where gradual static typing is both easily available and super easy to work with. (And there's also Rust, which can scratch a whole different set of itches that I don't happen to personally have.) If your idea of static typing is Java or Go or "something", if your idea of it is that it's for "giant orgs" and not improving your own correctness and throughput of code (I write better code, faster, in TypeScript than I ever did in Ruby!), yeah, it might not make sense. But that's a pretty out-of-date take, I think, and the wins the suitably plastic individual can get, even on a solo or small-team project, are significant.
- Mikeb85 5y ago
  The static languages I've used most are actually Haskell and recently Pony (mostly for things that involve a bunch of maths and processing in parallel). Just brought Go/Java up because it seems everyone is trying to turn every language into those. I don't want Ruby to become another TS because I'd use a typed language if I wanted one. The problems I use Ruby for don't need the speed of a statically typed language and it's nice using a dynamic one for.
  - abstract_put 5y ago
    I think what the parent comment is saying (that I agree with) is that it's easy to over-estimate the cost and under-estimate the value. You don't _have_ to do anything with types, but it's another tool to use where it makes sense. Or put another way, provided it's not mandatory what's the downside to having another tool in the toolbox?
    - Mikeb85 5y ago
      The downside is the ecosystem turning into the JS/TS ecosystem. Where the zealots have pushed TS to the point it all just looks like C# and what makes JS nice is being lost.
austinthetaco 5y ago
I really feel the same about javascript with typescript. It feels a heck of a lot like new grads or old c#/java devs trying to keep up with the times by switching to javascript, but then resisting the code structure and loose typings.
- tmh88j 5y ago
  That seems to be more in line with "what's the benefit of static types?" than "what benefit does JS get from static types?". JavaScript is not only a very different language than it was 15+ years ago, but also takes up a significantly higher percentage of an app's codebase. The web is a drastically different place than when JS was created.
  - austinthetaco 5y ago
    it taking up more of an app's code doesn't mean that it suddenly has a need for typing. but even then, that assertion is incorrect, javascript has been making up a large majority of the codebase for quite some time now. Nodejs is 12 years old and jquery 15. That argument is one that could've been made like 9 years ago, but even then, multiple projects have tried adding typing and the javascript community strongly rejected it (heck typescript was pushing for it in 2014). Anecdotally, I've met considerably more and more developers coming from C# projects who are being made to do frontend work or find work in the javascript world, who seem to be very intent on pushing for typescript in their orgs.
    - tmh88j 5y ago
      > but even then, that assertion is incorrect, javascript has been making up a large majority of the codebase for quite some time now. Nodejs is 12 years old and jquery 15. That argument is one that could've been made like 9 years ago, Typescript is 9 years old. React was still a project then and Angular was brand new. SPA's were still a new-ish concept then. JS was not used as widely 10 years ago as it is now, thanks to SPA's. The web was a drastically different place back then. I am not at all saying that TypeScript should always be used, far from that. I just think it has a valid spot in the world of web development.
whakim 5y ago
Ruby isn't forcing you to use static types. That being said, I actually think something like Sorbet makes even solo/small teams more productive because it trades some additional time writing boilerplate for dramatically reducing the number of bugs you write.
- zomgwat 5y ago
  This has been my experience using Sorbet. I sometimes get annoyed when I get stuck screwing around with the RBI files. Then I get in the flow and remember how fast Sorbet allows me to move.
- BurningFrog 5y ago
  A good test suite is better at keeping the code bug free. Not needing types is another benefit of good testing. That's my experience, at least.
  - emodendroket 5y ago
    I think people remembering to test all the typing-related corner cases is never going to come close to being as effective as something enforced by static checking -- and even if it did, it seems like I've lost all the time I saved and then some, if that's the price of not having to write the declarations.
  - abstract_put 5y ago
    Do you think it's possible for well used types to displace the need for some tests?
    - JohnBooty 5y ago
      I'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice." What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing? You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tries to actually do something with those improper argument(s). I suppose it could be useful in cases where you'd stubbed out B in your specs, but ehhhh.
friedman23 5y ago
> Honestly I don't get why some people want to move to static types I don't understand how anyone that has experience with dynamically typed languages and the insane runtime errors that can result from them would ever consider using a dynamically typed language. It's terrible and it actually provides little to no benefit in development speed. People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time. Given the popularity of typescript and how nearly all major internet companies have moved to typed versions of their dynamically typed languages it's clear to me the whole dynamic typing experiment has failed absolutely miserably.
- Mikeb85 5y ago
  > People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time. You just develop on the running program... If you just write it in your editor, run, check for errors, stop, edit more, run, stop, etc... then yes, you don't gain anything.
  - friedman23 5y ago
    > You just develop on the running program... Ah yes, don't worry about correctness at all, just wing it. I take it you haven't had to debug some of the stuff you've written?
    - DeathArrow 5y ago
      >I take it you haven't had to debug some of the stuff you've written? Most Ruby devs work as contractors. They deliver the software and go to the next paying contract. They don't have to live with their software. :)
    - Mikeb85 5y ago
      You asked about the productivity boost... Well it's in being able to code, debug, etc... a running program. Did you miss a decade or two of CS history? Lisp and Smalltalk have been around long enough that the value of programming with dynamic languages is known... I mean, there's shaceships and whatnot running on Lisp. Or did CS simply start and end with Java?
sankha93 5y ago
Ruby is and will be the same language even after static types. A Ruby programmer will need to opt-in to writing type annotations in an external file and run a separate type checker (that is not a part of MRI binary). The benefit is if libraries ship with type definitions, type inference can detect type errors early in the IDE. If no type definitions are available, you do not get ahead of runtime type errors.
emodendroket 5y ago
Probably they got sick of having to read a function body (and maybe a couple levels of indirection from there) to figure out what the hell a method returns while doing maintenance programming on a hoary old Ruby codebase.
humbleMouse 5y ago
Java 11+ supports declaring variables with “var”...
hsn915 5y ago
I started using dynamic languages since around 2008 (Python and Javascript). Before that I was more into C/C++. Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs. What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to start making programs. Programming basically became dreadful. I taught myself to wade through it anyway, convinced I would find the joy again when I get more proficient. What eventually made me redisocver the joy of Programming is switching to procedural programming and static typing. First it was with Typescript. Now with Go. Writing programs with just structs and functions is really enjoyable. Programming in dynamically typed languages is dreadful. There's no joy in it.
- ngc248 5y ago
  Dynamic languages start becoming problematic as more the size of the codebase increases. It becomes very hard to maintain.
  - sparker72678 5y ago
    Use whatever language you want; there is no large codebase that's easy to maintain.
    - ngc248 5y ago
      I agree, but maintaining a large codebase in a statically typed language as compared to a dynamic language is magnitudes easier. As the codebase grows larger, if people dont have the discipline to write proper code, the code will get more and more complicated since you will not know what exactly you will get. Mostly dynamic languages are easy to get into (which is a strength) but this becomes a weakness as the project becomes larger.
- mykowebhn 5y ago
  Have you wrangled with JSON using Go? Absolutely dreadful. Have you written multiple microservices in Go? The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code. The learning-curve to understand how each service's code is organized gets old fast. With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic. When writing one-off scripts, I can see the advantages of dealing with just structs and functions.
MeinBlutIstBlau 5y ago
Static typing is awesome because I don't have to just "know" what's being passed in, I can see exactly the structure of it right there. The nice thing too is that another person who has never touched the code can know this as well without reading the entire code base. Dynamic languages are fine for quick and dirty stuff. For full fledged software, they still make things too difficult to maintain. Javascript to me personally at least attempts to address this with Typescript.
joelbluminator 5y ago
Ruby is NOT becoming static. It will just have tools like Sorbet or rbs files. The community will for sure stay mostly in dynamic programming. The huge orgs like Shopify or Stripe who want more strictness will now be able to do it in their Ruby codebases.
sanderjd 5y ago
It is possible to be very productive in a language with a static type system. In my view, it is actually much easier.
vidarh 5y ago
I don't want a move to enforced static typing everywhere in Ruby. But rbs is relatively non-intrusive. Having the standard library covered by it, and allowing people to tighten up things where they make sense makes it less cumbersome to avoid elsewhere. And it allows those people who feel they need to have type hints everywhere in their IDE to still use Ruby. I find it clutters things up more than it helps, but if it helps others then that's great. I'm slightly concerned that people will overdo it. E.g. I've more than once wanted to pass an input to something that enforced stricter typing than necessary via guards e.g. checking its input with #kind_of? when it otherwise only needed a class that implemented a sensible #read (for example). But Rubyists are pragmatic - I think after a period of overzealous annotations (the way people went totally overboard with monkey patching for a while) most people will keep the type declarations just loose enough.
mabbo 5y ago
Static typing is like an automatic test for a specific category of errors- type errors. That's why it's useful. Ruby's choice of making it optional means folks like yourself who want to move fast and break things are welcome to do so, but those of us working on more mature systems that need the reliability and lack of bugs can add this on and get the safety.
- Mikeb85 5y ago
  Ruby is strongly typed anyway... The runtime complains if you mis-type something just as a compiler would complain. In fact, linters just catch it as you type (plus any other typos). Mixing it up with JS (which is weakly typed)?

muglug 5y ago

By the time they get giant with [interpreted language], the giant org cannot pivot to Java without sacrificing a year of forward momentum on product development. It's far easier for them to adopt a static analysis tool that mimics the type safety that Java provides than to migrate their codebase.

mwint 5y ago

Mostly, I really want Rails in a typed language.

Mikeb85 5y ago
There's a reason it didn't come from a typed language... It uses a lot of dynamic features and metaprogramming.
kayodelycaon 5y ago
That would be nice. There are so many attempt to clone it and the clones are always missing some important piece of what makes rails rails. Lack of good, heavily integrated libraries is a universal failure of all of the ones I’ve seen.
truly_not_next 5y ago
Redwood does this in TypeScript
abstract_put 5y ago
This is the most frustrating part - having worked in an enterprise Rails project, I wouldn't wish that on anyone valuing their own time. At the same time, it is the most complete offering I've used by a long shot for getting started. I was writing a web app in Rust (I want to be cool!) and only after a couple hours of implementing CRUD did I realize I'd effectively made an inconsistently implemented rails scaffolding. The default opinionated round trip for DB -> application -> UI for CRUD is still really slick.

eropple 5y ago

This is a set of statements that strike me as pretty unreflective of the state of things these days. I have slung a lot of Ruby in my life and I literally-not-figuratively stopped the second I laid my hands on TypeScript because we've hit the point where gradual static typing is both easily available and super easy to work with. (And there's also Rust, which can scratch a whole different set of itches that I don't happen to personally have.) If your idea of static typing is Java or Go or "something", if your idea of it is that it's for "giant orgs" and not improving your own correctness and throughput of code (I write better code, faster, in TypeScript than I ever did in Ruby!), yeah, it might not make sense. But that's a pretty out-of-date take, I think, and the wins the suitably plastic individual can get, even on a solo or small-team project, are significant.

Mikeb85 5y ago
The static languages I've used most are actually Haskell and recently Pony (mostly for things that involve a bunch of maths and processing in parallel). Just brought Go/Java up because it seems everyone is trying to turn every language into those. I don't want Ruby to become another TS because I'd use a typed language if I wanted one. The problems I use Ruby for don't need the speed of a statically typed language and it's nice using a dynamic one for.
- abstract_put 5y ago
  I think what the parent comment is saying (that I agree with) is that it's easy to over-estimate the cost and under-estimate the value. You don't _have_ to do anything with types, but it's another tool to use where it makes sense. Or put another way, provided it's not mandatory what's the downside to having another tool in the toolbox?
  - Mikeb85 5y ago
    The downside is the ecosystem turning into the JS/TS ecosystem. Where the zealots have pushed TS to the point it all just looks like C# and what makes JS nice is being lost.

austinthetaco 5y ago

I really feel the same about javascript with typescript. It feels a heck of a lot like new grads or old c#/java devs trying to keep up with the times by switching to javascript, but then resisting the code structure and loose typings.

tmh88j 5y ago
That seems to be more in line with "what's the benefit of static types?" than "what benefit does JS get from static types?". JavaScript is not only a very different language than it was 15+ years ago, but also takes up a significantly higher percentage of an app's codebase. The web is a drastically different place than when JS was created.
- austinthetaco 5y ago
  it taking up more of an app's code doesn't mean that it suddenly has a need for typing. but even then, that assertion is incorrect, javascript has been making up a large majority of the codebase for quite some time now. Nodejs is 12 years old and jquery 15. That argument is one that could've been made like 9 years ago, but even then, multiple projects have tried adding typing and the javascript community strongly rejected it (heck typescript was pushing for it in 2014). Anecdotally, I've met considerably more and more developers coming from C# projects who are being made to do frontend work or find work in the javascript world, who seem to be very intent on pushing for typescript in their orgs.
  - tmh88j 5y ago
    > but even then, that assertion is incorrect, javascript has been making up a large majority of the codebase for quite some time now. Nodejs is 12 years old and jquery 15. That argument is one that could've been made like 9 years ago, Typescript is 9 years old. React was still a project then and Angular was brand new. SPA's were still a new-ish concept then. JS was not used as widely 10 years ago as it is now, thanks to SPA's. The web was a drastically different place back then. I am not at all saying that TypeScript should always be used, far from that. I just think it has a valid spot in the world of web development.

whakim 5y ago

Ruby isn't forcing you to use static types. That being said, I actually think something like Sorbet makes even solo/small teams more productive because it trades some additional time writing boilerplate for dramatically reducing the number of bugs you write.

zomgwat 5y ago
This has been my experience using Sorbet. I sometimes get annoyed when I get stuck screwing around with the RBI files. Then I get in the flow and remember how fast Sorbet allows me to move.
BurningFrog 5y ago
A good test suite is better at keeping the code bug free. Not needing types is another benefit of good testing. That's my experience, at least.
- emodendroket 5y ago
  I think people remembering to test all the typing-related corner cases is never going to come close to being as effective as something enforced by static checking -- and even if it did, it seems like I've lost all the time I saved and then some, if that's the price of not having to write the declarations.
- abstract_put 5y ago
  Do you think it's possible for well used types to displace the need for some tests?
  - JohnBooty 5y ago
    I'm not the person you're responding to, but I would say: "yeah, but it'd probably be bad practice." What would you be testing for, exactly? That `SomeClass#some_method` raises a `NoMethodError` when you pass it the wrong thing? You could test for that, but I don't think that would be a good use of code or your time. If A is passing the wrong things to B, your specs will fail anyway on that `NoMethodError` once B tries to actually do something with those improper argument(s). I suppose it could be useful in cases where you'd stubbed out B in your specs, but ehhhh.

friedman23 5y ago

> Honestly I don't get why some people want to move to static types I don't understand how anyone that has experience with dynamically typed languages and the insane runtime errors that can result from them would ever consider using a dynamically typed language. It's terrible and it actually provides little to no benefit in development speed. People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time. Given the popularity of typescript and how nearly all major internet companies have moved to typed versions of their dynamically typed languages it's clear to me the whole dynamic typing experiment has failed absolutely miserably.

Mikeb85 5y ago
> People always say development is faster in a dynamically typed language, this is not my experience. You need to actually run the program and step into it with a debugger in order to determine the type of anything at run time. You just develop on the running program... If you just write it in your editor, run, check for errors, stop, edit more, run, stop, etc... then yes, you don't gain anything.
- friedman23 5y ago
  > You just develop on the running program... Ah yes, don't worry about correctness at all, just wing it. I take it you haven't had to debug some of the stuff you've written?
  - DeathArrow 5y ago
    >I take it you haven't had to debug some of the stuff you've written? Most Ruby devs work as contractors. They deliver the software and go to the next paying contract. They don't have to live with their software. :)
  - Mikeb85 5y ago
    You asked about the productivity boost... Well it's in being able to code, debug, etc... a running program. Did you miss a decade or two of CS history? Lisp and Smalltalk have been around long enough that the value of programming with dynamic languages is known... I mean, there's shaceships and whatnot running on Lisp. Or did CS simply start and end with Java?

sankha93 5y ago

Ruby is and will be the same language even after static types. A Ruby programmer will need to opt-in to writing type annotations in an external file and run a separate type checker (that is not a part of MRI binary). The benefit is if libraries ship with type definitions, type inference can detect type errors early in the IDE. If no type definitions are available, you do not get ahead of runtime type errors.

emodendroket 5y ago

Probably they got sick of having to read a function body (and maybe a couple levels of indirection from there) to figure out what the hell a method returns while doing maintenance programming on a hoary old Ruby codebase.

humbleMouse 5y ago

Java 11+ supports declaring variables with “var”...

hsn915 5y ago

I started using dynamic languages since around 2008 (Python and Javascript). Before that I was more into C/C++. Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs. What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to start making programs. Programming basically became dreadful. I taught myself to wade through it anyway, convinced I would find the joy again when I get more proficient. What eventually made me redisocver the joy of Programming is switching to procedural programming and static typing. First it was with Typescript. Now with Go. Writing programs with just structs and functions is really enjoyable. Programming in dynamically typed languages is dreadful. There's no joy in it.

ngc248 5y ago
Dynamic languages start becoming problematic as more the size of the codebase increases. It becomes very hard to maintain.
- sparker72678 5y ago
  Use whatever language you want; there is no large codebase that's easy to maintain.
  - ngc248 5y ago
    I agree, but maintaining a large codebase in a statically typed language as compared to a dynamic language is magnitudes easier. As the codebase grows larger, if people dont have the discipline to write proper code, the code will get more and more complicated since you will not know what exactly you will get. Mostly dynamic languages are easy to get into (which is a strength) but this becomes a weakness as the project becomes larger.
mykowebhn 5y ago
Have you wrangled with JSON using Go? Absolutely dreadful. Have you written multiple microservices in Go? The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code. The learning-curve to understand how each service's code is organized gets old fast. With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic. When writing one-off scripts, I can see the advantages of dealing with just structs and functions.

MeinBlutIstBlau 5y ago

Static typing is awesome because I don't have to just "know" what's being passed in, I can see exactly the structure of it right there. The nice thing too is that another person who has never touched the code can know this as well without reading the entire code base. Dynamic languages are fine for quick and dirty stuff. For full fledged software, they still make things too difficult to maintain. Javascript to me personally at least attempts to address this with Typescript.

joelbluminator 5y ago

Ruby is NOT becoming static. It will just have tools like Sorbet or rbs files. The community will for sure stay mostly in dynamic programming. The huge orgs like Shopify or Stripe who want more strictness will now be able to do it in their Ruby codebases.

sanderjd 5y ago

It is possible to be very productive in a language with a static type system. In my view, it is actually much easier.

vidarh 5y ago

I don't want a move to enforced static typing everywhere in Ruby. But rbs is relatively non-intrusive. Having the standard library covered by it, and allowing people to tighten up things where they make sense makes it less cumbersome to avoid elsewhere. And it allows those people who feel they need to have type hints everywhere in their IDE to still use Ruby. I find it clutters things up more than it helps, but if it helps others then that's great. I'm slightly concerned that people will overdo it. E.g. I've more than once wanted to pass an input to something that enforced stricter typing than necessary via guards e.g. checking its input with #kind_of? when it otherwise only needed a class that implemented a sensible #read (for example). But Rubyists are pragmatic - I think after a period of overzealous annotations (the way people went totally overboard with monkey patching for a while) most people will keep the type declarations just loose enough.

mabbo 5y ago

Static typing is like an automatic test for a specific category of errors- type errors. That's why it's useful. Ruby's choice of making it optional means folks like yourself who want to move fast and break things are welcome to do so, but those of us working on more mature systems that need the reliability and lack of bugs can add this on and get the safety.

Mikeb85 5y ago
Ruby is strongly typed anyway... The runtime complains if you mis-type something just as a compiler would complain. In fact, linters just catch it as you type (plus any other typos). Mixing it up with JS (which is weakly typed)?