Comment by dhruvrajvanshi | Hacker News Reader

Comment by dhruvrajvanshi | Hacker News Reader

Parent Full thread

I wonder about a Typescript with alternate design decisions. The type system is cool and you can do a lot of compile time metaprogramming. However, when there's a type error in computed types, it's a nightmare to visually parse

  type { foo: ... , bar: ..., ... } can't be assigned to type { foo: ..., bar: ... }. type { foo: ... bar: ..., ... } is missing the following properties from { foo: ..., bar: ..., ... }

Apart from repeating roughly the same type 4 times (which is a UX issue that's fixable), debugging computed types requires having a typescript interpreter in your head.

I wonder if we had nominal runtime checked types, it could work better than the current design in terms of DX. Basically, the : Type would always be a runtime checked assertion. Zod certainly fills that gap, but it would be nicer to have it baked in.

The type system would not be as powerful, but when I'm writing Kotlin, I really don't miss the advanced features of Typescript at all. I just define a data class structure and add @Serializable to generate conversions from/to JSON.

TypeScript has a crazy powerful type system because it has to be able to describe any crazy behavior that was implemented in JavaScript. I mean, just take a look at @types/express-serve-static-core [0] or @types/lodash [1] to see the lengths TS will let you go.

If you write in TS to start with, you can use a more sane subset.

[0] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

[1] https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...

Right. I'm aware. My point was that even though the type system is powerful, somehow, I'm able to represent everything I need to in Kotlin's type system just fine and it feels a lot more type safe because it will throw a type error at runtime in the right place if I do a bad cast.

Typescript `as Foo` will not do anything at runtime, and it will just keep on going, then throw a type error somewhere else later (possibly across an async boundary).

You can, in theory use very strong lint rules (disallow `as` operator in favour of Zod, disallow postfix ! operator), but no actual codebase that I've worked on has these checks. Even the ones with the strictest checks enabled have gaps.

Not to mention, there's intentional unsoundness in the type system, so even if you wanted, you couldn't really create a save subset of TS.

Then there's the issue of reading the library types of some generic heavy code. When I "go to definition" in my fastify codebase, I see stuff like this

  RouteHandlerMethod<RawServer, RawRequest, RawReply, RouteGeneric, ContextConfig, SchemaCompiler, TypeProvider, Logger>

Which expands to this

  export type RouteHandlerMethod<
  RawServer extends RawServerBase = RawServerDefault,
  RawRequest extends RawRequestDefaultExpression<RawServer> = RawRequestDefaultExpression<RawServer>,
  RawReply extends RawReplyDefaultExpression<RawServer> = RawReplyDefaultExpression<RawServer>,
  RouteGeneric extends RouteGenericInterface = RouteGenericInterface,
  ContextConfig = ContextConfigDefault,
  SchemaCompiler extends FastifySchema = FastifySchema,
  TypeProvider extends FastifyTypeProvider = FastifyTypeProviderDefault,
  Logger extends FastifyBaseLogger = FastifyBaseLogger

> = ( this: FastifyInstance<RawServer, RawRequest, RawReply, Logger, TypeProvider>, request: FastifyRequest<RouteGeneric, RawServer, RawRequest, SchemaCompiler, TypeProvider, ContextConfig, Logger>, reply: FastifyReply<RouteGeneric, RawServer, RawRequest, RawReply, ContextConfig, SchemaCompiler, TypeProvider> // This return type used to be a generic type argument. Due to TypeScript's inference of return types, this rendered returns unchecked. ) => ResolveFastifyReplyReturnType<TypeProvider, SchemaCompiler, RouteGeneric>

Other languages somehow don't need types this complicated and they're still safer at runtime :shrug:

> You can, in theory use very strong lint rules (disallow `as` operator in favour of Zod, disallow postfix ! operator), but no actual codebase that I've worked on has these checks. Even the ones with the strictest checks enabled have gaps.

That's surprising. I've worked on a few codebases with reasonably mature TS usage and they've all disallowed as/!/any without an explicit comment to disable the rule and explain why the use is required there.

I don't write Kotlin, but what that does (assuming I'm guessing at it correctly) requires far more awkward code in most other languages. That looks like it will allow you to extend the types of objects deep inside the library so that you could e.g. create your own Request object without having to type cast inside the HTTP handlers or wrap the entire library.

That shifts the complexity of doing that out of the runtime and into the Typescript preprocessor where it's not going to mess with your production instances.

I also don't think it's all that bad; it's a lot of generic types, but it doesn't appear to be doing anything particularly complicated.

I do think they get awful, though. This is something I've been hacking on that I'm probably going to rewrite https://pastebin.com/VszX3MyE It's a wrapper around Electron's IPC and derives a type for the client from the type for the server (has to have the same methods and does some type finagling to strip out the server-specific types). It also dynamically generates a client based on the server prototype. The whole thing rapidly fell into the "neat but too complicated to be practical" hole.

> I don't write Kotlin, but what that does (assuming I'm guessing at it correctly) requires far more awkward code in most other languages

