3 ms·

10K is a lot of code. As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript

by chmln 6y ago

subaru_shoe 6y ago
10k is a lot of code? No way that is a lot of code or at least it’s not a lot for senior devs.
- recursive 6y ago
  It's enough to benefit from types, assuming no large swathes of inline literals.
- timkam 6y ago
  This certainly depends on what the code does and on the use case, i.e. on how critical reliability and performance are. 10k code in a simple web application prototype that will be trashed in 3 months is not "a lot", because it's not critical and piling up technical dept is not a problem. 10k code to specify the core algorithms in a mission-critical, long-living system is "a lot", or at least "much more", because it needs to be crafted and maintained with immense care.
- jlg23 6y ago
  Unless one is paid in LOC I'd expect a senior dev to write less code than a novice...
Dork1234 6y ago
As someone who has maintained multiple legacy projects, 10k is not a lot of code. I normally run into single files in the 10k range, if it wasn't for NP++ and VSCode I would go insane just trying to scroll.
tigershark 6y ago
No, it’s not. 10k loc is a small project.
kybernetikos 6y ago
I've worked on javascript codebases pushing half a million lines of code, and my memory is that we didn't run into type bugs all that often. The biggest downside was the lack of automated refactoring tools - this was many years ago now. It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard.
- Yoric 6y ago
  If your memory is good, I'm impressed. > It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard. Out of curiosity, what was the turnover within the team? My personal experience is that static typing helps a lot when you're new to a codebase. Probably less so when everybody can recite the architecture in their sleep.
  - kybernetikos 6y ago
    The turnover didn't start increasing until the 'javascript ecosystem' developed, and suddenly everyone wished that they were following the new community developed practices rather than the ones we'd be following for years. That lead to lots of factionalism within the team and a lot of unhappiness on all sides.
- yawaramin 6y ago
  > The biggest downside was the lack of automated refactoring tools That's what a typechecker gives you–an automated enforcement mechanism for ruling out certain errors during refactoring.
kiliancs 6y ago
Working on half a million LOC TypeScript codebase. All strict flags up, low-2-digit team size. We don't really run into many problems. TypeScript is not perfect, but developer happiness and productivity have definitely increased since we adopted it, and defect rates have dropped significantly --while increasing the size of the team & working on more features.
- yawboakye 6y ago
  Think of the change as a statically compiled language writing parts of their runtime with assembly or unsafe pointers. It’s not an indictment of TypeScript.
  - kiliancs 6y ago
    My first impression of the reasons in the design doc is that the change is not well justified, but I also see the point you make; my response, though, was to the direct parent comment.
- thegreatpeter 6y ago
  I have a hard time believing that. We have 10k lines of typescript and that take forever to compile compared to 5x more of the ReasonML code we have that compiles instantly
  - petersellers 6y ago
    You have a hard time believing that their team experienced more happiness and productivity with TS...because your ReasonML code compiles a lot faster than your TS code?
    - kohtatsu 6y ago
      I've actually been (very) wary of adopting TypeScript once I learned of the multi-second compile times, even for tiny projects. I had actually been watching Deno in case they solved any of that.

10K is a lot of code. As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript

by chmln 6y ago

10K is a lot of code. As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript

subaru_shoe 6y ago

10k is a lot of code? No way that is a lot of code or at least it’s not a lot for senior devs.

recursive 6y ago
It's enough to benefit from types, assuming no large swathes of inline literals.
timkam 6y ago
This certainly depends on what the code does and on the use case, i.e. on how critical reliability and performance are. 10k code in a simple web application prototype that will be trashed in 3 months is not "a lot", because it's not critical and piling up technical dept is not a problem. 10k code to specify the core algorithms in a mission-critical, long-living system is "a lot", or at least "much more", because it needs to be crafted and maintained with immense care.
jlg23 6y ago
Unless one is paid in LOC I'd expect a senior dev to write less code than a novice...

Dork1234 6y ago

As someone who has maintained multiple legacy projects, 10k is not a lot of code. I normally run into single files in the 10k range, if it wasn't for NP++ and VSCode I would go insane just trying to scroll.

tigershark 6y ago

No, it’s not. 10k loc is a small project.

kybernetikos 6y ago

I've worked on javascript codebases pushing half a million lines of code, and my memory is that we didn't run into type bugs all that often. The biggest downside was the lack of automated refactoring tools - this was many years ago now. It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard.

Yoric 6y ago
If your memory is good, I'm impressed. > It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard. Out of curiosity, what was the turnover within the team? My personal experience is that static typing helps a lot when you're new to a codebase. Probably less so when everybody can recite the architecture in their sleep.
- kybernetikos 6y ago
  The turnover didn't start increasing until the 'javascript ecosystem' developed, and suddenly everyone wished that they were following the new community developed practices rather than the ones we'd be following for years. That lead to lots of factionalism within the team and a lot of unhappiness on all sides.
yawaramin 6y ago
> The biggest downside was the lack of automated refactoring tools That's what a typechecker gives you–an automated enforcement mechanism for ruling out certain errors during refactoring.

kiliancs 6y ago

Working on half a million LOC TypeScript codebase. All strict flags up, low-2-digit team size. We don't really run into many problems. TypeScript is not perfect, but developer happiness and productivity have definitely increased since we adopted it, and defect rates have dropped significantly --while increasing the size of the team & working on more features.

yawboakye 6y ago
Think of the change as a statically compiled language writing parts of their runtime with assembly or unsafe pointers. It’s not an indictment of TypeScript.
- kiliancs 6y ago
  My first impression of the reasons in the design doc is that the change is not well justified, but I also see the point you make; my response, though, was to the direct parent comment.
thegreatpeter 6y ago
I have a hard time believing that. We have 10k lines of typescript and that take forever to compile compared to 5x more of the ReasonML code we have that compiles instantly
- petersellers 6y ago
  You have a hard time believing that their team experienced more happiness and productivity with TS...because your ReasonML code compiles a lot faster than your TS code?
  - kohtatsu 6y ago
    I've actually been (very) wary of adopting TypeScript once I learned of the multi-second compile times, even for tiny projects. I had actually been watching Deno in case they solved any of that.