Live data from Hacker News

Deno will stop using TypeScript

startfunction.com

281–290 of 359 posts

Re: Deno will stop using TypeScript

#281

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.

It's not about most errors being due to type mismatch, as much as it is about being able to model your domain.

By having types, you open the door to formally describing the building blocks of your system. This lets you create very specific, well understood, pure pieces that then are composed together to bring about your desired functionality.

Why rely on documentation that a compiler cannot statically verify, as opposed to a type (annotation or otherwise) that can?

I think you're correct regarding your "most errors are caused by" comment, and no programming paradigm will ever get rid of these - you can always find a way to write bad code. And you are also correct that there are type zealots out there who create beautiful prisons they call abstractions. But at the end of the day, types are a tool, and while I'd highly recommend learning them, I also recognize some projects and teams will never make use of them.

Re: Deno will stop using TypeScript

#283

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 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 hours to do in Scala.

Re: Deno will stop using TypeScript

#284
post #156

Earlier quoted context omitted.

> 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. How many times has six-months-hence you cursed you for this attitude? Be honest.

Never. This is why we write small functions that, as much as possible, depend only on their inputs and avoid mutation. Code becomes simple to reason about. You don't need to worry when composing these small pieces like you do when passing mutable objects, using out variables, etc.

An experienced developer I know with a dead simple function fell for the classic 10+20+30=102030 bug the other day. Had it not been noticed in production it would have been very costly. It was an edge case he had not encountered in the wild, but had thought to handle just-in-case. Integration tests missed it too. Sure, good unit tests could have caught it, but Typescript would not have allowed it in the first place.

Re: Deno will stop using TypeScript

#285

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…

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 because my code was correct. Lo and behold, the assertion tripped in my test suite - apparently I was sometimes treating a string as an object and didn’t notice. Which was a serious issue; and could end up being a security problem for some people. My fuzzer didn’t find it because it never occurred to me to add string method names in my random data generator.

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. You can eventually find all bugs with a sufficiently large test suite; and with enough PhDs you can apparently formally prove everything. But you get the best bang for buck with a little of each. A few tests is much better than no tests. But in the same spirit, I find no matter how big my test suite, there’s a good chance static types will improve my code.

Typescript is far from perfect, but I sleep better at night with a type checker checking my code.

Re: Deno will stop using TypeScript

#286

Earlier quoted context omitted.

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

I’d say that TypeScript removes friction in the sense that you can use autocomplete fairly easily with it, out of the box. Using autocomplete without type annotations is pretty hard.

Also, things like automated/safe refactoring, jump to definition, find all usages, etc.

Re: Deno will stop using TypeScript

#287

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…

"That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. If you want to make an assertion, back it up. I will make my argument for why types are a good thing below:

I don't agree with you. I don't think that loose typing is based on opinion, and I do not think it is because people who start out in statically typed languages are unable to "grasp" loose typing. 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 lines, projects.

Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages.

An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL.

In an untyped environment, only by understanding ALL upstream code are we able to make assumptions about downstream code. We know that the "string URL" is a sequence of characters, and nothing more.

However, if we have a type, we can have a "URL" type. Since we have a type, we do not need to concern ourselves with all upstream code, only the code associated with the "URL" type. So, instead of potentially thousands of places to seek information about our "URL" variable, we have only one: The "URL" type. We look at the implementation of that type, and we know weather or not the URL has been validated.

Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application. This makes your application more secure, more readable, and easier to maintain.

Re: Deno will stop using TypeScript

#288

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 entire comment did not mention testing so it sounds like you never have to continue working on a codebase and eventually face the challenges of refactoring something that you didn't write or remember writing. How about self-documnted code how often do you work with others?

Re: Deno will stop using TypeScript

#289

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…

How about a map of options where some of them are mutually exclusive? Without union types you have to write test for that.

Re: Deno will stop using TypeScript

#290

Is there a reason we can ONLY use JavaScript in the browser? The world would immediately become better if we added a different language compiler on in instead.

The reason is language compatibility. But since graalvm solve that, browsers should include graalvm. Sadly this is not going to happen anytime soon, webassembly has too much lobbying
Post reply on HN