Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

Post reply on HN
Print view View original

141–150 of 359 posts

Re: Deno will stop using TypeScript

#141

Post by kybernetikos »

chmln wrote: post #75
vimslayer wrote: post #23

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.

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

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.

Re: Deno will stop using TypeScript

#142

Post by pjmlp »

So it happens again, yet another project discovers that whatever improvements a guest language brings into a platform, using it also has its costs versus using the main language of the platform.

Re: Deno will stop using TypeScript

#143

Post by orangecat »

stickfigure wrote: post #123
orangecat wrote: post #89

Earlier quoted context omitted.

You don't have to write as many tests when you use static typing, because your method contracts are solid. People often say this, and I don't get it. What JS tests are you writing that become unnecessary in TypeScript? I've used a fair amount of TypeScript and plain JS, and end up with similar amounts of tests for each. With JS, I almost never want to verify only that a value is of a specific type; I want to look at…

Let's say you have a method that takes a thing : function doSomething(thing) { ... } How many different possible representations of a 'thing' do you have? A json object? A class object with behaviors? A database id? Some sort of natural key like a SKU? A URL? Is it a metric or imperial thing? You need integration-level tests around every method call to ensure that caller and callee agree what kind of 'thing' represen…

You need integration-level tests around every method call

Sure, but you need those tests anyway to verify that your code actually works. I agree that type systems reduce the occurrences of some classes of bugs; I'm only disagreeing with the claim that they reduce the amount of tests you need to write.

Re: Deno will stop using TypeScript

#144

Post by TOGoS »

devit wrote: 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.…

With regard to point 1, I think the reasoning is that they wanted precise control over their .d.ts file, since that's the public interface. This I understand, though I don't see why switching to JavaScript necessarily helps. Maybe it was tricky to get the TypeScript compiler to accept their hand-written .d.ts while also processing TypeScript? Which sounds more like a tooling problem than a language problem.

I'm with you on the rest of the points, though. I don't quite understand it, either. But then I'm not working in that codebase every day. Easy to criticize people from the outside!

Re: Deno will stop using TypeScript

#145

Post by wereHamster »

ricardobeat wrote: post #131
smhmd wrote: post #77

Earlier quoted context omitted.

> not the languages's fault. 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 wa…

The compiled 'mess' that is shipped in the runtime is mostly due to SystemJS, not TypeScript - it doesn't handle modules, and compiles to very clean code if you target a recent ES version. I'm confused as to how dropping TS will help with the code emitted for modules.

Is SystemJS still a thing? What's their point now that browsers support ESM natively?

Re: Deno will stop using TypeScript

#146

Post by Yoric »

kybernetikos wrote: post #141
chmln wrote: post #75

Earlier quoted context omitted.

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

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.

Re: Deno will stop using TypeScript

#147

Post by untog »

wereHamster wrote: post #145
ricardobeat wrote: post #131

Earlier quoted context omitted.

The compiled 'mess' that is shipped in the runtime is mostly due to SystemJS, not TypeScript - it doesn't handle modules, and compiles to very clean code if you target a recent ES version. I'm confused as to how dropping TS will help with the code emitted for modules.

Is SystemJS still a thing? What's their point now that browsers support ESM natively?

Deno != browser

Re: Deno will stop using TypeScript

#148

Post by hellisothers »

kevsim wrote: post #136
IBCNU wrote: post #92

Earlier quoted context omitted.

null coalescing is good, but I personally found that Typescript doesn't offer many advantages on a large team. I know it's not cool these days! But it just slows me down and if you're reasoning about functions I never run into that many production level issues with types, but maybe that's just my brain I dunno!

What is it about a large team that causes it to stop offering an advantage? If anything I’d expect it to be more useful as a code base grows in complexity

Agreed, as the team gets larger and an given individual doesn’t necessarily know how everything works from memory the need to rely on the compiler and type safety should grow.

Re: Deno will stop using TypeScript

#149

Post by tigershark »

mimixco wrote: post #33
efficax wrote: post #19

Earlier quoted context omitted.

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.

I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS…

No, it’s not counterproductive to access JSON objects using a predefined schema, it saves your ass in case of typos.

Re: Deno will stop using TypeScript

#150

Post by jlg23 »

mimixco wrote: post #16
echelon wrote: 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…

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 large, important, and also not statically typed. It's worked out ok for Lisp programmers.

Lisp programmers use check-type[1] a lot, they proclaim[2] types for performance optimizations and they often deftype[3] if not only for code clarity. And then we have CLOS and its dispatching on types/classes...

[1] http://www.lispworks.com/documentation/HyperSpec/Body/m_chec... [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_proc... [3] http://www.lispworks.com/documentation/HyperSpec/Body/m_deft...

Post reply on HN