One of the most exciting features of Zig, but am I correct that this doesn’t apply to types themselves like comptime generics in Zig? I find that to be one of the most powerful ideas: type level mappings that have the same syntax as the runtime code where you can just set an iteration limit. This would be a great way to get around the “too large union” problem in TS, for example.
Author here. We have an idea in the works to implement `typeInfo`, but it serves a more type -> value usecase (for example, generating validations from types).
However, going full cycle (type -> value -> type) is not as trivial because we won't get to ride on TypeScript's existing language server support, and solutions such as needing to use our own patched tsserver, etc., are too hacky for my liking.
Also not possible is generic types as parameters to comptime functions like Zig.
Happy to discuss more comptime usecases though. Feel free to raise an issue if you'd like to discuss, we can look into feasibility.
It's not unusable per-se, however being unable to take advantage of Rust's fearless concurrency and having to glue everything together with JavaScript severely restrict the usefulness.
May as well just use TypeScript and React at that point.
The dream is to be able to specify only a wasm file in an html script tag, have the tab consume under 1mb of memory and maximise the use of client hardware to produce a flawless user experience across all types of hardware.
import {sum} from './sum.js' with {type: 'comptime'};
is an unfortunate abuse of the `type` import attribute. `type` is the one spec-defined attribute and it's supposed to correspond to the mime-type of the imported module, thus the two web platform supported types are "json" and "css". The mime-type of the imported file in this case is still `application/javascript`, so if this module had a type it would be "js".
It would have been better to choose a different import attribute altogether.
I have had many discussions with the author and we ultimately decided not to support those kinds of usecases until we have a very solid set of guarantees. Supporting closures can quickly become very tricky when you need to preserve a function across JS processes.
I have read the examples, and it seems like this cannot be used for aggressive hoisting of conditionals by writing "if (comptime foo)", resulting in the the body of the if statement being executed unconditionally or omitted. So it cannot replace my current use of C preprocessor macros in Javascript, though Zig's actual comptime feature could.
16 comments
[ 2.9 ms ] story [ 42.9 ms ] threadHowever, going full cycle (type -> value -> type) is not as trivial because we won't get to ride on TypeScript's existing language server support, and solutions such as needing to use our own patched tsserver, etc., are too hacky for my liking.
Also not possible is generic types as parameters to comptime functions like Zig.
Happy to discuss more comptime usecases though. Feel free to raise an issue if you'd like to discuss, we can look into feasibility.
``` const MyComponent = () => jsx!(<div></div>) ```
rather than a .tsx file.
That or wasm to be usable so I can just write my web apps in Rust
https://github.com/lite-jsx/core
May as well just use TypeScript and React at that point.
The dream is to be able to specify only a wasm file in an html script tag, have the tab consume under 1mb of memory and maximise the use of client hardware to produce a flawless user experience across all types of hardware.
It would have been better to choose a different import attribute altogether.