You're NOT assuming correctly. In Kotlin, this would be handled as an extension property on the Request type. You could write it just like normal code instead of extending some global ambient interfaces.

  val Request.foo: Bar = whatever
  get("/") { req.foo // just a method call }

You can CMD+Click on it and read the actual implementation (instead of generated type definitions).

The Typescript ecosystem needs these complicated types because of some design choices (no type based dispatch). I suggest looking up how other languages solve these problems. You'll find that in typescript, you have to reach for complex types far sooner than in other languages.

So if I pass that Request option to another function that expects a Request object, the compiler is going to track that I’m using an extended object instead of the actual Request type in the function signature and allow me to access the “foo” property?

That’s what I’m specifically talking about. Yours is just dependency injecting a type, which is more avoiding the existing types in the library. That would be the “wrapping” option I was talking about. You don’t need to extend the types if you’re just going to dependency inject them. You could just have an entirely separate object that you pass around at that point.

If the other method has visibility of my foo property, then it can call it. Nothing is being "injected" anywhere. It's the moral equivalent of foo(req). It's statically dispatched

That is exactly dependency injection, the functions have to be embedded into a scope that has access to additional values because the framework doesn’t support passing them directly. The types are injected into the function by being embedded into another scope.

It’s not some kind of moral sin, but it is a kludge. The type system is now tied to the structure of your code, because scoping is now intrinsic to your types.

It’s not the end of the world, I’ve worked in similar systems, it just tends to have a heavy mental overhead at some point as you now have to keep scoping in mind as part of your types.

The complexity of the types you see in traditional nodejs web servers is there because all of them tried to work as a god-function multitool. The type of a router handler literally incorporates the types of all constituents of a generic request-reponse process and additional server-specific data, all packed into (req, res). This only happens in ultra-generic code that is basically web servers only.

Iow, don't go to the definition of a web request handler. Go here: https://fastify.dev/docs/latest/Reference/TypeScript/

Other languages (libraries really) separate these parts, e.g. Spring Boot seems to hide routing away into a method decorator which infers the body type from a target signature and the server is somehow implied(? through a controller?..). Anyway, it's all there, just not in one place. It has nothing to do with Typescript, it's a js library legacy issue.

My company’s codebase disallows type coercion. You can disable the lint rule if there’s a legit reason to but then we ask to explain why.

It's apples and oranges. The type system in Kotlin is integrated into the language. TypeScript is a preprocessor for JavaScript that isn't allowed to change the JavaScript language, or have any runtime.

The "as Foo" construct is for you to tell TS that you know better than it, or that you deliberately want to bypass the type system. You can have a runtime check, but you have to write the code yourself (a type predicate), because TS doesn't write or change any JavaScript*, it just type-checks it.

I've certainly worked in new codebases where a relatively simple subset of TS types were used. Even then there were a few places the crazy type system was helpful to have. For example, we enforced that the names of the properties in the global configuration object weren't allowed to have consecutive uppercase letters!

(* with minor exceptions like transpiling for new JS features)

This is my exact experience. TypeScript seemed to hit a complexity sweet spot about 5 years ago, then they just kept adding more obscure stuff to the type system. I find that understanding TypeScript compiler errors can be almost as difficult as understanding C++ template errors at times.

Hint, 9 times out of 10 you only need to read the last part of the error.

Also, there are many ways to make types opaque (not show their entire verbose structure).

Which begs the question of why they don't rearrange that part to the first in the error message. Like you said, 9/10 times I scroll down without thinking which is silly.

I have no clue, but I guess there were (and are), good discussions around it.

This. Haxe is a more sane TS alternative in 2024.

Haxe is amazing, has macros etc. A force multiplier if you are a solo developer for sure. But damn, you feel kinda alone if you are using it. Not everything is an npm install away which negates your velocity gains from using a saner language.

I RARELY/NEVER have to build an app so fast that i just fart out whatever broken code as fast as my fingers can type. IF i get a project like this with a deadline of "yesterday" i politely just refuse. I will be wasting my personal time, and the clients time. And the result will be a broken mess that will eventually take more time to fix, than it would have if i in fact did it "correct" from the get go.

That said Haxe has externs, enabling you to target JS/PHP and use the rich ecosystem both langauges have. The best part of externs is that IF i only use 4 things from given package, i statically KNOW i only use these 4 things, and can refactor more easily, or even build the thing i need myself.

When I'm talking about velocity, I'm not talking about coding fast, but being able to write DRY, flexible yet easily maintainable code that can weather future requirements / refactorings easily. Personally, I'm also talking in the context of my own projects so nobody is breathing down my neck or pressuring me with time. I just want to write good code that is a joy to maintain for years to come.

Ironically Haxe was inspired by ActionScript 3 which was the basis for the EcmaScript 4 proposal which was abandoned back in 2008 or so.

It's Haxe still been actively developed? I loved it back in the day. The blog hasn't had an update in years.

It is. And only getting better SLOWLY by each iteration. The thing i love about Haxe that once you use it, your installed version is not legacy in a month (unlike npm/typescipt ecosystem). Haxe is fully working, and does not need a lot of "new" features.

More news about Haxe can be found here: https://haxe.io/ (the old blog is not updated AFAIK)

Couldn't this be improved by showing a diff between the mismatched types?

Yes, I did mention that the UX of the type errors could be improved and probably should, but once you start getting into conditional types, and nested types (which may not be fully expanded when you see the error), it gets hairy.

Can you do any compile time metaprogramming in typescript?

Not really - https://github.com/Microsoft/TypeScript/issues/16607.

ts-morph provides an easy way to use the TypeScript Compiler API to view and edit the AST before compile. Once you get your head around the API, which has good examples but isn't thoroughly documented on the web.

https://github.com/dsherret/ts-morph

Nope. For thins you pick Haxe (https://haxe.org/), it has an awesome macro system, and a state of the art compiler thats really, really fast.

How does haxe modify a typescript project pre or post compile?

Reply on news.ycombinator.com