Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

171–180 of 359 posts

Re: Deno will stop using TypeScript

#171
post #133

Earlier quoted context omitted.

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.

My 3 year old laptop has no problems with TypeScript (neither Angular nor React), and I am a rather impatient guy when it comes to computers.

I'm honestly wondering: What are people doing to end up in a position where TypeScript compile times are a problem?

Re: Deno will stop using TypeScript

#172

Earlier quoted context omitted.

Working on half a million LOC TypeScript codebase. All strict flags up, low-2-digit team size. We don't really run into many problems. TypeScript is not perfect, but developer happiness and productivity have definitely increased since we adopted it, and defect rates have dropped significantly --while increasing the size of the team & working on more features.

Think of the change as a statically compiled language writing parts of their runtime with assembly or unsafe pointers. It’s not an indictment of TypeScript.

My first impression of the reasons in the design doc is that the change is not well justified, but I also see the point you make; my response, though, was to the direct parent comment.

Re: Deno will stop using TypeScript

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

Further, even if they drop typescript, this particular problem won't go away. The solution to this problem is the same regardless of whether typescript is in play. It's odd to count it as a problem with typescript.

Re: Deno will stop using TypeScript

#174
post #156

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. How many times has six-months-hence you cursed you for this attitude? Be honest.

Never. This is why we write small functions that, as much as possible, depend only on their inputs and avoid mutation. Code becomes simple to reason about. You don't need to worry when composing these small pieces like you do when passing mutable objects, using out variables, etc.

See, that's interesting. 'Cause I do write small functions, I do avoid side effects, I do avoid mutation--and writing code in dynamically typed languages still bites me when I'm forced to do it. (It isn't really any faster to write, either.)

So you could be leaps and bounds better than me. Or you could be--let's be generous and call it "optimistic to a fault"--and retrofitting to a narrative about Good Programmers Don't Need Guardrails. And, TBH, I see a lot of people who are the latter and very few who are the former--and most of that very few tend towards statically or at least optionally typed languages by default. So forgive me if I don't believe you.

Re: Deno will stop using TypeScript

#175
post #79

Earlier quoted context omitted.

Lisp is not popular. Remove the browser practical monopoly, and JS popularity would vanish.

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.

> It's actually possible for people to like it.

If they started using PHP, without monopoly, they would not have switched to JS.

But plenty of people have switched from PHP to python or ruby.

> Also, languages are always a function of their ecosystems. You could argue, remove Apple products and Swift/ObjC would vanish.

Python, C and Java are not.

Re: Deno will stop using TypeScript

#176

I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol' JavaScript. You still can't trust function parameters to be what they say. It's a Babel configuration with inline doc…

AFAIK Elm doesn’t perform runtime checks, does it? One benefit of types is auto-complete, of course. The other benefit is that knowing the type of your input you can successfully guide it through your system to an expected output. That’s how all statically typed languages work: they don’t have runtime checks. It’s not for nothing that teams switching to TypeScript see a decrease in runtime exceptions (speaking from experience). Our bug tracker was reduced by more than 80% after we finally completed the switch from JavaScript to TypeScript.

Re: Deno will stop using TypeScript

#177

Earlier quoted context omitted.

The only really unique thing JS is bringing to the table is that it also has a privileged position in the front end. Your list of benefits it provides boils down to stuff multiple large languages all have, and the one thing that means you can learn just JS. GP comment was presented somewhat snarkily, but I'm not sure they're all that wrong.

Sure other languages have some pieces of the puzzle - python has tons of libraries and is easy to understand, golang has great performance and is easy to write, etc. But I have yet to find a language that has the same set of features except JS. If you want to offer up an alternative, please do so.

JS has zero unique set of feature.

There is not a single feature in JS you can't find elsewhere, often better implemented.

If anything, the vast majority of scripting languages (Python, Ruby, PHP...) have more features than JS.

JS is so lacking in features that half of its ecosystem is dedicated to compensate for that (typescript, babel, webpack, undersacore...).

Re: Deno will stop using TypeScript

#178

Earlier quoted context omitted.

Lisp is not popular. Remove the browser practical monopoly, and JS popularity would vanish.

I disagree on the current sentiment but agree that browser monopoly pushed js on people. If js didn't evolve over the last few years (since es5), I would have believed removing it from the browser would kill it. Right now, you have options to avoid writing js at all. There might be some glue code in js but you can write vast majority of your code in other languages and target js. People still choose to write in js. P…

> Purescript, elm, clojurescript, kotlin, bucklescript, and the list goes on. There is a to-js transpiler for every popular language. Why aren't they seeing more usage?

Because a layer of indirection is a heavy price to pay.

If I could code in Python with zero cost in the browser, I would. Hell, I would code in Lua, Lisp or Ruby if that was the alternative.

Re: Deno will stop using TypeScript

#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 more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.

Re: Deno will stop using TypeScript

#180

Earlier quoted context omitted.

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.

remember deno is written by same person who wrote node js so please don't judge immediately.

That's even more reason to disregard it then
Post reply on HN