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

301–310 of 359 posts

Re: Deno will stop using TypeScript

#301

Post by kiliancs »

goostavos wrote: post #272
kohtatsu wrote: post #223

Earlier quoted context omitted.

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.

They become really frustrating as the project grows in size. Personally, it becomes really difficult to maintain productivity. As compile times tick up, I start bouncing over to other tabs rather than just twiddling my thumbs starring at a terminal. Then I realize I've been on Reddit for a half-hour. I recently watched this talk by Johnathan Blow[0] where he talks about quality of life in programming languages and sp…

I don't love the compile times, but I'll also say with TypeScript I tend to check the browser that often. TS also means simpler refactoring, for example.

Note also: * type checks can run in parallel, so they won't block your other build block * the tsc has been making gradual improvements to performance and techniques to improve compilation and type checking * there are speedy alternatives to the TypeScript compiler (tsc) (eg: https://sucrase.io) for transpilation

Re: Deno will stop using TypeScript

#302

Post by thayne »

There are tools to transpile typescript only, without doing typechecking, which dramatically reduces "compile time." It's very useful for a quick development iteration cycle, and then do a full type checking pass before merging and during CI.

Re: Deno will stop using TypeScript

#303

Post by eyerony »

dtagames wrote: post #25
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…

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.

Re: Deno will stop using TypeScript

#304

Post by eyerony »

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 re: time.

Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people.

As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.

Re: Deno will stop using TypeScript

#305

Post by waheoo »

snarfy wrote: post #43
efficax wrote: post #19

Earlier quoted context omitted.

there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.

For dynamically typed languages, the idea is you make up for that class of bugs by incorporating TDD and having lots and lots of unit tests. So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.

If youre doing tdd or writing tests like this you have bigger problems.

Type safety is easy in a dynamic language. Stop mutating variables and stop mixing types. Suddenly that whole class of errors evaporates. No need to test things that are impossible.

And for those times you want some magic in your life, nothing is stopping you, no need for generics, just proceed with caution and test accordingly.

Re: Deno will stop using TypeScript

#306

Post by orangecat »

josephg wrote: post #285
orangecat wrote: post #143

Earlier quoted context omitted.

You need integration-level tests around every method call Sure, but you need those tests anyway to verify that your code actually works. I agree that type systems reduce the occurrences of some classes of bugs; I'm only disagreeing with the claim that they reduce the amount of tests you need to write.

I used to agree with you, and somewhere in my comment history on HN you’ll find similar comments to yours. But I think I was wrong. I recently ported some (quite complex) code I wrote from JavaScript to Typescript. The code has about a 2:1 test to code ratio, and a fuzzer for correctness. While porting, I ended up adding a couple “useless” assert(typeof x === ...) calls to quieten the compiler, which felt useless bec…

Generally I find that the bugs that are easy to find with tests and the bugs that are easy to find with static types are different.

I don't think we disagree much. As your experience shows, trying to replicate type checking via unit tests is almost always impractical. Which means the tradeoff of not having static typing is not that you're writing more tests, but that there's an increased chance of bugs.

And I agree that once a JS project is large enough to have a build process, the benefits of TypeScript almost always outweigh the costs. I'd even like to see JS interpreters allow and ignore TypeScript types, so you could use it without a build step.

Re: Deno will stop using TypeScript

#307

Post by zodiakzz »

kumarvvr wrote: post #126

HN gods, an off topic question. Would Deno become the new Node? Do you see a vibrant ecosystem building around Deno? What I am interested to know primarily is, is the architecture / stack / goals and vision that resulted in Deno viable in the long term?

Deno's main selling point over Node.js seems to be some dubious sandboxing. Unlikely to be compelling enough for people to rewrite their applications from using Node's stdlib to Deno's.

Personally, it makes me cringe to see hard-coded HTTP URLs in source code files for loading dependencies. They present it like we're stupid for using package managers all this time. What used to be a simple command line option (changing a package repo) is now a thousand file edit. Excellent.

Re: Deno will stop using TypeScript

#308

Post by echelon »

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…

> maybe much more so than novice programmers can appreciate

Okay, unsubscribe. This is not the tone you use to interact with the community. This is brash, elitist hogwash.

Re: Deno will stop using TypeScript

#309

Post by meowzero »

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

Earlier quoted context omitted.

I've developed with JS, PHP, and Ruby for about 5 years. Then I switch to statically type languages for the next 5 years (Scala then to Typescript). If I had to choose, I would choose static typing. For small projects, dynamically typed languages are fine. but as the project grows bigger, the static typing will help and will make thing simpler. As the project grows, refactoring will be an issue. Static typing will ma…

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. Instead of monads, they have stuff built into the language to make things easier and cleaner like null coalescing (compared to Option) and async/await (compared to using IO or Future). I can live with that. I've grown to like TS.

I'm curious what abstractions you had easier time with in TS compared to Scala.

Re: Deno will stop using TypeScript

#310

Post by luord »

honkycat wrote: post #294
luord wrote: post #292

Earlier quoted context omitted.

> "That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. Oh, wow, given this unnecessarily combative start, am I about to finally read conclusive proof that will stop that over sixty years old flamewar? > I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand…

> Can't do that with static languages either. Call it a type (or class), call it a parsing function, ultimately the result is the same. You need something to ensure that it is an url. Those exist in dynamically typed languages and are not obviated in static ones. In a loosely typed language you cannot have compiler-level enforcement that a variable has been produced by a factory function that ensures that the passed…

My previous comment was merely an attempt to mention how participating in this flamewar leads nowhere. I'm certainly not about to get into it by discussing details of the good and the bad and even the necessity of compile time checks of whether a string is a url.

Hundreds of books have been written on the matter, and the results are still inconclusive.

> Is it my opinion though? Or did I pull it straight out of Building Secure and Reliably Systems, a book written by Google engineers to express industry best practice for developing software at a scale?

Yes and yes, you happen to share their opinion.

Now, should we pretend that appeals to authority turn an opinion into fact now? If so, to whose authority should we appeal? Theirs? The different google engineers who work in more dynamic languages? Hell, designers of dynamic languages who have worked at Google? The people who designed and work in LISP or any of its derivates? Whose authority weighs more?

Or maybe we should acknowledge that appeals to authority hold no real decisive value in deciding something like this, and instead contribute to studies trying to gauge how effective different type systems actually are.

Except that even those turn into flamewars: https://www.hillelwayne.com/post/this-is-how-science-happens...

Post reply on HN