Deno will stop using TypeScript

Post by thomasrognon » Sun, Jun 21, 2020, 6:34 PM UTC

eitland wrote: post #171

jorams wrote: post #133

Earlier quoted context omitted.

Slow compile times are very much a problem caused by TypeScript.

My 3 year old laptop has no problems with TypeScript (neither Angular nor React), and I am a rather impatient guy when it comes to computers. I'm honestly wondering: What are people doing to end up in a position where TypeScript compile times are a problem?

  type ImmutablePrimitive = undefined | null | boolean | string | number | Function;
  export type Immutable =
    T extends ImmutablePrimitive ? T :
    T extends [infer U]                                     ? readonly [Immutable] :
    T extends [infer U, infer V]                            ? readonly [Immutable, Immutable] :
    T extends [infer U, infer V, infer X]                   ? readonly [Immutable, Immutable, Immutable] :
    T extends [infer U, infer V, infer X, infer Y]          ? readonly [Immutable, Immutable, Immutable, Immutable] :
    T extends [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable, Immutable, Immutable, Immutable] :
    T extends readonly [infer U]                                     ? readonly [Immutable] :
    T extends readonly [infer U, infer V]                            ? readonly [Immutable, Immutable] :
    T extends readonly [infer U, infer V, infer X]                   ? readonly [Immutable, Immutable, Immutable] :
    T extends readonly [infer U, infer V, infer X, infer Y]          ? readonly [Immutable, Immutable, Immutable, Immutable] :
    T extends readonly [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable, Immutable, Immutable, Immutable] :
    T extends Array ? ImmutableArray :
    T extends ReadonlyArray ? ImmutableArray :
    T extends Map ? ImmutableMap :
    T extends ReadonlyMap ? ImmutableMap :
    T extends Set ? ImmutableSet :
    T extends ReadonlySet ? ImmutableSet :
    ImmutableObject;
  type ImmutableArray = ReadonlyArray>;
  type ImmutableMap = ReadonlyMap, Immutable>;
  type ImmutableSet = ReadonlySet>;
  type ImmutableObject = { readonly [K in keyof T]: Immutable };

Post by ptx » Sun, Jun 21, 2020, 6:42 PM UTC

snarfy wrote: post #43

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.

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.

Post by karmakaze » Sun, Jun 21, 2020, 6:58 PM UTC

karmakaze wrote: post #39

untog wrote: post #5

> While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. Woah, woah, hold on. This case is showing that in the very specific, atypical case the Deno team are using it in, TypeScript is not the right fit. I’d rather read something that actually interviews the Deno folks about what they are doing, the underlying document is a pretty free ranging discussion…

May as well drop tests and code reviews if it feels like it's slowing you down. For one-person or very small teams who have full context of a'll changes this can actually work very well. It's with more contributors participating in a mature project that you'd wish these things weren't dropped. Types can be added later so it's not like using php and later wishing you'd used Kotlin.

Post by underdeserver » Sun, Jun 21, 2020, 7:05 PM UTC

baddox wrote: post #154

underdeserver wrote: post #46

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…

Your main point seems to be that these problems aren’t the language’s fault. But I don’t see the Deno team claiming that to be the case. There’s nothing wrong with choosing a language that works with how your team likes to develop software, and rejecting a language that doesn’t work well for your team. Doesn’t need to be anyone’s “fault.”

Post by eitland » Sun, Jun 21, 2020, 7:13 PM UTC

vorpalhex wrote: post #199

eitland wrote: post #182

Earlier quoted context omitted.

> Easy to reason about, I'd like to know what language you use as a baseline for this? I made my first "real" Javascript code back in 2005 (a vector map system that worked in realtime) and I've been working mostly with frontend for the last 3 years so it is not lack of familiarity. In between that however I have programmed a lot of other languages, worked in a number of different teams, written new code, maintained o…

Event threading pulls out a huge amount of difficulty with semaphores, locks, thread safety, etc. The lack of OO means no typecasting, inheritance models, interfaces, etc. Arrays are fully dynamic, not type restricted and operate strictly by reference. No memory mapping, manual garbage collection or even GC adjustments. Suddenly the list of things someone has to understand to be a competent JS engineer is way smaller…