Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript’s quirks: How inconsistencies make the language more complex

blog.asana.com

Post reply on HN
Print view View original

181–190 of 216 posts

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#181

Post by platz »

marcosdumay wrote: post #165
hopia wrote: post #157

Earlier quoted context omitted.

Aeson parsing seems straightforward to me, not sure it could be easier in any language. Serialization from your endpoint is automatic, based on your data types. The real benefit of using a well typed language here is that you only need to parse the data once at this point, after that the type system makes sure the data is of correct format everywhere else in your codebase.

Aeson is not straightforward at all. Just try doing what the GP is saying he wants to do, you will discover you can't. It is a very good library if you control both sides of the communication, and have fit for purpose interfaces. Otherwise, you are better with any lower level library. Besides, what is it with the strictness of Haskell JSON libraries? There's nothing that will even accept Window's BOM.

You don't have to define a type for Json data in Haskell if you don't want to. Defining a full type is only norm/preference.

With Aeson, You always have the option work with a map directly and pull out properties by name.

That is also especially useful when you can't predict what keys or shape the data will have

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#182

Post by the_gipsy »

cryptica wrote: post #146
DonHopkins wrote: post #139

Earlier quoted context omitted.

Do your JavaScript tests inform your IDE how to do code highlighting and completion and refactoring?

My JavaScript integration and unit tests do something better; they tell me exactly what features I broke as a result of my refactoring and let me fix things in the best way possible without regard for the previous structure of the code (which may no longer be relevant anyway; there is usually a good reason why we do refactorings in the first place! It's rarely just about renaming things). I have many stories on the s…

I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums.

In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful.

On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#183

Post by chmod775 »

IggleSniggle wrote: post #176
chmod775 wrote: post #161

Earlier quoted context omitted.

I'm assuming you don't understand why you shouldn't use discriminated unions for server-side validation? Client (JSON) messages will pretty much always start out as any, and you can't assume they fit your union any way shape or form. Taking the Cat|Dog example from the article, a client may pass {"kind":"cat", "bark": "woof"} and if you just go blindly from there to the union and then try to narrow that down, you've…

But wouldn't what you're talking about just be a union type? We might be saying the same thing. The "discriminated" part of discriminated union means that you will be performing the runtime validation to check which of Cat or Dog it is, and only once it receives those validations do you have a derived type. By asserting that the object received is Dog only if it has kind:dog bark:string, you've narrowed your type at…

> But wouldn't what you're talking about just be a union type?

Not really, unless you define any as union of every possible type. Also TypeScript won't realize you have narrowed the type (because it doesn't use such a definition) with all your checking unless you cheat with type guards (which are really just a prettier cast with optional user-created validation).

Then there's also the fact that thanks to getters your narrowing from any may be incorrect, which is probably why you can only narrow to basic types or with an instanceof operator, neither of which will help you with your JSON input.

tl;dr: Discriminated unions won't help you when you're starting out from any, because any is not an union.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#184

Post by yawaramin »

sjy wrote: post #138
yawaramin wrote: post #73

Earlier quoted context omitted.

Out of curiousity, what exactly was the difficulty with decoding JSON in Haskell/

I was trying to use Aeson, which as noted in this excellent tutorial [1] (which didn’t exist when I first tried it) is “hopelessly magical for people who try to learn it by looking at provided examples, and existing tutorials don’t help that much.“ The rest of the tutorial should give you some idea of why I say that parsing JSON in Haskell is complex, at least if you’re used to doing it in JavaScript. [1]: https://ar…

I'm interested in specifically what issues you had with JSON.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#185

Post by loxs »

yawaramin wrote: post #178
loxs wrote: post #89

Earlier quoted context omitted.

The thing is... it doesn't seem to matter. After 30-40k lines of TS code (coming from OCaml) I am still to find a bug where OCaml would have done a better job, except for missing features like nominally typed primitives and no pattern matching. And these are hopefully coming to TS/JS

I recommend looking at your frontend console logs for instances of type errors a la https://rollbar.com/blog/top-10-javascript-errors/

My console is fine, definitely do not experience these errors :)

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#186

Post by thosakwe »

davedx wrote: post #117

