8 ms·

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

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.
    - abstract_put 5y ago
      Do you have any specific examples of things that make JS nice that have been lost because of the popularity of TS? As with types in Ruby, I was under the impression nothing was really lost as TS could be added incrementally as developers saw value. I don't think I've talked to anyone who has gotten "over the hump" with TS and felt like they were missing something from JS - I may be in a bubble though. It's almost frustratingly beloved in my experience.
      - fiddlerwoaroof 5y ago
        I’ve been writing TS for a year now and I find TS annoying. Especially for react components with state management of some kind, the types get so complex you almost need unit tests to assert they are what you think they are. Additionally, TS being a structural type system with no access to nominal types at all eliminates a whole class of “ghosts of departed proofs” modeling techniques. (And, I know you can work around this, but those workarounds are ugly.) My view is that I’d use TS if I have to but I’d pick either plain JS / CLJS or something like purescript if I really wanted types.
        jamil7 5y ago
        I haven’t touched the ecosystem really for a number of years but my last JS project was in TS and I hated it for the same reason. The overhead of bringing in yet more npm modules and types and build steps for questionable levels type safety. Languages with much better type systems exist.
        canaus 5y ago
        Such as?
        arcanon 5y ago
        The year is 2021. People argue for a toolchain that takes a static language, compiles it to a dynamic one, then runs it with an interpreter on the server side. Humanity ended shortly thereafter.
- imachine1980_ 5y ago
  you don't use static type for speed, the first time i write some code in TS(wh compile to js) i typed something of web-storage the editor say this function assume string and you put a num, if i use js i need to run the program to know that. is cool ultra expressive typing(haskell) but you don need nothing so fancy to have huge gains in productivity. ruby and python are grate langues to write scripts and rails make a lot for you but having the compiler take your hand slaps bugs like nothing
- JBits 5y ago
  Wait, Pony as in https://www.ponylang.io/ https://www.ponylang.io/ ? Since this is the first time I've seen someone bring it up, can I what your experience using it has been like? And also what you were using it for?
  - Mikeb85 5y ago
    That's the one. Experience is that it's very good at what it does: multithreaded/distributed programs. Good C interop. It forces you into it's paradigm, but it's a good one for creating performant code across cores. Tooling isn't great, it's missing things like a language server (compiler gives good error messages at least), but it's also quite simple (whole syntax fits into a smallish page) and the documentation is decent. Playing around with it for doing economic simulations. Actors + good multithreaded performance = pretty much perfect for the domain. Makes sense too, the creator and half the core members came from the financial field. Ruby is my go-to for scripting, one off programs, and anything web-related (blog, putting together a small crud site). For things where I want performance, I just use a compiled/static language.
- lucideer 5y ago
  > I'd use a typed language if I wanted one. I think the general point the above commenter is trying to make is that not all typed languages are equivalent: i.e. if you're avoiding TS/typed ruby/etc. because you don't want something like Haskell/Java, then that's not a well-informed decision as they're (all) radically different approaches to static typing, each with their own unique benefits and drawbacks. TS is nothing like Java nor Haskell. Nor Rust. (I can't personally speak to Ruby/Pony yet)
zomgwat 5y ago
I've gotten a lot of value from integrating Sorbet into a non-trival 15 year old Rails app. The gradual nature of the typing is very nice. I've never written TypeScript but I suspect the tooling around Sorbet is pretty far behind at this point but it's still worth it. For example, there are is a whole class of unit tests that no longer need to be written. In addition to the gradual typing, having access to interfaces, typed structs and enums is all nice too.
- eropple 5y ago
  Yeah, Sorbet and the progress being made in Ruby-land makes me want to go back and give it a good look. I really like Ruby. I just really like writing silly in/out tests less.
  - JohnBooty 5y ago
    I just really like writing silly in/out tests less. Were you writing a bunch of tests to make sure that A is passing arguments of the right type to B? I'm not sure that's a great use of time. If A is passing the wrong thing to B, B will throw a `NoMethodError` anyway once it tries to do anything with the arguments, which will make the spec test fail anyway. But maybe I'm misunderstanding what you mean by "silly in/out tests"...
    - eropple 5y ago
      You can get away with that if you're writing something for immediate delivery, though I think it leads to a lot of not-my-problem thinking in teams that have to scale. On the other hand, I write a lot of libraries, both for internal and external consumption, and there are a lot of operations, in that context, where you won't get a `NoMethodError`--serialization, for example. You can happily serialize an integer if it's passed instead of a string. That doesn't mean it makes sense, or whatever is consuming it is going to be able to make heads or tails of it, and having to run code in order to know whether you've made trivial mistakes is shitty and demoralizing to an end user when they have to divine what a `NoMethodError` means when it's thrown deep inside of a library. It can also then create security issues around untrusted input; you should be sanitizing at module boundaries any time something might be sensibly used with rando input, IMO, rather than relying on web developers who may or may not be competent enough to duplicate other consumers' effort to do it. Having to do less work to enforce sanity at module boundaries, and having it tied in with the type system when you do have to do it, is a powerful force-multiplier. For example: I use `runtypes` to create validators in TypeScript when I must handle untrusted input and it's smart enough to take the validator I specify and create a type of the same shape for use at compile-time, so users who aren't dealing with untrusted input just have the nice computer cross the T's and dot the I's for them.
