Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

331–340 of 359 posts

Re: Deno will stop using TypeScript

#331
post #268
post #260

Earlier quoted context omitted.

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.

There are efforts to provide faster compilation times: - https://github.com/evanw/esbuild - awesome, I use it for most of my ts projects - https://swc-project.github.io/ - also awesome, but has some bugs

Re: Deno will stop using TypeScript

#332

Earlier quoted context omitted.

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?

Good example.

The JVM is one of the most amazing piece of tech ever created. It's so good it supports not only what has been most the popular language in the world for years, but many newly popular languages like Kotlin or Closure. The perf have been optimized so much they are getting about 70% of C/C++, but with high level paradigms. It can pretty much do everything.

In fact, it runs on everything. It used to run on old school nokia phones. It runs on some credit cards! Despite being slowed down by patent trolling, Java found its way to more than half the modern mobile phones in the world throught Dalvik reimplementation.

It's everywhere.

Today, it is still ranking #2 on TIOBE and PYPL, despite having to leave with 2 decades of legacy design decisions and no monopoly.

Re: Deno will stop using TypeScript

#334
post #331
post #268

Earlier quoted context omitted.

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.

There are efforts to provide faster compilation times: - https://github.com/evanw/esbuild - awesome, I use it for most of my ts projects - https://swc-project.github.io/ - also awesome, but has some bugs

Esbuild is cool, but if it doesn’t check the types then using Typescript is a bit pointless in the first place.

Guess a combination of esbuild during development, and tsc during commit would be the best of both worlds.

Re: Deno will stop using TypeScript

#335
post #331
post #268

Earlier quoted context omitted.

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.

There are efforts to provide faster compilation times: - https://github.com/evanw/esbuild - awesome, I use it for most of my ts projects - https://swc-project.github.io/ - also awesome, but has some bugs

Thumbs up for esbuild, it's awesome.

Re: Deno will stop using TypeScript

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

Maybe you are one of those 10x programmers who can magically keep track of all the type data in your head and always catch yourself before you push to prod.

I and most people however are human and make mistakes sometimes. Worse, the bigger the project, the more you need to collaborate between people and sometimes teams. Types are almost like docs that check your code at compile time and reduce the chances of human error creating a production failure. Its not a panacea but its certainly nice to know that if I change a functions parameter, that the system breaks someone else's code depends on that function following a certain signature. At that point, I can either write a different function, message him to update his code or discuss how to make the changes together. All 3 cases are MASSIVE upgrades over fiding out shit broke in prod with some undefined behavior arising.

Re: Deno will stop using TypeScript

#337
post #321

Earlier quoted context omitted.

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

Typescript typing is fundamentally optional, so this criticism, even if true regarding statically typed languages, does not apply to Typescript.

Typing is optional both for individual variables via the `any` type, and compiler-wide, by configuring it to assume untyped variables are `any` by default.

Re: Deno will stop using TypeScript

#338

Earlier quoted context omitted.

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

> Any developer who's done many years of both TS and JS would never in a million years consider going back to JS. Except, apparently, for the topic of this article. > If I misspell something, or provide the wrong argument type to a method, or have args in wrong order, etc, it's caught instantly. Yes, I've heard the pitch before. I've even given it more than a few times. Of course, if both of your arguments happen to…

> Except, apparently, for the topic of this article.

Well, Deno devs did try to use TypeScript, and just ran into some challenges, and decided to throw the baby out with the bath water. I've seen this a lot in my 30yrs exp.: some developer/team runs into problems, gets frustrated, gives up, and decides the best decision is to remove some important piece rather than solve the actual problems.

The reason Deno is giving up TypeScript is representative of failure, and not an indication them wanting JS instead of TS. What they want is TS.

The rest of your reply is just stating some minor imperfections that are a billion miles from invalidating TS. And yeah, there's a place for JavaScript still, for small-scale tinkering, or perhaps even prototypes with only a few hundred lines of code. Any large scale project in JavaScript (not TS) is simply unfathomable to any modern developer worth his salt.

Re: Deno will stop using TypeScript

#339

Earlier quoted context omitted.

Event threading pulls out a huge amount of difficulty with semaphores, locks, thread safety, etc. The lack of OO means no typecasting, inheritance models, interfaces, etc. Arrays are fully dynamic, not type restricted and operate strictly by reference. No memory mapping, manual garbage collection or even GC adjustments. Suddenly the list of things someone has to understand to be a competent JS engineer is way smaller…

Have my upvote for the serious answer. Let's just say we have different opinions. Here's my attempt to create something similar from my perspective: - Being able to know to at any point what a variable can contain is very liberating. (Ok, you can define a list of Object that behaves just like a list in JS: "fully dynamic, not type restricted", but thankfully for people like me that is not common in Java anymore.) - K…

It's a tradeoff. Dynamic isn't "better" than typesafety, but it's generally easier to comprehend and reason about. Just yesterday, I was working on a C# script and encountered the following problem:

+ An engineer had written a script with a Dictionary of type . If you've touched Unity, you immediately caught the flaw: Transform's aren't unique enough keys and it's really easy to end up trying to add Duplicate keys, even though you really mean different objects.

+ So, since we don't care about uniqueness, shift from a Dictionary to a List. Except we have a problem, because we need to keep that Key->Value relation so we know what transforms get what materials. Well, we have a solution to that, it's yet-another-type called a KeyValuePair.

+ Well we're now nesting a generic KeyValuePair that needs type information inside of a list that is holding objects, which also changes how we iterate through that list and add items to it.

+ In a language like JS, everything I just said doesn't matter at all because instead of using a Dictionary (Map in JS), we would of just said "Use a Set instead". Done.

Re: Deno will stop using TypeScript

#340
post #327

Earlier quoted context omitted.

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

It’s not the word, it’s the sentence.
Post reply on HN