This article makes me think about the "rust compile times are terrible" blog post from the other day. If you spend a lot of time with a technology, day in and day out, you get intimately familiar with all of its shortcomings, and sometimes you maybe lose some perspective. Having used Rust (enough to see its innovations and promise) and TypeScript (daily), I think they are incredible languages and platforms. Sure, the…

Nothing wrong with highlighting areas for improvement, though.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#187

Post by ravenstine »

lexicality wrote: post #158
kjtekn wrote: post #140

I like how nobody has realized that typescript is classic Microsoft embrace, extend, extinguish. Oh no, they have "turned a corner". This is a different Microsoft! Haha.. they are exactly the same. Every single company has wanted to try and control JavaScript as it takes over more and more of the roles other languages used to fill. Google failed with their new language, Microsoft is having some success. Google claime…

The only electron app I've ever used that wasn't slow/terrible is VSCode which happens to be written in typescript by Microsoft and it still occasionally decides to use 100% of my macbook's CPU making it entirely unusable until I restart, so I'm not sure that's a very good argument.

Do you think that's actually thanks to TypeScript? From what I know, TypeScript doesn't have an inherent performance quality that makes it better than JavaScript.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#188

Post by IggleSniggle »

chmod775 wrote: post #183
IggleSniggle wrote: post #176

Earlier quoted context omitted.

But wouldn't what you're talking about just be a union type? We might be saying the same thing. The "discriminated" part of discriminated union means that you will be performing the runtime validation to check which of Cat or Dog it is, and only once it receives those validations do you have a derived type. By asserting that the object received is Dog only if it has kind:dog bark:string, you've narrowed your type at…

> But wouldn't what you're talking about just be a union type? Not really, unless you define any as union of every possible type. Also TypeScript won't realize you have narrowed the type (because it doesn't use such a definition) with all your checking unless you cheat with type guards (which are really just a prettier cast with optional user-created validation). Then there's also the fact that thanks to getters your…

True, discriminated unions don't flow from any, but they can be useful for composing types from any.

I suppose I'm saying that the validation function itself is the precursor to discriminated unions being useful. run through a type predicate function or an assertion type function (https://www.typescriptlang.org/docs/handbook/release-notes/t...) produces a typed object that conforms to your requirements for the type.

I definitely do wish there were some way to create these assertions/validators from the types automatically, but I think that might be impossible.

Apologies for any formatting issues, on mobile:

``` foo:any; isAnimal(foo); if(isDog(foo)){ // Dog } else { // Cat } }

function isAnimal(thing: any): asserts thing is Animal { if (thing.kind !== "dog" && thing.kind !== "cat && etc){ throw new AssertionError("Not an animal!"); } ```

// ...etc, except that string literals probably exist in an Array or similar, ie types that can be progressively derived / enhanced from the runtime code.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#189

Post by TomMarius »

kjtekn wrote: post #150
nicoburns wrote: post #127

Earlier quoted context omitted.

Type systems can be thought of as low-cost (in terms of dev time) declarative tests. Which should leave you with less to test in your actual tests. They also give much quicker feedback than tests.

No longer enjoying programming is a cost nobody can afford to pay. When I read the long list of c#, I mean typescript documentation, it gives me PTSD from c# and java, which people used to hate here, but now suddenly like and let me tell you it has nothing to do with microsoft social engineering.

I also used to think TS is like C#. Huge mistake. Try to approach it from a functional angle. The TS compiler code does not use the class keyword.

Re: TypeScript’s quirks: How inconsistencies make the language more complex

#190

Post by okbake »

jahewson wrote: post #63
mekster wrote: post #17

Earlier quoted context omitted.

Casting is as bad as using "any". You can make the compiler think anything you throw at it as that type and you can get bitten at runtime.

Nope. This is not how casting works in TypeScript. To get an unsafe cast you have to go via the ‘any’ or ‘unknown’ types. e.g. ‘foo as unknown as Dog’

There are a few casts that are allowed that I would consider unsafe, particularly around unions of literals or using empty object literals:

  // No error here
  type Animal = 'dog' | 'cat';
  const notAnimal = 'couch' as Animal;

  // No error here either
  type Food = { isSpicy: boolean };
  const empty = {} as Food;
https://www.typescriptlang.org/play/index.html#code/C4TwDgpg...
Post reply on HN