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

321–330 of 359 posts

Re: Deno will stop using TypeScript

#321

Post by preek »

Kinrany wrote: post #277
preek wrote: post #132

Earlier quoted context omitted.

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.

Not really in the same way, though.

I mentioned that paradigms of functional programming languages like Clojure translate well to JavaScript. They do not to typescript, because it is a statically typed language.

If you are interested in why are you dynamically typed language has benefits for functional programming, please see this talk: https://youtu.be/oytL881p-nQ

Re: Deno will stop using TypeScript

#322

Post by verdagon »

qayxc wrote: post #134
IBCNU wrote: post #91

I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.

> Types are for compilers, not people, and personally I think there's more disadvantages than advantages The Haskell community strongly disagrees...

I dont know Haskell that well, but I thought it had strong static typing?

Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?

Re: Deno will stop using TypeScript

#323

Post by NicoJuicy »

yawaramin wrote: post #315
NicoJuicy wrote: post #227

Earlier quoted context omitted.

I believe people here don't belong to the situation I mentioned. You are here because you are interested and want to learn. You probably know more than 1 language. But that is not the general developer. Most developers are lazy and at the end of the day, want to go back to their wife and kids ( for example).

Yeah, and there's absolutely nothing wrong with that. It's the sign of a healthy work-life balance. The real problem is that businesses don't want to train devs in the right tools for the jobs at hand, and are instead looking for the shortcut that will let them 'ship it'.

> Yeah, and there's absolutely nothing wrong with that. It's the sign of a healthy work-life balance.

I agree, never claimed otherwise.

Re: Deno will stop using TypeScript

#324

Post by vimslayer »

mirekrusin wrote: post #259
emptysea wrote: post #254

Earlier quoted context omitted.

Generics are supported via `@template` https://www.typescriptlang.org/docs/handbook/type-checking-j... types can be imported either explicitly via `require()` or via the `@type {import("foo").Bar}` There are definitely some limitations and caveats, like `Object` being aliased to `any` (I think this is being changed in a new version), but it's still way better than untyped JS, and having typescript integration is nice…

If it supports many constructs, why they don't switch to using it in deno?

I assume most of the minutes-long compile times they are running into are because of type checking. Moving types to comments wouldn't help that.

I don't konow why they aren't separating type checking and dev builds from each other, but there is just absolutely no way simple TS to modern JS (no compiling to old ES5) conversion would take that long for a 10k LOC project, it must be the type checking. I'm using TS through Babel and it has been a breeze for much larger projects than that. Babel just strips away the TS types and we do type checks via editor integration and a separate CI step. Can't recommend this setup enough.

Re: Deno will stop using TypeScript

#325

Post by mirekrusin »

vimslayer wrote: post #324
mirekrusin wrote: post #259

Earlier quoted context omitted.

If it supports many constructs, why they don't switch to using it in deno?

I assume most of the minutes-long compile times they are running into are because of type checking. Moving types to comments wouldn't help that. I don't konow why they aren't separating type checking and dev builds from each other, but there is just absolutely no way simple TS to modern JS (no compiling to old ES5) conversion would take that long for a 10k LOC project, it must be the type checking. I'm using TS throu…

It's not only compile times, it's also runtime code it generates and issues it creates in some cases, article mentions it.

Re: Deno will stop using TypeScript

#326

Post by holtwick »

I can fully understand that an additional tool layer can cause additional problems, but static type checking is a large quality win for large projects. There are workarounds to achieve similar results:

(1) Use a faster bundler like esbuild, here vite's similar considerations [1]

(2) Use Flow [2] and just strip it away before distribution like this Babel module [3]

---

[1] https://github.com/vitejs/vite#typescript

[2] https://flow.org/

[3] https://babeljs.io/docs/en/babel-plugin-transform-flow-strip...

Re: Deno will stop using TypeScript

#327

Post by tome »

klodolph wrote: post #274
chmln wrote: post #273

Earlier quoted context omitted.

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…

It was your GP who introduced the word "novice".

Re: Deno will stop using TypeScript

#328

Post by tome »

eyerony wrote: post #303
dtagames wrote: post #25

Earlier quoted context omitted.

I've been programming for 40 years and I agree. Strong typing has a religious quality. You have to believe that most errors are caused by type mismatch, and I simply don't believe that. Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc.

> poor documentation Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.

> > poor documentation

> Static types are documentation. Better yet they're documentation that can't go stale without a computer yelling at you that it's wrong.

Absolutely, and I'd go further:

"Most errors, in my experience, are caused by bad architecture, poor documentation, and poor communications strategies between MVC, etc"

Good static types (a la Hindley-Milner) encourage good architecture, serve is documentation that cannot go stale, and encourage good communication strategies between different parts of a codebase.

Re: Deno will stop using TypeScript

#329

Post by ZenPsycho »

hnarn wrote: post #102
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 We're pretty deep down in abstract discussions here and I have no idea what your code looks like or what it does, but I think it's helpful to point out that knowing the type means you already know the contents to some extent. The way I see it, checking if a value is what you expect is always good, but if y…

I want to know what kind of code you're writing where a number can suddenly become an email address. I certainly hope you're not using type checking as a substitute for input sanitization.

Re: Deno will stop using TypeScript

#330

Post by say-vagnes »

meowzero wrote: post #309
say-vagnes wrote: post #283

Earlier quoted context omitted.

Hey, I've also made the trip from Scala to Typescript. We're talking ZIO and Shapeless wrangling. Twitter vs Scala futures. All that fun stuff (and I loved scala nonetheless). Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for ho…

I haven't played with ZIO that much. I do like it though. It seems to make your Scala code much more functional. I'm 100% TypeScript now and miss Scala. I miss using monads. But since Typescript doesn't have for comprehensions, using any of the monad libs for TS (like fp-ts) is messier than plain old TS. Also, Typescript doesn't have pattern matching, thus ADTs are more painful in TS. But TS is a nice language. Inste…

A lot may have been simply my own inexpertise in Scala. But I remember it being much more of a fight, and subject to much more nuanced errors, to do anything interesting with generics or any more advanced typing. I would often stop, whereas at the same point in Typescript, I can just cast, and then see what actually happens at runtime. If I fail to be creative enough with my types, so long as I satisfy the type contract at some level, I can be wild wild west in the internals.

I do miss the for comprehensions, but have built an abstraction that does the same thing for my purposes. It isn't quite as good, due to the whole monad thing, and me fitting it to the average Javascript programmer who won't want to learn functional programming all at once. So at its core it is pretty much async/await with sugar.

I quite enjoy exploiting structural typing for unit testing purposes. Gone is the need to learn a mock framework and its DSL; just write plain ol' JS for the parts you are interested in, and tell the compiler to chill. ;) Long term, of course, you should probably just have doubles.

Post reply on HN