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

221–230 of 359 posts

Re: Deno will stop using TypeScript

#221

Post by hombre_fatal »

kbenson wrote: post #130
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.

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.

Yikes to see people assume so little about others. Why not ask people why they use Node instead of assuming the worst about them?

You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem.

Btw, what's lazy is making convenient uncharitable assumptions about others than just... asking.

This forum is full of people who could tell you why they still use JS after they analyze pros/cons of other languages.

Re: Deno will stop using TypeScript

#222

Post by mirekrusin »

I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn't work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type declarations and when declaring functions and pretty much nowhere else. The code has interesting haskell'ish feel to it, ie. most of the code looks something like this:

  const ofId /*: (Sql, number) => Promise */ =
    (sql, id) =>
      ...
I'm very happy with it after using it on quite complex projects, writing libraries (ie. functional combinators for parsers, assertions/runtime types, template sql generators; and the rest from apis, business logic to anything that is needed).

Lack of libdefs is not a huge problem in my case. I have strong preference for shallow or no dependencies in projects and for things I use 3rd party code there are types or were converted from ts or simply added. Better support would help here but it was not a deal breaker.

Code editor support is not as good as ts but it does the job.

Another interesting effect is that arbitrarily deep npm linking is so much easier, the code is just js, doesn't need transpilation step, can be edited as is; I'm free to use any directory structure, ie. I often use root directory to drop files, they have natural require/import paths, no configuration etc.

For me, it's a joy to code like this.

Re: Deno will stop using TypeScript

#223

Post by kohtatsu »

petersellers wrote: post #218
thegreatpeter wrote: post #210

Earlier quoted context omitted.

I have a hard time believing that. We have 10k lines of typescript and that take forever to compile compared to 5x more of the ReasonML code we have that compiles instantly

You have a hard time believing that their team experienced more happiness and productivity with TS...because your ReasonML code compiles a lot faster than your TS code?

I've actually been (very) wary of adopting TypeScript once I learned of the multi-second compile times, even for tiny projects.

I had actually been watching Deno in case they solved any of that.

Re: Deno will stop using TypeScript

#224

Post by snek »

inimino wrote: post #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 mor…

Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.

Re: Deno will stop using TypeScript

#225

Post by Rapzid »

ctrl-j wrote: post #44
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.

I like typescript not because it prevents most errors in my code, but because it prevents some errors. Those errors, in my experience, tend to be ones that are time consuming to identify and solve. A value of the wrong type passed forward because it's almost the right type can cause errors that make their way into production. I hear you say "so unit test your code!", and to that I reply, we're a c# shop that has only…

I've spent more time helping people hunt down "undefined is not a function" and "Cannot read property of undefined" than just about anything else. Two observations from this:

1.) The fact that I even got involved meant the issues were particularly hard to track down

2.) These errors seem to be more of a time sync within a larger team/project than many realize

Typically these were caused by either scope issues and/or some context object that's been riding dirty all day. In the case of the latter hunting down the code that did the naughty can be particularly soul crushing.

Re: Deno will stop using TypeScript

#226

Post by emptysea »

mirekrusin wrote: post #222

I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn't work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type dec…

typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-j...

I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works!

Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.

Re: Deno will stop using TypeScript

#227

Post by NicoJuicy »

hombre_fatal wrote: post #221
kbenson wrote: post #130

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.

Yikes to see people assume so little about others. Why not ask people why they use Node instead of assuming the worst about them? You don't think JS is obviously unique for its ubiquitous Promise, async/await, + async-everything abstraction. You tend to only get that in other languages (Rust, Python, Ruby) by limiting yourself to a fraction of the ecosystem. Btw, what's lazy is making convenient uncharitable assumpti…

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

Re: Deno will stop using TypeScript

#228

Post by balfirevic »

elmo2you wrote: post #96
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.

I have a little less experience, only 30 years, but I have to fully agree with you. Not sure why you got down voted (maybe the religious popularity crowd rearing its head). I have seen my share of "innovations" come and go, but I too fail to see the empirical evidence that most bugs/errors are caused by type mismatch. In fact, I would even go as far as to argue that in my experience the benefits of typed languages (a…

> Not sure why you got down voted

For the (pretty obvious) logical error of claiming that you have to believe that most errors are caused by type mismatch to consider stating typing beneficial.

Re: Deno will stop using TypeScript

#229

Post by Rapzid »

kthejoker2 wrote: post #67
whoisjuan wrote: post #10

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It…

> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. This is true, and confirmed by the TypeScript team https://stackoverflow.blog/2020/06/15/talking-typescript-wit... > Do you remember why the team came up with TypeScript, why you wanted to release something like this? > A: When I…

> TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature

Seriously?

> They wanted to have that static typing available both for conceptual scalability and for the tooling

Sounds like they understood the loose nature pretty darn well.

Re: Deno will stop using TypeScript

#230

Post by goliatone »

echelon wrote: post #22
whoisjuan wrote: post #10

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It…

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…

Personally I have two issues with TS as it exists today. On the one hand I’m reticent to add a transpiler/compiler step between code and the runtime unless there is a very very compelling argument. On the other my perception of TS is that is a tool that removes friction between the language (JS) and tooling without really addressing anything core to the language itself. Everything people sum up as pros of using TS generally end up in a bucket in my head labeled “compiler work to remove friction”. I actually use that friction to improve my codebase, in the instances that some sort of type error happens usually is bringing to the surface an related problem/business domain assumption on my part that I need to address upstream to a conceptual or logical off code layer. Some of what TS offers I get around by being very attentive to providing good jsdoc annotations which requieres disciplina and work- so I see the value brings there but the price I pay for that convenience is to high.

Usually what I do is that once a project has reached a point of maturity and the requirements merit it I move parts of it to a typed language (go). That’s for things that need to be both performant and maintenable long term without much effort.

I actually benefit from that rewrite in that I have yet another chance to review assumptions and address higher order

Post reply on HN