Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

101–110 of 359 posts

Re: Deno will stop using TypeScript

#101
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…

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

How many times has six-months-hence you cursed you for this attitude?

Be honest.

Re: Deno will stop using TypeScript

#102
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…

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…

> With JS, I almost never want to verify only that a value is of a specific type; I want to look at its contents

We're pretty deep down in abstract discussions here and I have no idea what your code looks like or what it does, but I think it's helpful to point out that knowing the type means you already know the contents to some extent.

The way I see it, checking if a value is what you expect is always good, but if you additionally get an error automatically because your number is now suddenly an e-mail address, or the function you wrote that expects phone numbers suddenly gets a name instead, in my mind that's "built in testing". It doesn't make other testing unnecessary but it sure raises the bar for cleanliness -- which is especially useful when you're working with other components that aren't JS where types do really matter (like databases, for example).

Re: Deno will stop using TypeScript

#103
post #75

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

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.

Re: Deno will stop using TypeScript

#105
Thank you.

Finally people are speaking out against the madness of TypeScript.

Don't get me wrong. It is a technical achievement to put a static type system on top of JavaScript. And for libraries, it is useful. It let's the users of the library get hints and direction from an editor like Visual Studio.

But as a language. It is just not good. No way anyone would end up with a design like that had it been built from scratch without going through JavaScript first.

Remember when Java did generics and got flak because of type erasure? Compare with TypeScript ...

Re: Deno will stop using TypeScript

#107
post #65
post #62

Earlier quoted context omitted.

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.

I would guess that he means that when you have a lot of glue code it tends to be repetitive and so writing tools to write the glue code can be a win. Let's say you have implemented a service that exposes API X to its users, and let's say you have an internal service that provides the actual functionality you are trying to expose but uses API Y. Hence you need glue code that translates between X and Y.

There might be hundreds of API calls in X but the glue code is all going to be of the same general form: translate the X parameters to corresponding Y parameters, call the matching Y function, and then translate results back.

Within all these glue functions there will be a lot of common actions. X calls with integer parameters for instance might pass them as ASCII strings and Y might expect integers as 64-bit big-endian binary.

In this situation there is a good chance you can make a table that lists each X call, the types of its arguments and results, the Y call to map it to, and some flags to indicate that some things need special handling and what those are.

You can then have a program, probably a fairly short and straightforward program, that reads that table and writes out the glue code for you, sticking in comments marking places where you need to edit it to deal with those places marked as needing special handling.

Re: Deno will stop using TypeScript

#110
post #16
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.

javascripts success is an accident of history and we have paid a heavy price for it
Post reply on HN