71–80 of 359 posts
As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn't mean it's good for your project.
Why such a large, important project would want to drop static types is beyond me. > TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just…
Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.
Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc.
All you're doing by switching from TS to JS, is trading one set of minor problems (which are solvable) to a more vast set of even larger problems that are NOT solvable.
Earlier quoted context omitted.
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.
If it’s only 10k lines of glue code how are they running into minutes long compiles?
Why such a large, important project would want to drop static types is beyond me. > TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just…
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.
As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript
EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.
Due respect, these are issues with how the Deno team uses Typescript, not with the language itself. > TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process Umm, you can compile single files, and serve them individually. It's no different from bundling (e.g. with webpack) Javascript. > The Typescript structure that they’re using in the source file…
I think that's the whole point. It's not the right tool for their specific goal.
In their design doc[0], they agree that Rust glue code should not be written in TS: compiled code "full of weird namespaces."
From the design doc discussion[0]:
ry: manually managing the d.ts files has been great - it's very much part of the public interface - we need to have 100% control over it we do not want random compiler-generated __namespace0123 in there This is the same situation - but for the bundle It's not good that we do not have visibility nor control over what code is in there. for example, the TS compiler worker, has 15k lines of code in its bundle - EXCLUDING typescript.js TS compiler worker is about 500 line thing that interfaces between ops and TSC this is caused by our attempt to "self host" the internal code self hosting is cute - but if it's effecting performance and the ability to make improvements - it's an unnecessary feature https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 ^--- here is what we ship for the compiler worker we call this code every time deno runs
lucacasonato: Ok, wow. I hadn't seen this. That changes things...
ry: does the compiler worker really need to generate a UUID? https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#... (no) yes, this is fixable within the current system .. but the point is that we're abstracting away the important parts V8 does not run typescript. It runs JS. We need to have a good handle on the JS we ship If we don't try to self-host, we don't need a sourcemap for the internal code. There's 1mb off the executable right there. The point is the internal typescript comes at a cost - and that cost is too high.
lucacasonato: So the actual issue is the bundling and opaqueness that that brings with it. It makes sense to stick to pure JS in that case. Its annoying that type checking is gone, but youre right. This is not the kind of code that should be in the runtime.
ry: not like the code isn't full of "!" anyway. TS is great, but it gives a false sense of security.
[0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
TS is the best language I've used. It supports frontend and backend and strict typing and it's scalable so I can refactor and know that my code still works.
The one thing its not good at is ML where Python is better but that's mostly because Python has better library support (not language design).
Here's the deal. When dealing with a large amount of code 80% of your dev time is spent maintaining code - NOT writing new code.
You can save a lot of time now writing new code and not using strict typing. OR you can spend a little bit of time now, maintaining your types, and save a MASSIVE amount of time later.
> - TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process
I have a HUGE typescript repo and using a Macbook Pro from 2015...
With --incremental and --watch my build takes like 5 seconds. About 1 minute on the first build then about 5 seconds after that.
If your build is taking a long time - you're doing something wrong.
> The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files
What? How? That doesn't make any sense. You're doing something wrong here. If all the code is in typescript, you have no additional work to do. If it's in JS you just have to write your own .d.ts files manually.
Honestly it seems like this team just needs to sit down and understand how their tools actually work.
The one issue where Typescript DOES kind of suck is when dealing with webpack, typemaps, and types.
Many older projects just don't publish types and if you rely on them, and they refuse to publish types, you're going to be in a bit of pain.
You can write your own types though and we've been doing this internally and for some repos just forking them so it's a bit easier to work with them. They usually lag on publishing their types.
If you want to avoid all this pain you can just use webpack for your build system and Typescript for your code. We use lerna to build a multi-module system with --hoist to avoid duplicate dependencies.
https://github.com/burtonator/polar-bookshelf
... is the project we're working on if you want to check it out. Our internal build system isn't fully published yet as we're in the process of reworking it but we're open source so you can take a look if you want.
Earlier quoted context omitted.
Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.
Lisp is not popular. Remove the browser practical monopoly, and JS popularity would vanish.
Also, languages are always a function of their ecosystems. You could argue, remove Apple products and Swift/ObjC would vanish.
We were actually considering Deno because of its TypeScript support. We have a sizeable TypeScript codebase written for Node. This will probably make us more likely to stay in Node. EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.
> Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.