Deno will stop using TypeScript • Hacker News Board

Re: Deno will stop using TypeScript

#191

Post by inimino » Sun, Jun 21, 2020, 6:21 PM UTC

devit wrote: post #31

It seems it might be an issue with their development abilities or problem-solving motivation: 1. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action. 2.…

Thank goodness the noobs that brought us Node.js have you, random HN commenter, to explain CS 102: Intro to Software Engineering to them.

Have you considered that the people making this decision might just possibly have more relevant experience than you do?

Re: Deno will stop using TypeScript

#192

Post by inimino » Sun, Jun 21, 2020, 6:23 PM UTC

WClayFerguson wrote: post #73

Using JS instead of TypeScript is very short-sighted and they will regret it, eventually. Sounds like they got frustrated and gave up. Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc. All you're doing by switching from TS to JS, is trading one set of minor problems (which…

Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.

Re: Deno will stop using TypeScript

#193

Post by heavyset_go » Sun, Jun 21, 2020, 6:24 PM UTC

RivieraKid wrote: post #63

I wish Dart was more popular as a JS alternative. I've been using it recently it's really surprisingly productive and fun.

Does Dart still allow you to compile to JS or was that feature dropped?

Re: Deno will stop using TypeScript

#194

Post by inimino » Sun, Jun 21, 2020, 6:26 PM UTC

war1025 wrote: post #57

wufufufu wrote: post #26

Has anyone else experienced these issues? This reads more like product placement for Deno than a sincere criticism of TS.

I've definitely noticed that compiling typescript is slow and extremely resource hungry. It's amusing to me that our "web" stack is the most resource intensive part of our entire codebase at work. A sign of the times I guess that a build system requires 8gb of ram to run. Could be we're doing something wrong, but from what I understand we're using a pretty vanilla setup.

Unfortunately the state of web dev in 2020 is such that using a vanilla "best practice" setup is very much doing something wrong.

Re: Deno will stop using TypeScript

#195

Post by vorpalhex » Sun, Jun 21, 2020, 6:26 PM UTC

BiteCode_dev wrote: post #177

vorpalhex wrote: post #159

Earlier quoted context omitted.

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

Sure and julia has the best matrices, python has the most flexible threading models, erlang has the best distributed runtime..

Yet one feature does not a language make. A language is the whole of it's behavior, and JS is a perfectly fine solution with a wide mix of good features.

Is it the fastest? No. The most performant? Not close. Does it have the best ability to write language parsers? No!

But it's not supposed to. It's a general purpose language that's well suited for a wide swath of cases.

Most languages have transpilers and utility libraries - and those are useful tools but also not meant to be part of a language. Even python has dozens of compilation tools depending on how you intend to distribute your code.

It's the mark of a poor intelligence that buys on pros only without considering cons. We must weigh not only our features but how well the average engineer can use it, how quickly we can produce features and how safe our code is, and how easily we can actually hire and train engineers.

JS is one of the most popular languages in the world. My 10 year old nephew can write it and do a decent job of it.

Re: Deno will stop using TypeScript

#196

Post by austincheney » Sun, Jun 21, 2020, 6:26 PM UTC

eitland wrote: post #171

jorams wrote: post #133

Earlier quoted context omitted.

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?

It is something to do with a class in their code named something similar to header conflicting with a same named definition in their index.d.ts file that is closely related to that class instance.

If they dropped use of classes, or differentiated the names of the two things in collision the problem would appear to be solved.

To turn that around and blame TypeScript as the point of failure is an extremely bad omen suggesting their code style opinions are more important than product delivery. I could live with that nonsense if this were a framework or some minor dependency, which this application is not.

Re: Deno will stop using TypeScript

#197

Post by carapace » Sun, Jun 21, 2020, 6:26 PM UTC

mimixco wrote: post #16

echelon wrote: 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…

Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.

> JS ... is the most successful and important language in the world (probably in the history of programming),

I object, C is that.

Re: Deno will stop using TypeScript

#198

Post by oliwarner » Sun, Jun 21, 2020, 6:27 PM UTC

You know when you say a word over and over again and it starts to lose meaning?

Well, I didn't have a clue what Deno was before, but now it's barely letters in a screen. This post says Deno way too much. Deno.

Re: Deno will stop using TypeScript

#199

Post by vorpalhex » Sun, Jun 21, 2020, 6:31 PM UTC

eitland wrote: post #182

vorpalhex wrote: post #116

Earlier quoted context omitted.

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

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 than a language like C or Java.

There are other languages that have a similar level of being easy to understand such as Python and Ruby, and they're good languages too but have a different set of tradeoffs.

Re: Deno will stop using TypeScript

#200

Post by austincheney » Sun, Jun 21, 2020, 6:32 PM UTC

shirshak55 wrote: post #127

austincheney wrote: post #37

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.

The technical problem is a class name in their code conflicting with a same named definition in their index.d.ts file closely related to that class. If they stopped using classes or changed those names to not be in collision this problem would be cured, which indicates it’s an edge case in their code they could easily fix but choose not to. Knowing that and that they blame the TS compiler for their code problem is cause enough to be judgemental.

Knowing they are aware they could easily fix this issue themselves but are instead dumping TS is cause for hesitation to invest in the project.