tambourine_man 5y ago
> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch, the required for larger projects, compiletime vs runtime errors are all discussable, even though they are often thrown in the conversation as irrefutable advantages of static typing. The performance angle, not so much. Static will almost always be faster then dynamic typing, even with all the crazy tricks we’ve developed over the decades.
- fastball 5y ago
  When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.
  - DeathArrow 5y ago
    With Visual Studio also. Intellisense works wonders.
  - deleted 5y ago
    [deleted]
  - dragonwriter 5y ago
    > The argument has always been whether or not the price of that correctness is too high. No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time. > But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.
joelbluminator 5y ago
Out of date how? Tons of people write pure javascript and not typescript. They are all not as productive as you?
- deleted 5y ago
  [deleted]
- eropple 5y ago
  I'm saying that I am significantly faster and more correct TypeScript than JavaScript, and I know literally no people who are starting greenfield projects in JavaScript today. People choosing to write JavaScript in 2021 might be plenty productive. I trust their code much less, though, unless they're writing a battery of tests to establish sanity at their module boundaries and making the extra effort to ensure correctness that you get very cheaply with TypeScript.
  - joelbluminator 5y ago
    YOU are faster with Typescript. Can you accept the fact that certain people are not and do not like Typescript? You live in a Typescript bubble so you conclude everyone is doing that. Just open a jobs board and see for yourself not everyone is doing Typescript.

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.
  - abstract_put 5y ago
    Do you have any specific examples of things that make JS nice that have been lost because of the popularity of TS? As with types in Ruby, I was under the impression nothing was really lost as TS could be added incrementally as developers saw value. I don't think I've talked to anyone who has gotten "over the hump" with TS and felt like they were missing something from JS - I may be in a bubble though. It's almost frustratingly beloved in my experience.
    - fiddlerwoaroof 5y ago
      I’ve been writing TS for a year now and I find TS annoying. Especially for react components with state management of some kind, the types get so complex you almost need unit tests to assert they are what you think they are. Additionally, TS being a structural type system with no access to nominal types at all eliminates a whole class of “ghosts of departed proofs” modeling techniques. (And, I know you can work around this, but those workarounds are ugly.) My view is that I’d use TS if I have to but I’d pick either plain JS / CLJS or something like purescript if I really wanted types.
      - jamil7 5y ago
        I haven’t touched the ecosystem really for a number of years but my last JS project was in TS and I hated it for the same reason. The overhead of bringing in yet more npm modules and types and build steps for questionable levels type safety. Languages with much better type systems exist.
        canaus 5y ago
        Such as?
      - arcanon 5y ago
        The year is 2021. People argue for a toolchain that takes a static language, compiles it to a dynamic one, then runs it with an interpreter on the server side. Humanity ended shortly thereafter.
imachine1980_ 5y ago
you don't use static type for speed, the first time i write some code in TS(wh compile to js) i typed something of web-storage the editor say this function assume string and you put a num, if i use js i need to run the program to know that. is cool ultra expressive typing(haskell) but you don need nothing so fancy to have huge gains in productivity. ruby and python are grate langues to write scripts and rails make a lot for you but having the compiler take your hand slaps bugs like nothing
JBits 5y ago
Wait, Pony as in https://www.ponylang.io/ https://www.ponylang.io/ ? Since this is the first time I've seen someone bring it up, can I what your experience using it has been like? And also what you were using it for?
- Mikeb85 5y ago
  That's the one. Experience is that it's very good at what it does: multithreaded/distributed programs. Good C interop. It forces you into it's paradigm, but it's a good one for creating performant code across cores. Tooling isn't great, it's missing things like a language server (compiler gives good error messages at least), but it's also quite simple (whole syntax fits into a smallish page) and the documentation is decent. Playing around with it for doing economic simulations. Actors + good multithreaded performance = pretty much perfect for the domain. Makes sense too, the creator and half the core members came from the financial field. Ruby is my go-to for scripting, one off programs, and anything web-related (blog, putting together a small crud site). For things where I want performance, I just use a compiled/static language.
lucideer 5y ago
> I'd use a typed language if I wanted one. I think the general point the above commenter is trying to make is that not all typed languages are equivalent: i.e. if you're avoiding TS/typed ruby/etc. because you don't want something like Haskell/Java, then that's not a well-informed decision as they're (all) radically different approaches to static typing, each with their own unique benefits and drawbacks. TS is nothing like Java nor Haskell. Nor Rust. (I can't personally speak to Ruby/Pony yet)

