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

181–190 of 359 posts

Re: Deno will stop using TypeScript

#181

Post by vimslayer »

yawboakye wrote: post #176
diffrinse wrote: post #152

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 e…

Elm doesn't need to perform runtime checks (apart from application boundaries like JSON parsing, where runtime checks are performed) because their type system is supposed to be sound, so you can't compile something that would have incorrect types at runtime. Or if you can, that's considered a bug in the compiler. That kind of sound type system has never been a goal for TypeScript.

Note that I'm not saying that Elm would be better than TS or any other language or anything like that, just commenting about the runtime checks. Obviously languages have their strengths and weaknesses (Elm has plenty of both) and TS has had good reasons to go with their design goals.

Re: Deno will stop using TypeScript

#182

Post by eitland »

vorpalhex wrote: post #116
NicoJuicy wrote: post #99

Earlier quoted context omitted.

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.

> Easy to reason about,

I'd like to know what language you use as a baseline for this?

I made my first "real" Javascript code back in 2005 (a vector map system that worked in realtime) and I've been working mostly with frontend for the last 3 years so it is not lack of familiarity. In between that however I have programmed a lot of other languages, worked in a number of different teams, written new code, maintained old code and generally gotten some perspective on life.

That perspective has sent Javascript down my list of languages that are easy to reason about.

Re: Deno will stop using TypeScript

#183

Post by wereHamster »

untog wrote: post #147
wereHamster wrote: post #145

Earlier quoted context omitted.

Is SystemJS still a thing? What's their point now that browsers support ESM natively?

Deno != browser

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

Re: Deno will stop using TypeScript

#184

Post by diffrinse »

samhh wrote: post #168
diffrinse wrote: post #152

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…

TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.

But this is a niche application of TypeScript, most day-to-day front-end devs I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the benefits.

Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started.

For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript.

tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?

Re: Deno will stop using TypeScript

#186

Post by heavyset_go »

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…

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

Will you in two years? Will your coworkers? Will the contractor who has no context for the code understand it?

Like variable names, types convey information that are crucial to the understanding of your application.

Under the hood, there are "types", even if they are weak, so you'll need to know about implicit typing anyway. Making them explicit is both a way to test correctness and a way to document your code.

Re: Deno will stop using TypeScript

#188

Post by Shacklz »

samhh wrote: post #168
diffrinse wrote: post #152

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…

TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.

Wholeheartedly agree and would like to point to another library that is capable of providing runtime typechecks: https://github.com/vriad/zod

It doesn't come with the fp-approach that io-ts takes, and has, in my opinion, significantly better error reporting. Just plugging this here because I believe that zod is grossly underused :)

Re: Deno will stop using TypeScript

#189

Post by austincheney »

jorams wrote: post #133
austincheney wrote: post #120

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.

You can do any manner of stupid things to make any compiler of any language to behave slowly, but that doesn’t mean all compilers are slow. If you want better output don’t deliver garbage for input.

Re: Deno will stop using TypeScript

#190

Post by erikerikson »

baddox wrote: post #154
underdeserver wrote: post #46

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…

Your main point seems to be that these problems aren’t the language’s fault. But I don’t see the Deno team claiming that to be the case. There’s nothing wrong with choosing a language that works with how your team likes to develop software, and rejecting a language that doesn’t work well for your team. Doesn’t need to be anyone’s “fault.”

It's entirely valid for them to decide they don't want to change their ways. However, it is frequent that technologies will be rejected because the requisite learning to understand why and how to best use the technology is not done. A common example of this (in my observation and ignoring the application of the technology where it's entirely unnecessary) is NoSql where teams have attempted to use those databases as they used their relational counterparts which obviously didn't work because they didn't shift how they were thinking about using storage and structuring their systems. Anyway, that was how I read the GPs post, as attempting to note that the Deno team may not have pushed through the mental shift required to really get the most out of TypeScript.

[edit: not trying to take a stance in support of the GPS post or either side of this discussion, to be clear]

Post reply on HN