Hacker News Reader

Comment by vimslayer | Hacker News Reader

Most of the project is and will still be written in Rust, a statically typed language, so saying that the "project" will drop static types is an overstatement. Based on the design document where the devs talk about this, the TS code in question is about 10k lines of glue code between Rust & userland JS/TS.

View on HN

If it’s only 10k lines of glue code how are they running into minutes long compiles?

Presumably that's what the Deno team is wondering

Haven't looked at their build, but it's almost certainly the case that they are generating some sort of rust binding from the typescript code and the compilation times are actually from needing to recompile rust.

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

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.

It's enough to benefit from types, assuming no large swathes of inline literals.

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.

Unless one is paid in LOC I'd expect a senior dev to write less code than a novice...

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.

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

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.

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.

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.

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

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.

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.

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.

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

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?

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.

They become really frustrating as the project grows in size. Personally, it becomes really difficult to maintain productivity. As compile times tick up, I start bouncing over to other tabs rather than just twiddling my thumbs starring at a terminal. Then I realize I've been on Reddit for a half-hour.

I recently watched this talk by Johnathan Blow[0] where he talks about quality of life in programming languages and spends a fair amount of time talking about compile times and their effects.

I think we collectively need to re-align on being performance focused. Tools are simultaneously amazing but crummy at the same time.

[0] https://www.youtube.com/watch?v=uZgbKrDEzAs&t=2s

I don't love the compile times, but I'll also say with TypeScript I tend to check the browser that often. TS also means simpler refactoring, for example.

Note also: * type checks can run in parallel, so they won't block your other build block * the tsc has been making gradual improvements to performance and techniques to improve compilation and type checking * there are speedy alternatives to the TypeScript compiler (tsc) (eg: https://sucrase.io) for transpilation

Much faster compiles times sounds like a good reason to me ;)

I wasn't comparing to ReasonML, which I'm convinced is a very good choice.

If compilation times are a problem with typescript I do not see how Rust will help.

Maybe that means it is not as bad as it sounds, but if it's true it makes no sense to me. How could you possibly have minutes of compile time on so few lines of code? The typescript compiler isn't that slow.

I've witnessed teams that have switched from static typing to dynamic typing before, due to complaints about compile times and a lack of ability. It doesn't take long before their testkit balloons and they spend 10x the time on testing, dwarfing any savings they made by eliminating compilation. Or worse, the code turns into something magical but untouchable, lest something break...eliminating the ability that they imagined they would get.

Why is anyone in the world manually writing 10k lines of glue code? You don't need TS or JS, you need.. a computer.

Please, elaborate.

I suspect there might be more than one definition of "glue code" at play here.

I would guess that he means that when you have a lot of glue code it tends to be repetitive and so writing tools to write the glue code can be a win. Let's say you have implemented a service that exposes API X to its users, and let's say you have an internal service that provides the actual functionality you are trying to expose but uses API Y. Hence you need glue code that translates between X and Y.

There might be hundreds of API calls in X but the glue code is all going to be of the same general form: translate the X parameters to corresponding Y parameters, call the matching Y function, and then translate results back.

Within all these glue functions there will be a lot of common actions. X calls with integer parameters for instance might pass them as ASCII strings and Y might expect integers as 64-bit big-endian binary.

In this situation there is a good chance you can make a table that lists each X call, the types of its arguments and results, the Y call to map it to, and some flags to indicate that some things need special handling and what those are.

You can then have a program, probably a fairly short and straightforward program, that reads that table and writes out the glue code for you, sticking in comments marking places where you need to edit it to deal with those places marked as needing special handling.

Codegen?

Reply on news.ycombinator.com