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

231–240 of 359 posts

Re: Deno will stop using TypeScript

#231

Post by yawaramin »

snek wrote: post #224
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.

That passage didn't say anything about finding the document 'amusing'.

Re: Deno will stop using TypeScript

#232

Post by stickfigure »

pmontra wrote: post #140
stickfigure wrote: post #123

Earlier quoted context omitted.

Let's say you have a method that takes a thing : function doSomething(thing) { ... } How many different possible representations of a 'thing' do you have? A json object? A class object with behaviors? A database id? Some sort of natural key like a SKU? A URL? Is it a metric or imperial thing? You need integration-level tests around every method call to ensure that caller and callee agree what kind of 'thing' represen…

I never throw inputs of random types to my functions. Actually that could be a good idea, some fuzzying at the public API level could catch some bugs and attacks. But not at unit test level. If a function expects an integer argument I test it with integer values. That in Node, Ruby, Python and Elixir. I never saw anybody doing something different. Well, if we wanted to enforce types we could use any static typed lang…

If a function expects an integer argument I test it with integer values.

Metric or imperial integers? Your unit tests failed to prevent this $300 million blunder:

https://www.wired.com/2010/11/1110mars-climate-observer-repo...

But more commonly what is going to happen is that someone (two years from now) is going to change a 'person' parameter from legacy SSN to database id and some users are going to get "you don't exist" when they show up at the hospital to get medical service.

You're right though, most folks in the JS/Ruby/Python ecosystems don't do this kind of testing. It's a recurring joke:

https://www.google.com/search?q=2+unit+tests+0+integration+t...

Re: Deno will stop using TypeScript

#233

Post by yawaramin »

kybernetikos wrote: post #141
chmln wrote: post #75

Earlier quoted context omitted.

10K is a lot of code. As a maintainer of a popular 3k LOC typescript library, even at 1k LOC you start running into frequent type-related bugs with JavaScript

I've worked on javascript codebases pushing half a million lines of code, and my memory is that we didn't run into type bugs all that often. The biggest downside was the lack of automated refactoring tools - this was many years ago now. It did take quite a bit of discipline, but with a skilled team it really wasn't all that hard.

> The biggest downside was the lack of automated refactoring tools

That's what a typechecker gives you–an automated enforcement mechanism for ruling out certain errors during refactoring.

Re: Deno will stop using TypeScript

#234

Post by Rapzid »

tengbretson wrote: post #60
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…

The thing I have found the most useful with typescript is that it punishes you for doing the kind of cutesy stuff that permeated the node ecosystem in the early days. "Pass in three parameters with a callback in the fourth position. The second param is configuration so pass in a string, but if you need to really customize stuff actually pass in an object instead and by the way if you don't have a third parameter then…

Yes! My pet peeve with public APIs are DTOs that are like this!

"This is an array of strings, but it could be an object. If it's an object it will have this key and based on the name of the key it's this type. But it could also have or not have this other key and..."

ARghhhh! You can tell what kinda language the back-end was written in with that crap because while TypeScript can actually type most of that stuff it's a huge mess in something like C#, Golang, Java, etc.

Re: Deno will stop using TypeScript

#235

Post by NicoJuicy »

hombre_fatal wrote: post #220
BiteCode_dev wrote: post #177

Earlier quoted context omitted.

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

JS has a great future: first class ubiquitous promise + async-everything. Can't find that in Ruby/Python/PHP, you have to use something like Twisted/asyncio which limits you to a bolted on subset of the ecosystem, unlike in JS. Very dishonest take btw. Here's a forum of people who could tell you why they use JS instead of your $favelang, yet instead of trying to figure it out, you just assume everyone is lazy or a ju…

No, I'm experienced with node and other programming languages. I never said NodeJS is a bad language, that is not related to the statement i made.

I also didn't say everyone is lazy. I said a lot of developers.

Most people here do not belong to that use-case. As they are mostly here by interest and are willing to learn.

But most people, after work, don't do anything with their knowledge.

And are more willing to learn node as it's the same on the backend + frontend.

Or keep using what they already know, with no interest for other languages.

Re: Deno will stop using TypeScript

#236

Post by jondubois »

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…

>> This feels like process immaturity or unfamiliarity.

On the contrary, I think it shows great maturity in the decision making process. Many highly experienced developers have stayed away from TypeScript for reasons like those mentioned in the article (mostly to do with the build environment, source mapping, versioning complexity, etc...) These are very significant problems and not worth the small benefits which static typing brings.

Re: Deno will stop using TypeScript

#237

Post by kiliancs »

thegreatpeter wrote: post #210
kiliancs wrote: post #158

Earlier quoted context omitted.

Working on half a million LOC TypeScript codebase. All strict flags up, low-2-digit team size. We don't really run into many problems. TypeScript is not perfect, but developer happiness and productivity have definitely increased since we adopted it, and defect rates have dropped significantly --while increasing the size of the team & working on more features.

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

I wasn't comparing to ReasonML, which I'm convinced is a very good choice.

Re: Deno will stop using TypeScript

#238

Post by yawaramin »

NicoJuicy wrote: post #99
pfraze wrote: post #79

Earlier quoted context omitted.

Browser monopoly led lots of devs to learn JS, then NodeJS showed that lots of devs want to keep using JS. It's actually possible for people to like it. Also, languages are always a function of their ecosystems. You could argue, remove Apple products and Swift/ObjC would vanish.

Nodejs showed that a lot of developers are lazy and want 1 language to learn

Not developers; businesses. What do you think a business would prefer: hiring cheap ubiquitous JS devs and using them interchangeably for frontend and backend work, or hiring/training devs separately for backend stacks like Java?

Re: Deno will stop using TypeScript

#239

Post by yawaramin »

goliatone wrote: post #230
echelon wrote: 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…

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

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

I don't understand what that means. How is TypeScript removing friction between JavaScript and tooling? That doesn't make any sense. TypeScript is a typechecker and a language that compiles to JavaScript.

Re: Deno will stop using TypeScript

#240

Post by yawaramin »

orangecat wrote: post #119
geoka9 wrote: post #113

Earlier quoted context omitted.

> With JS, I almost never want to verify only that a value is of a specific type; I want to look at its contents, which means I'd need to write the same test in TypeScript. If such (refactored) method is being called from code that's not covered by tests, the bug may not be discovered until it blows up in production. With static typing it would be caught at compile time.

If such (refactored) method is being called from code that's not covered by tests Well there's your problem :p I agree that if code has no tests, it's more likely to be correct if it's in TypeScript than JS. But I don't consider that an acceptable bar, so if I'm doing your code review I'm going to ask for tests in either case. And once you have tests that verify the behavior of the code, you're not getting much incre…

Unit tests can only prove the presence of bugs; they can never prove the absence of bugs. Only a typechecker can do that (provided an appropriate implementation). E.g. here is an AVL tree that is verified balanced at the type level: https://sketch.sh/s/C7Afz38jtFRMTkkydeBgUA/

No unit tests needed to show that it is balanced :-)

Post reply on HN