Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

61–70 of 359 posts

Re: Deno will stop using TypeScript

#61

This 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'm not a huge fan of TS not because I don't appreciate types but because I don't feel like it gives me any real type safety. Not due to the language itself but because I have to connect whatever I write to something else, and I wind up writing the type checking myself.

It's the same BS as Python and JS, the lack of typing but fundamental nature of systems that require data to be typed means half my code is checking that everything is properly typed!

Dynamic types have their uses, but in general they're more trouble than just writing typed code to begin with. And when your type system is more a suggestion than anything it provides little benefits.

Re: Deno will stop using TypeScript

#62
post #14

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.

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

Re: Deno will stop using TypeScript

#64
post #31

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

> 2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead.

Interested to know how you're actually supposed to do this. I don't do much web development, but the few times I've had to dive into our typescript code at work, I end up just modifying the compiled javascript to debug things because the compile loop is painfully slow.

Re: Deno will stop using TypeScript

#65
post #62

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.

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.

Re: Deno will stop using TypeScript

#66
post #14

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…

Yeah, I tend to agree. After 18 months with TypeScript, I can't really imagine going away from it. After every single refactoring I do, I'm extremely grateful for proper typing. Not to mention sugar like null coalescing, etc.

Re: Deno will stop using TypeScript

#67

This 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…

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

This is true, and confirmed by the TypeScript team

https://stackoverflow.blog/2020/06/15/talking-typescript-wit...

> Do you remember why the team came up with TypeScript, why you wanted to release something like this?

> A: When I joined the team, there were a lot of people at Microsoft who wanted to develop JavaScript at what we call “application scale.” Teams like TFS and Office wanted to build large JavaScript applications. A lot of those people had familiarity with statically-typed languages— C++, C#, Java, that kind of thing. They wanted to have that static typing available both for conceptual scalability and for the tooling.

> The language experts at Microsoft looked at the situation and said, well, we could try to write a new language like people had done before. There are projects like Script#, which takes C sharp and turns it into JavaScript, or languages like CoffeeScript that said, what if JavaScript had a different syntax? But what they decided instead was to just take JavaScript and add static types on top of that.

> At the time, JavaScript was experiencing a renaissance of growth, where they were adding features to the language again for the first time in a pretty long time. People wanted to use those cool new features, like arrow functions and classes, and they didn’t want to wait for all browsers to adopt them. They wanted to be able to use those features right away. I think those were the three things that TypeScript offered upfront: static typing for error finding purposes, leveraging that static type information for tooling, and providing the JavaScript features of tomorrow, today.

Re: Deno will stop using TypeScript

#68
post #14

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…

[deleted]

Re: Deno will stop using TypeScript

#69

I don't remotely see TypeScript as the end state of statically typed JavaScript. I think it was the first major project to prove how static typing could work and benefit browser applications. Flow and TypeScript are just the first generation. In the future I expect the type system to be integrated with the runtime. While there are projects that give you this (Elm, Reason, Bridge.net, Fable, etc.), they are nowhere ne…

I am a newbie reason user. I like the language and ocaml ecosystem but it is just a bit of a pain to do anything practical with it. Soon you are writing a lot of js in reason. Compared to typescript, js and reason mixed code stings like a sharp contrast between sun and moon.

Until those languages make themselves feel just like js or completely remove excessive js interlop, they won't be as mainstream.

Re: Deno will stop using TypeScript

#70
I’m very perplexed about the reasoning.

Aside from the compiling takes time issue, the rest sounds like trolling.

If the code was organized in a way which is inefficient and confusing, I fail to see why checking types at runtime instead of compile types improves the structure. It’s a completely separate problem.

Post reply on HN