6 ms·

dhh is still not very fond of it. To each their own. https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01 https://world.hey.com/dhh/turbo-8-is-dro

by chem83 2mo ago

dhh is still not very fond of it. To each their own. https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01 https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...

tiffanyh 2mo ago
> TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become `any`. No thanks! That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
- aaronvg 2mo ago
  these painpoints seem moot in a world where AI agents are writing all the code.
  - overfeed 2mo ago
    That world will never be. Humans will always be writing some code, at least for as long as I live and breathe.
  - recursive 2mo ago
    Type declarations can help an LLM in the same way they help people.
- deleted 2mo ago
  [deleted]
- hvb2 2mo ago
  Types are a safeguard, they rule out certain errors. So using them is mostly for maintainability, and especially in large codebases and teams that becomes a thing. I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
  - egorfine 2mo ago
    > Types are a safeguard, they rule out certain errors I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
    - overfeed 2mo ago
      eons ago, I migrated a frontend to Typescript and caught a lot of type-related bugs[1]. It was a 5kLoC, fast-moving productized prototype written by a team of 5. I won't ever do dynamic-typed plain Javascript in a team ever again, type-checker is superior to human code-reviews when it comes to catching potential bugs. Then again I prefer codebase stability of clever code or "expressiveness" 1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.
    - Xixi 2mo ago
      Static types are not _that_ useful to catch bugs, if only because type related bugs tend to surface very quickly, especially in strongly typed language like Python. So a good CI suite is usually enough to catch them, but you do need good coverage. Even if they make it to prod, they won't survive long... Static types are IMHO more useful for speed, maintenance/refactoring of large projects, and code completion in IDEs. But a codebase in production is unlikely to have much type related bugs...
      - zoul 2mo ago
        Catching bugs in CI is orders of magnitude slower and more expensive than catching them as type errors while writing the code.
      - hvb2 2mo ago
        > Even if they make it to prod, they won't survive long... I don't think that's an acceptable way to treat your users. If something is trivial to prevent, do it.
- dymk 2mo ago
  I'm a Ruby enthusiast - Sorbet is one of the best things since sliced bread to happen to the ecosystem. matz is pushing hard on static typing as part of the standard Ruby ecosystem as well.
  - matltc 2mo ago
    Really? Matt is pushing for it now? Dang. Might try Sorbet out. What IDE/LSP do you use? I was on VSCode/ruby-lsp and disabled sorbet, but after working with Zod, I became quite intrigued with the value of letting the schema do a lot of the guarding. I was under the impression that things like Crystal (statically typed Ruby) were not in vogue, and that the reason no one was moving toward static typing was because Matz did not give his blessing. (Just checked sorbet landing page, looks like it's mainly/only for fn signatures?)
  - spect88 2mo ago
    Matz hates (inline) type annotations and said many times that they're not coming to Ruby. IIUC he only allowed RBS (type annotations in separate files) due to community pressure. A lot of Rubyists deeply care about code aesthetics and Sorbet annotations are unfortunately quite ugly. There are also RBS comments, which look a bit better, but tooling/LSPs are not quite there yet IME.
  - voihannena 2mo ago
    Wow, never heard about Sorbet before, looks good! I was a Ruby developer around ten years ago, and never stopped liking the language. I have moved into functional programming since, with strong types like Haskell, and do appreciate compile time type checking nowadays. Sorbet seems like a nice compromise here though!
- lurkercodemnky 2mo ago
  > so little joy to my development experience, and quite frequently considerable grief Me when my manager asks to complete the JIRA ticket.
IshKebab 2mo ago
I mean he's a Ruby developer. He has to delude himself that static typing is a waste of time.

by chem83 2mo ago

dhh is still not very fond of it. To each their own. https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01 https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...

tiffanyh 2mo ago

> TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become `any`. No thanks! That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.

aaronvg 2mo ago
these painpoints seem moot in a world where AI agents are writing all the code.
- overfeed 2mo ago
  That world will never be. Humans will always be writing some code, at least for as long as I live and breathe.
- recursive 2mo ago
  Type declarations can help an LLM in the same way they help people.
deleted 2mo ago
[deleted]
hvb2 2mo ago
Types are a safeguard, they rule out certain errors. So using them is mostly for maintainability, and especially in large codebases and teams that becomes a thing. I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
- egorfine 2mo ago
  > Types are a safeguard, they rule out certain errors I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
  - overfeed 2mo ago
    eons ago, I migrated a frontend to Typescript and caught a lot of type-related bugs[1]. It was a 5kLoC, fast-moving productized prototype written by a team of 5. I won't ever do dynamic-typed plain Javascript in a team ever again, type-checker is superior to human code-reviews when it comes to catching potential bugs. Then again I prefer codebase stability of clever code or "expressiveness" 1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.
  - Xixi 2mo ago
    Static types are not _that_ useful to catch bugs, if only because type related bugs tend to surface very quickly, especially in strongly typed language like Python. So a good CI suite is usually enough to catch them, but you do need good coverage. Even if they make it to prod, they won't survive long... Static types are IMHO more useful for speed, maintenance/refactoring of large projects, and code completion in IDEs. But a codebase in production is unlikely to have much type related bugs...
    - zoul 2mo ago
      Catching bugs in CI is orders of magnitude slower and more expensive than catching them as type errors while writing the code.
    - hvb2 2mo ago
      > Even if they make it to prod, they won't survive long... I don't think that's an acceptable way to treat your users. If something is trivial to prevent, do it.
dymk 2mo ago
I'm a Ruby enthusiast - Sorbet is one of the best things since sliced bread to happen to the ecosystem. matz is pushing hard on static typing as part of the standard Ruby ecosystem as well.
- matltc 2mo ago
  Really? Matt is pushing for it now? Dang. Might try Sorbet out. What IDE/LSP do you use? I was on VSCode/ruby-lsp and disabled sorbet, but after working with Zod, I became quite intrigued with the value of letting the schema do a lot of the guarding. I was under the impression that things like Crystal (statically typed Ruby) were not in vogue, and that the reason no one was moving toward static typing was because Matz did not give his blessing. (Just checked sorbet landing page, looks like it's mainly/only for fn signatures?)
- spect88 2mo ago
  Matz hates (inline) type annotations and said many times that they're not coming to Ruby. IIUC he only allowed RBS (type annotations in separate files) due to community pressure. A lot of Rubyists deeply care about code aesthetics and Sorbet annotations are unfortunately quite ugly. There are also RBS comments, which look a bit better, but tooling/LSPs are not quite there yet IME.
- voihannena 2mo ago
  Wow, never heard about Sorbet before, looks good! I was a Ruby developer around ten years ago, and never stopped liking the language. I have moved into functional programming since, with strong types like Haskell, and do appreciate compile time type checking nowadays. Sorbet seems like a nice compromise here though!
lurkercodemnky 2mo ago
> so little joy to my development experience, and quite frequently considerable grief Me when my manager asks to complete the JIRA ticket.

IshKebab 2mo ago

I mean he's a Ruby developer. He has to delude himself that static typing is a waste of time.