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

271–280 of 359 posts

Re: Deno will stop using TypeScript

#271

Post by Aeolun »

jondubois wrote: post #236
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…

>> This feels like process immaturity or unfamiliarity. On the contrary, I think it shows great maturity in the decision making process. Many highly experienced developers have stayed away from TypeScript for reasons like those mentioned in the article (mostly to do with the build environment, source mapping, versioning complexity, etc...) These are very significant problems and not worth the small benefits which sta…

I just cannot consider this a reasonable stance.

There are places where no-typescript would be appropriate, but they’re vanishingly small. The idea that the benefits static typing brings are small is just laughable.

The reason this is such a hard choice is because static typing brings great benefits, so choosing to forgo that is not easy.

Re: Deno will stop using TypeScript

#272

Post by goostavos »

kohtatsu wrote: post #223
petersellers wrote: post #218

Earlier quoted context omitted.

You have a hard time believing that their team experienced more happiness and productivity with TS...because your ReasonML code compiles a lot faster than your TS code?

I've actually been (very) wary of adopting TypeScript once I learned of the multi-second compile times, even for tiny projects. I had actually been watching Deno in case they solved any of that.

They become really frustrating as the project grows in size. Personally, it becomes really difficult to maintain productivity. As compile times tick up, I start bouncing over to other tabs rather than just twiddling my thumbs starring at a terminal. Then I realize I've been on Reddit for a half-hour.

I recently watched this talk by Johnathan Blow[0] where he talks about quality of life in programming languages and spends a fair amount of time talking about compile times and their effects.

I think we collectively need to re-align on being performance focused. Tools are simultaneously amazing but crummy at the same time.

[0] https://www.youtube.com/watch?v=uZgbKrDEzAs&t=2s

Re: Deno will stop using TypeScript

#273

Post by chmln »

inimino wrote: post #179

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds. [1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed mor…

That document is not particularly enlightening either.

> we're removing the types from internal code and making it pure JS. this reduces complexity and helps us ship a faster product

Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run.

But perhaps this is something beyond the simpleton comprehension of us novice programmers

Re: Deno will stop using TypeScript

#274

Post by klodolph »

chmln wrote: post #273
inimino wrote: post #179

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds. [1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed mor…

That document is not particularly enlightening either. > we're removing the types from internal code and making it pure JS. this reduces complexity and helps us ship a faster product Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run. But perhaps this is something beyond the simpleton comprehension of us novice programmers

> Yeah, because dropping static types from 10K lines of code is definitely not going to be a maintenance nightmare in the long run.

My personal experience is that there’s a size threshold where static tying becomes more useful. Below this threshold, the problems solved by static types are still mostly tractable by humans and things like linters. The threshold is different for every program and set of developers.

10K lines is small enough IMO.

> But perhaps this is something beyond the simpleton comprehension of us novice programmers

That’s just flamebait, the comment is better without it.

Re: Deno will stop using TypeScript

#275

Post by klodolph »

yawaramin wrote: post #239
goliatone wrote: post #230

Earlier quoted context omitted.

Personally I have two issues with TS as it exists today. On the one hand I’m reticent to add a transpiler/compiler step between code and the runtime unless there is a very very compelling argument. On the other my perception of TS is that is a tool that removes friction between the language (JS) and tooling without really addressing anything core to the language itself. Everything people sum up as pros of using TS ge…

> my perception of TS is that is a tool that removes friction between the language (JS) and tooling without really addressing anything core to the language itself. I don't understand what that means. How is TypeScript removing friction between JavaScript and tooling? That doesn't make any sense. TypeScript is a typechecker and a language that compiles to JavaScript.

I’d say that TypeScript removes friction in the sense that you can use autocomplete fairly easily with it, out of the box. Using autocomplete without type annotations is pretty hard.

Re: Deno will stop using TypeScript

#276

Post by untog »

wereHamster wrote: post #183
untog wrote: post #147

Earlier quoted context omitted.

Deno != browser

I know that. What eludes me is what advantages SystemJS brings over ESM, for browser runtimes and server runtimes (node, deno)…

IIRC SystemJS can be used without any transpilation at runtime. ESM cannot (unless natively supported of course, like it is in browsers)

Re: Deno will stop using TypeScript

#277

Post by Kinrany »

preek wrote: post #132
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…

That quote is not really relevant: TS is as functional as JS.

Re: Deno will stop using TypeScript

#278

Post by goostavos »

kybernetikos wrote: post #153
dboreham wrote: post #129

Earlier quoted context omitted.

You could arrange to have a program write those tests for you based on your description of the project's data model. Oh wait...

You know what, that would already be better than most type systems. Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code. Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types. Thirdly, they'd run when you wanted the tests to run…

That's an interesting take. To some degree, I think I agreeing with you.

I write a lot of Purescript and a lot of Clojure. Purescript, being basically a Haskell variant, is about closing down every last little part of the system into types. You _do_ pick up a lot of visual noise for this (like `liftEffect` ugh...). Whereas Clojure, is the polar opposite. It's about keeping the system open, using large chunks of data, and having functions take/change what they need and pass along everything else none-the-wiser to what's present.

Bouncing back and forth between these two worlds, I think I've begun to lean towards the opinion that I really only care about strict types at the boundaries of my program and certain very specific checkpoints along the way (generally, something like a module/namespace boundary).

Clojure has Spec, but it misses the mark in my opinion because it doesn't solve refactoring. It's not (currently) instrumented enough to help the me as a human make changes to the code without also just "bumping into the guard rails" to try and figure out what I broke along the way.

A middle ground orthogonal type system sounds really appealing to me. "Type coverage" is an idea I've been kicking around. Something like Spec in Clojure, but more symbiotic with the host code such that it can tell you things _about_ your code and help in refactoring, symbol resolution, etc..

That's a lot of words, but tl;dr I think I agree with you : )

Re: Deno will stop using TypeScript

#279

Post by cletus »

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…

Static typing shows you to eliminate the class of tests I like to call “spelling mistakes tests”, something I grew to loathe in Puthon. You have a method called doSomething. You’d better make sure your code isn’t trying to call doSomethign.

Compile time errors are much quicker and cheaper to detect and fix than runtime errors.

Post reply on HN