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

TypeScript please give us reflection/runtime types

github.com

Post reply on HN
Print view View original

91–100 of 287 posts

Re: TypeScript please give us reflection/runtime types

#91

Post by jxf »

paxys wrote: post #43

I had to read their problem statement like 4 times to understand what they are asking for. This is exactly why simple, concise writing is essential, and their wall of text is...not it. > I love you. You do amazing work. You are gods among mortals. You have brought JavaScript from the darkness, and given it the warm light of strong typing. Look upon us, the cowering meek masses, and understand that we live in the muck…

> This is exactly why simple, concise writing is essential, and their wall of text is...not it.

I only skimmed this but felt it was clear. They're asking for TypeScript, as part of the type erasure, to emit the type information it has discovered about the types in a side channel to the emitted JavaScript. Think of, say, PDB files as an analogy.

> They are really asking for a net new product which has very little to do with the TypeScript that exists today.

This is information TypeScript already has today but which it discards. It wouldn't take a "net new product".

Re: TypeScript please give us reflection/runtime types

#92

Post by wvenable »

paxys wrote: post #84
cornstalks wrote: post #73

Earlier quoted context omitted.

> > TypeScript Needs to Emit Runtime Type Information > This is not possible at all because TypeScript is a compiler. Sorry, can you clarify? Many compilers exist in other languages that support RTTI, so it's not clear to me what you mean by this.

