Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

261–270 of 359 posts

Re: Deno will stop using TypeScript

#261

Earlier quoted context omitted.

JS has a great future: first class ubiquitous promise + async-everything. Can't find that in Ruby/Python/PHP, you have to use something like Twisted/asyncio which limits you to a bolted on subset of the ecosystem, unlike in JS. Very dishonest take btw. Here's a forum of people who could tell you why they use JS instead of your $favelang, yet instead of trying to figure it out, you just assume everyone is lazy or a ju…

Go and Erlang (or Elixir) both have a better async model, and are pretty much better designed on all points. So for the rare cases where async does matter (and they are a niche, given even big names like facebook code behind async proxy and do long polling), there are still little reason to choose JS. I can't think of a single mission where, if I were not being forced to use it, I would chose it over something else.…

>Any tech that would have had half the resources poured into it would today be the incarnation of skynet.

Java?

Re: Deno will stop using TypeScript

#262
post #97

Earlier quoted context omitted.

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. That sounds fine, as long as no-one else will ever have to read or work on your code.

Including future you.

Re: Deno will stop using TypeScript

#263

Earlier quoted context omitted.

Here's a pretty sizable project I wrote in pure TypeScript: https://github.com/Clay-Ferguson/quantizr I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.

I do understand the value, thanks mostly to Haskell. I also know that (language- or tool-enforced) type safety and type discipline are separable concerns. I also understand when the former gets in the way, thanks to JS, TS, Rust, Lisp, and projects large and small, slow and then fast, fast and then slow, slow and then slow, and fast and then fast.

Every developer, regardless of skill level, makes mistakes and typos. The beauty of type-safety in TypeScript is that the compiler catches it instantly, in a way that is simply humanly impossible.

If I misspell something, or provide the wrong argument type to a method, or have args in wrong order, etc, it's caught instantly.

With JS you can have a typo that causes user malfunctions for YEARS before being found by a developer and fixed. Any developer who's done many years of both TS and JS would never in a million years consider going back to JS. Absolutely out of the question.

Re: Deno will stop using TypeScript

#264

Earlier quoted context omitted.

I have a hard time believing that. We have 10k lines of typescript and that take forever to compile compared to 5x more of the ReasonML code we have that compiles instantly

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?

Much faster compiles times sounds like a good reason to me ;)

Re: Deno will stop using TypeScript

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

> not worth the small benefits which static typing brings.

pshh

Re: Deno will stop using TypeScript

#267

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…

These two have me confused:

"TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process"

and

"The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files"

If you're compiling Typescript, the .d.ts files are output by the compiler. The only time you need to manually keep them in sync is when you're writing .js and manually writing the .d.ts.

Re: Deno will stop using TypeScript

#268
post #260
post #224

Earlier quoted context omitted.

Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.

I thought the "novice" programmer remark was a pretty cringe-worthy comment. The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".

I can sympathize with their issues. TS compiles are slow as fuck, and if I could find anything that was just as nice without the long compiles I’d switch in a heartbeat.

But I don’t think I’d ever want to go back to plain Javascript.

Re: Deno will stop using TypeScript

#269
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 is enough reason for me to completely forget Deno. They clearly cannot write code or organize it without using classes, which is the core of their current error. The fact that they would choose that stupidity over the organizational benefits of interfaces and static types is not something I can reconcile.

[deleted]
Post reply on HN