Deno will stop using TypeScript • Hacker News Board

Re: Deno will stop using TypeScript

#131

Post by ricardobeat » Sun, Jun 21, 2020, 5:07 PM UTC

smhmd wrote: post #77

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…

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

Re: Deno will stop using TypeScript

#132

Post by preek » Sun, Jun 21, 2020, 5:11 PM UTC

whoisjuan wrote: post #10

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…

Thank you for the bold statement. I feel the same. I’m at home with Clojure, and Ruby. The same paradigms map well to JS. For the last 9 years, I have been a lecturer at the university of applied sciences in Zurich, Switzerland. In that time, I saw more and more students coming from Java and C# to JS.

They like TS a lot. And it’s obvious why. Having said that, I know no “old” programmer who used to prefer a different paradigm to express a wish to switch to TS.

Rich Hickey put it well in this quote “ Functional programs are desirable because they are simpler and easier to reason about, due to being mathematical i.e. they are free of time and place.”. I agree.

Re: Deno will stop using TypeScript

#133

Post by jorams » Sun, Jun 21, 2020, 5:11 PM UTC

austincheney wrote: post #120

mimixco wrote: post #33

Earlier quoted context omitted.

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…

Deno is having problems with TypeScript, but TypeScript is not the cause of that problem. The problem is a self inflicted issue of a name collision of their choosing.

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

Re: Deno will stop using TypeScript

#134

Post by qayxc » Sun, Jun 21, 2020, 5:12 PM UTC

IBCNU wrote: post #91

I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages

The Haskell community strongly disagrees...

Re: Deno will stop using TypeScript

#135

Post by spyke112 » Sun, Jun 21, 2020, 5:12 PM UTC

iamleppert wrote: post #87

echelon wrote: post #22

Earlier quoted context omitted.

You don't have to write as many tests when you use static typing, because your method contracts are solid. You can refactor your entire codebase with a few operations and don't have to worry about anything breaking. Is your timestamp in seconds? Millis? Is it a duration? Does it have a time zone? Have you ever written a method that returns more than one type of thing? Or had polymorphic inputs? Where are your dynamic…

Forgive me, but when I program I know what the variables I am working with are doing, and what kind of data they are storing. That’s the least of my problems. I don’t write a big mess of code, I’m constantly working iteratively on a small piece of code to make it perfect. Usually first pass is to make it perfect, then I refactor it right away to make it readable. I work that way, function by function. I never have th…

You must be one of those 10x developers. Good for you.

Re: Deno will stop using TypeScript

#136

Post by kevsim » Sun, Jun 21, 2020, 5:17 PM UTC

IBCNU wrote: post #92

kevsim wrote: post #66

Earlier quoted context omitted.

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.

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

Re: Deno will stop using TypeScript

#137

Post by Dork1234 » Sun, Jun 21, 2020, 5:18 PM UTC

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

As someone who has maintained multiple legacy projects, 10k is not a lot of code. I normally run into single files in the 10k range, if it wasn't for NP++ and VSCode I would go insane just trying to scroll.

Re: Deno will stop using TypeScript

#138

Post by tigershark » Sun, Jun 21, 2020, 5:20 PM UTC

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

No, it’s not. 10k loc is a small project.

Re: Deno will stop using TypeScript

#139

Post by jlg23 » Sun, Jun 21, 2020, 5:23 PM UTC

subaru_shoe wrote: post #103

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

10k is a lot of code? No way that is a lot of code or at least it’s not a lot for senior devs.

Unless one is paid in LOC I'd expect a senior dev to write less code than a novice...

Re: Deno will stop using TypeScript

#140

Post by pmontra » Sun, Jun 21, 2020, 5:23 PM UTC

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…

I never throw inputs of random types to my functions. Actually that could be a good idea, some fuzzying at the public API level could catch some bugs and attacks. But not at unit test level. If a function expects an integer argument I test it with integer values. That in Node, Ruby, Python and Elixir. I never saw anybody doing something different. Well, if we wanted to enforce types we could use any static typed language out there.