Earlier quoted context omitted.
You don’t see the benefits of a strongly typed language?
Python is strongly typed, don't confuse static and strong typing.
You’re right.
Deno will stop using TypeScript
41–50 of 359 posts
Re: Deno will stop using TypeScript
#42They should just use deno to run their setup, there would be no compilation if they did that. ;) Someone is trying to rewrite tsc in rust for speed up here - https://github.com/swc-project/swc Cool project for runtime checking with ts - https://github.com/gcanti/io-ts Edit: Remove unmaintained runtime type checking library.
Instead of ts-runtime, use io-ts (https://github.com/gcanti/io-ts). That one is actually maintained, unlike ts-runtime!
Re: Deno will stop using TypeScript
#43Earlier 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.
there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.
For dynamically typed languages, the idea is you make up for that class of bugs by incorporating TDD and having lots and lots of unit tests.
So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.
Re: Deno will stop using TypeScript
#44This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It…
I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.
I like typescript not because it prevents most errors in my code, but because it prevents some errors. Those errors, in my experience, tend to be ones that are time consuming to identify and solve.
A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production.
I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only recently started pushing some of our code to the client. If you can convince management that we should shift our paradigm to allow for the time to write tests that don't add much to the sprint we're in, I can send you their email address.
The fact is, a large portion of unit tests solve the same problems that strong types solve.
Re: Deno will stop using TypeScript
#45They should just use deno to run their setup, there would be no compilation if they did that. ;) Someone is trying to rewrite tsc in rust for speed up here - https://github.com/swc-project/swc Cool project for runtime checking with ts - https://github.com/gcanti/io-ts Edit: Remove unmaintained runtime type checking library.
Instead of ts-runtime, use io-ts ( https://github.com/gcanti/io-ts ). That one is actually maintained, unlike ts-runtime!
[deleted]
Re: Deno will stop using TypeScript
#46Due 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 files that create the actual Deno executable and the user-facing APIs is creating runtime performance problems
Then use a better structure?
? 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 https://github.com/denoland/deno/issues/4748
Then consolidate the two classes...? How is the the language's fault?
> 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
Well, it can be. Fix your build rules.
> They’re maintaining two TS compiler hosts: one for the internal Deno code and another other for external user code even though both have a similar goal
Again, not the language's fault.
---
We've been using Typescript for a couple of years now, and it's been great. By trying to do things the right way, it actually forces us to organize our code better. I think the Deno project would benefit from refactoring their code to solve their issues, instead of blaming the tools.
Re: Deno will stop using TypeScript
#47Why remove it entirely rather than split off compilation and type checking? I’m not familiar with the Deno codebase, but a similar problem with large webpack projects is solved by having the type checking be an async process. This gives the best of both worlds as you transpiling alone is near instant.
Re: Deno will stop using TypeScript
#48Why 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.
If it’s only 10k lines of glue code how are they running into minutes long compiles?
Re: Deno will stop using TypeScript
#49> One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations
... choice of programming languages is irrelevant here.
Re: Deno will stop using TypeScript
#50It seems it might be an issue with their development abilities or problem-solving motivation: 1. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action. 2.…
I’m never one for developer hero worship, but I feel safe assuming that Ryan Dahl’s development abilities are not the issue here.