Deno will stop using TypeScript • Hacker News Board

Re: Deno will stop using TypeScript

#111

Post by stefankorun » Sun, Jun 21, 2020, 4:49 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…

What a pretentious comment, everyone makes mistakes and everyone can write a big mess of a code eventually. The benefit of typesafety is how easy we can spot that and recover / rewrite when needed.

Re: Deno will stop using TypeScript

#112

Post by j1elo » Sun, Jun 21, 2020, 4:50 PM UTC

I just hope in 5 years we're not seeing a talk saying that in retrospective, dropping static types was a huge error... and DoNe is a new project to fix issues like that!

(I'm just referring to this nice talk about the regretful mistakes done in Node: https://youtu.be/M3BM9TB-8yA)

Re: Deno will stop using TypeScript

#113

Post by geoka9 » Sun, Jun 21, 2020, 4:50 PM UTC

orangecat wrote: post #89

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…

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, which means I'd need to write the same test in TypeScript.

If such (refactored) method is being called from code that's not covered by tests, the bug may not be discovered until it blows up in production. With static typing it would be caught at compile time.

Re: Deno will stop using TypeScript

#114

Post by gameswithgo » Sun, Jun 21, 2020, 4:50 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.

and you wait a minute for the tests to run every time you commit a change

Re: Deno will stop using TypeScript

#115

Post by recursive » Sun, Jun 21, 2020, 4:53 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.

It's enough to benefit from types, assuming no large swathes of inline literals.

Re: Deno will stop using TypeScript

#116

Post by vorpalhex » Sun, Jun 21, 2020, 4:54 PM UTC

NicoJuicy wrote: post #99

pfraze wrote: post #79

Earlier quoted context omitted.

Browser monopoly led lots of devs to learn JS, then NodeJS showed that lots of devs want to keep using JS. It's actually possible for people to like it. Also, languages are always a function of their ecosystems. You could argue, remove Apple products and Swift/ObjC would vanish.

Nodejs showed that a lot of developers are lazy and want 1 language to learn

Certainly you didn't go through the entire pro con list of Node over other languages and go "it must be developer laziness!"

Easy to reason about, great performance for most cases, simple to debug and write code for, a plethora of libraries, easy to ship, no need to have different teams for backend/frontend, and minimal tooling needed.

Re: Deno will stop using TypeScript

#117

Post by damnyou » Sun, Jun 21, 2020, 4:55 PM UTC

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 important for its intellectual contributions, not for its use in large production systems.

Re: Deno will stop using TypeScript

#118

Post by timkam » Sun, Jun 21, 2020, 4:58 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.

This certainly depends on what the code does and on the use case, i.e. on how critical reliability and performance are. 10k code in a simple web application prototype that will be trashed in 3 months is not "a lot", because it's not critical and piling up technical dept is not a problem. 10k code to specify the core algorithms in a mission-critical, long-living system is "a lot", or at least "much more", because it needs to be crafted and maintained with immense care.

Re: Deno will stop using TypeScript

#119

Post by orangecat » Sun, Jun 21, 2020, 4:59 PM UTC

geoka9 wrote: post #113

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…

> With JS, I almost never want to verify only that a value is of a specific type; I want to look at its contents, which means I'd need to write the same test in TypeScript. If such (refactored) method is being called from code that's not covered by tests, the bug may not be discovered until it blows up in production. With static typing it would be caught at compile time.

If such (refactored) method is being called from code that's not covered by tests

Well there's your problem :p

I agree that if code has no tests, it's more likely to be correct if it's in TypeScript than JS. But I don't consider that an acceptable bar, so if I'm doing your code review I'm going to ask for tests in either case. And once you have tests that verify the behavior of the code, you're not getting much incremental benefit from type checking.

Re: Deno will stop using TypeScript

#120

Post by austincheney » Sun, Jun 21, 2020, 4:59 PM UTC

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…

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.