zomgwat 5y ago

I've gotten a lot of value from integrating Sorbet into a non-trival 15 year old Rails app. The gradual nature of the typing is very nice. I've never written TypeScript but I suspect the tooling around Sorbet is pretty far behind at this point but it's still worth it. For example, there are is a whole class of unit tests that no longer need to be written. In addition to the gradual typing, having access to interfaces, typed structs and enums is all nice too.

eropple 5y ago
Yeah, Sorbet and the progress being made in Ruby-land makes me want to go back and give it a good look. I really like Ruby. I just really like writing silly in/out tests less.
- JohnBooty 5y ago
  I just really like writing silly in/out tests less. Were you writing a bunch of tests to make sure that A is passing arguments of the right type to B? I'm not sure that's a great use of time. If A is passing the wrong thing to B, B will throw a `NoMethodError` anyway once it tries to do anything with the arguments, which will make the spec test fail anyway. But maybe I'm misunderstanding what you mean by "silly in/out tests"...
  - eropple 5y ago
    You can get away with that if you're writing something for immediate delivery, though I think it leads to a lot of not-my-problem thinking in teams that have to scale. On the other hand, I write a lot of libraries, both for internal and external consumption, and there are a lot of operations, in that context, where you won't get a `NoMethodError`--serialization, for example. You can happily serialize an integer if it's passed instead of a string. That doesn't mean it makes sense, or whatever is consuming it is going to be able to make heads or tails of it, and having to run code in order to know whether you've made trivial mistakes is shitty and demoralizing to an end user when they have to divine what a `NoMethodError` means when it's thrown deep inside of a library. It can also then create security issues around untrusted input; you should be sanitizing at module boundaries any time something might be sensibly used with rando input, IMO, rather than relying on web developers who may or may not be competent enough to duplicate other consumers' effort to do it. Having to do less work to enforce sanity at module boundaries, and having it tied in with the type system when you do have to do it, is a powerful force-multiplier. For example: I use `runtypes` to create validators in TypeScript when I must handle untrusted input and it's smart enough to take the validator I specify and create a type of the same shape for use at compile-time, so users who aren't dealing with untrusted input just have the nice computer cross the T's and dot the I's for them.

tambourine_man 5y ago

> But that's a pretty out-of-date take Gradual/optional static typing are not new ideias. It’s just that they are fashionable now. It used to be that not having to deal with types at all was the cool place to be in. Our computers were getting so much faster every year, why would performance be a concern? Programmers are more productive in dynamic languages and computer time is cheap, etc, etc. The “correctness” pitch, the required for larger projects, compiletime vs runtime errors are all discussable, even though they are often thrown in the conversation as irrefutable advantages of static typing. The performance angle, not so much. Static will almost always be faster then dynamic typing, even with all the crazy tricks we’ve developed over the decades.

fastball 5y ago
When it comes to code, I'm fairly certain "correctness" is in fact an irrefutable advantage. The argument has always been whether or not the price of that correctness is too high. But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. At least with TypeScript in VSCode.
- DeathArrow 5y ago
  With Visual Studio also. Intellisense works wonders.
- deleted 5y ago
  [deleted]
- dragonwriter 5y ago
  > The argument has always been whether or not the price of that correctness is too high. No. I mean, that's been part of the argument, but so has whether static typing actually gave you useful correctness. Many static languages have had type systems that are more designed around convenience of compilation (and performance of compiled code) than correctness; the type systems of the optional typecheckers of modern dynamic languages are leaps and bounds better than static type systems of most popular static languages a couple decades ago, and have been for some time. > But at this point if you're using a modern IDE / code editor (e.g. VSCode), it's actually easier to write statically typed code because the inference / auto-completion / etc is so much better when you do. If you have good inference, statically typed and dynamically typed code is virtually indistinguishable TypeProf-IDE for Ruby, discussed in TFA, generates type signatures by inference from plain Ruby code.

joelbluminator 5y ago

Out of date how? Tons of people write pure javascript and not typescript. They are all not as productive as you?

deleted 5y ago
[deleted]
eropple 5y ago
I'm saying that I am significantly faster and more correct TypeScript than JavaScript, and I know literally no people who are starting greenfield projects in JavaScript today. People choosing to write JavaScript in 2021 might be plenty productive. I trust their code much less, though, unless they're writing a battery of tests to establish sanity at their module boundaries and making the extra effort to ensure correctness that you get very cheaply with TypeScript.
- joelbluminator 5y ago
  YOU are faster with Typescript. Can you accept the fact that certain people are not and do not like Typescript? You live in a Typescript bubble so you conclude everyone is doing that. Just open a jobs board and see for yourself not everyone is doing Typescript.