There are plenty of projects that do the same for TypeScript (e.g. https://github.com/typescript-rtti/typescript-rtti ) and plenty that support some kind of runtime reflection, and overall emitting TS type information at compile time in some readable format is a pretty trivial problem to solve. The complicated part is on the other side – what do you do with this information? How do you get JavaScript engines to under…

You don't get JavaScript engines to understand it. You use a library.

Re: TypeScript please give us reflection/runtime types

#93

Post by andix »

vbezhenar wrote: post #79
lolinder wrote: post #41

Earlier quoted context omitted.

Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate: > 3. Impose no runtime overhead on emitted programs. > 9. Use a consistent, fully erasable, structural type system. It's also explicitly called out as a non-goal in that doc: > 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, en…

If some design goals are stupid they must be changed. It's not god word. It's human word. And this human was wrong.

In my opinion they are not stupid, they make a lot of sense. And many people seem to agree and use typescript. If you don’t agree, use something else. There are many alternatives, pick something that is „smart“ in your opinion.

Re: TypeScript please give us reflection/runtime types

#94

Post by BiteCode_dev »

While type hints in Python are not as nice as typescript annotations, I understand their plea, because once thing Python does better is runtime introspection.

Which means we can have dataclass, pydantic, typer and fastapi all generating their stuff from regular type hints. No need for special syntax or functions. And that's super nice.

Re: TypeScript please give us reflection/runtime types

#95

Post by orthecreedence »

Reflection on a language that compiles to javascript? I don't get it. Why are people so allergic to macros?? Every stinking language that has compiled to JS has had a chance to do macros but they don't. Coming from many years spent in the lisp world, metaprogramming is this incredible feature that, in my experience, completely negates the need for runtime reflection while adding many other possibilities as well. I get it...the syntax is way harder when your language isn't basically a pre-parsed AST. But rust does it.

Seems like a huge waste.

Re: TypeScript please give us reflection/runtime types

#96

Post by wvenable »

ragnese wrote: post #65
orangepanda wrote: post #14

I vaguely remember one of typescripts developers stating that if they had to start it all over again, enums would not be added; as enums are the only thing emitting runtime code. Typescript does not change runtime behaviour, there is no special typescript {#if}

> I vaguely remember one of typescripts developers stating that if they had to start it all over again, enums would not be added; as enums are the only thing emitting runtime code. It's true. I don't remember if that was the only/main reason they said that, but that was definitely one of the things. I find that a weird sentiment, though, because TypeScript has a couple of other features that are not just "JavaScript…

Although namespaces are not deprecated they are not recommended anymore -- much for the same reasons.

Re: TypeScript please give us reflection/runtime types

#97

Post by lolinder »

wvenable wrote: post #68
lolinder wrote: post #41

Earlier quoted context omitted.

Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate: > 3. Impose no runtime overhead on emitted programs. > 9. Use a consistent, fully erasable, structural type system. It's also explicitly called out as a non-goal in that doc: > 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, en…

Emitting type information to some kind of separate common format wouldn't undermine most of these goals. There are already apparently dozens of tools that people can use for this task in a dozen different ways. Just have TS emit the data. In this way there is no runtime overhead (point #3) -- it's pure data to be optionally consumed. They wouldn't have to prescribe any particular reflection module (point #6). The onl…

It would violate #9 no matter what implementation you use, and #9 is absolutely essential to tools like ESBuild, Deno, and Bun, which all rely on the assumption that they can nearly instantly strip out the type annotations and execute the code as JS.

Re: TypeScript please give us reflection/runtime types

#98

Post by mrkeen »

can16358p wrote: post #47

This shouldn't happen... unless someone finds a way to do this without a runtime overhead, which naturally seems impossible. If this is done, TS will become something entirely different as it currently doesn't have a runtime: it's a huge-and-smart linter. But that's all about it. No matter how huge, it's a linter. Reflection would imply something beyond that. Even though I absolutely love reflection, I believe it sho…

No runtime necessary, if I understand the problem.

Input is bytes. Bytes will never carry their type information (and if they did, you couldn't trust them). So the type information needs to be used in the Deserialiser, not its input.

To get typed deserialisation of Foo, the compiler needs to generate a FooDeserialiser automatically for you. The compiler can't depend directly on Foo (Foo is written after the compiler), but if Foo could somehow emit its type information during compilation, then the compiler could depend on that.

Re: TypeScript please give us reflection/runtime types

#99

Post by anonzzzies »

seanmcdirmid wrote: post #69
anonzzzies wrote: post #49

Thanks for this. I thought I was screaming into a void. I started with typescript in 2018 and after two years started to believe this is just not really a solution because what it is. I came from Haskell/c#/f#, and TS, while it has a very powerful type system, just doesn’t give you much of the advantages the above languages give you outside (some of) dev. Even when it does, it is really limited in practice (aka when…

The point of TypeScript was always to run on web, it wasn't meant to give you a language advantage over say, C#. You use C# if you have to develop for .NET, you use TypeScript if you have to develop for Web, you wouldn't use one or the other in another context. That being said, TypeScript is differently capable from C#. C# is nominally typed, with decent reified generics. I like programming in C#, and miss its featur…

But that’s when you focus on the type system theory and I agree with that. I don’t see how enforcing types after compilation has anything to do with a programming language for the web vs ‘not for the web’ though, but I understand it is the philosophy to check the types and then drop to plain JS. Best tool for the job, sure, but literally losing everything typed you wrote and designed after compilation is just not as useful as it could (should imho) be. You express whatever, it compiles, and then everything can break all that you carefully set up, without any errors.

That’s not the language or type system per se, it’s the compiler implementation or rather the philosophy to stay close to js and have a very thin (powerful) layer at compile time only. Typescript in wasm, Deno maybe (didn’t try yet) etc could change this. Then we can have types as in other languages. Not sure why this would not be a win for everyone vs the current status.

Also, as you know, the run the web went out the door with nodejs; many backends are now typescript and indeed competing (… for at least writing web apps) with c#.

Re: TypeScript please give us reflection/runtime types

#100

Post by RyanCavanaugh »

wvenable wrote: post #68
lolinder wrote: post #41

Earlier quoted context omitted.

Emitting types would run counter to several of TypeScript's Design Goals [0]. In particular, it would violate: > 3. Impose no runtime overhead on emitted programs. > 9. Use a consistent, fully erasable, structural type system. It's also explicitly called out as a non-goal in that doc: > 5. Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, en…

Emitting type information to some kind of separate common format wouldn't undermine most of these goals. There are already apparently dozens of tools that people can use for this task in a dozen different ways. Just have TS emit the data. In this way there is no runtime overhead (point #3) -- it's pure data to be optionally consumed. They wouldn't have to prescribe any particular reflection module (point #6). The onl…

TypeScript dev lead here.

Today, you can already write a program using the TypeScript API to inspect all of this information to accomplish whichever scenario is at hand. The existence of all these tools, each with different opinions on design direction and implementation trade-offs, demonstrate that this is possible. Yet it's not demonstrated how those tools would benefit from reading from a data file as opposed to using the TypeScript API.

Something like api-extractor has different constraints from io-ts which has different constraints from typescript-schema. The API exists today and is apparently sufficient to meet all these tools' needs, yet what's proposed is a data file that can encapsulate any possible operation you might perform with that API.

Having TypeScript try to imagine, implement, and maintain a data file format that can satisfy _all_ of these tools' use cases, plus any future tool's use case, is a tremendous effort with no clear upside over using the existing API.

It's easy to gain support for the idea of "put the types in a file" because anyone reading that can imagine a straightforward implementation that just achieves their particular goals, but everyone's goals are different and the amount of overlap is not actually all that high when you look at the wide breadth of tools in the list. There's a very different amount of information you'd need to enable a type-aware linter (which is basically type info on every expression in the program!), as compared to a simple documentation generator (which might only need top-level declaration info).

Post reply on HN