typescript-runtime-type-benchmarks
tl
typescript-runtime-type-benchmarks | tl | |
---|---|---|
33 | 54 | |
560 | 1,944 | |
- | 1.9% | |
9.7 | 7.7 | |
4 days ago | 3 months ago | |
TypeScript | Lua | |
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
typescript-runtime-type-benchmarks
-
TypeScript please give us types
Has been heavily optimized, both in terms of its types and runtime performance. Even including the static parser, many types are about an order of magnitude more efficient than equivalent Zod. Early results show it as marginally faster than any validator currently published to typescript-runtime-type-benchmarks, not including more complex cases where (2) would give ArkType a much more significant advantage.
-
What are some of the best libraries you cannot work without?
Zod is a bit of an underdog but it is not fast, AJV which is slightly more common can validate and generate types too but requires using JSON syntax, TypeBox offers familiar syntax to Zod while still being JSON syntax in the background.
-
[AskTS] What do you think will be the future of runtime type checking?
First, they're not fast (runtime type checking benchmarks).
-
Typescript really hits the middle ground between extremely rigid statically typed languages on one extreme and no types at all dynamic languages on another extreme. Best type system
Aha, so you're using a library in Java for this. You know about libraries in TS for this, there are plenty of them btw, but you don't use them because it's so easy. Express has `any` type for `req.body` because authors don't care about this either and it's so easy. And TypeScript is the one to blame in that you prefer to work with `any` type for incoming data rather than validating it.
-
TypeBox: Runtime Type System Built on Industry Standards
It is so much faster than Zod that Zod basically doesn't show, https://moltar.github.io/typescript-runtime-type-benchmarks/ and according to bundlejs, https://bundlejs.com/?q=zod%2Czod%2C%40sinclair%2Ftypebox&treeshake=%5B*%5D%2C%5B%7B+default+%7D%5D%2C%5B*%5D&config=%7B%22analysis%22%3Atrue%7D, it is even smaller. I genuinely have no clue why Zod is this popular in 2023.
- Whatโs your favourite validation library?
-
TypeBox: Template Literals + Conditional Types at Runtime
TypeBox is a bit different to other libraries in this space where it's mostly intended to be used with a auxiliary JSON Schema validator. Although it provides a built in JSON Schema compiler (which is currently the fastest (not-AOT) runtime validator available for JavaScript today), it's equally intended to be used with validators like Ajv (or any other standards compliant validator)
-
Introducing ArkType: The first isomorphic type system for TS/JS
I do plan to add some direct comparisons to https://github.com/moltar/typescript-runtime-type-benchmarks as well but haven't had a chance yet.
-
Is using zod as the primary source of truth for Typescript types sensible/sustainable?
I think it's more of a case of the extremely low performance bar that's been set by the status quo (for even the simplest of validation structures). There's been a lot of focus on the TS type inference, and less on the runtime performance (which actually matters more as it does reduce operational costs). It probably wouldn't be such an issue if the performance was reasonable, but I mean here's the full breakdown https://moltar.github.io/typescript-runtime-type-benchmarks/.
-
Best schema validator for intellisense performance?
I found a benchmark for runtime performance, but I haven't found any for intellisense/editor performance.
tl
-
Ravi is a dialect of Lua, with JIT and AOT compilers
it's based off MIR, does it have something to do with https://mlir.llvm.org/ ?
for typed lua, there is another effort https://github.com/teal-language/tl in addition to the mentioned typescript approach: https://github.com/andremm/typedlua
-
Lua Criticism Is Unwarranted
I had the pleasure of working with Lua 5.1 back in the late noughties. For me it's replaced Tcl whenever I want something I can configure above a C library. At the time I used it I found it quite nice but I'll also not forget the hours I wasted tracking down nil table corruptions which could have easily been caught by a type checker.
I had some hope that Luau https://luau-lang.org or Teal https://github.com/teal-language/tl would make things better but with the following example
function foo(x: number): string
- Why Fennel?
-
Algebraic data types in Lua (Almost) post
I wonder why the author doesn't use Teal [0] - a typed dialect of lua.
[O] https://github.com/teal-language/tl
-
Lua: The Little Language That Could
Check out Teal
-
What's the deal with Fennel in Neovim?
There is already https://github.com/teal-language/tl, which is typed Lua. I think fennel exists to serve a different niche-- personally I use it not for any type features; I just like the syntax better, and others may find certain features like the macro system useful.
- Using Lua with C++
- Teal โ Type Hints for Lua
-
Using other languages
There's also some languages made to compile straight to Lua: - MoonScript is the most popular Lua wrapper - it's built to be more Python-like, featuring indentation-based scopes, function calls without parentheses, lambda syntax, list comprehension, and much more. - Yuescript is a modern update to MoonScript that adds more features (I haven't used it myself, so I'm not entirely sure exactly how it differs from MS). - Teal is a version of Lua that adds static typing for better code standards.
-
Bog โ small, strongly typed, embeddable language
Terra and Nelua are both very different in goals than Teal. Teal is literally gradual types integrated into Lua keeping as many of Lua's idioms as possible (to a fault[1]). Terra and Nelua are both very metaprogrammable systems programming languages. Nelua's goals are primarily to soften C's rough edges, comparable to something like Nim.
There's another one you missed in Pallene[2]. But again, it's goal was to optimize the stack sharing involved in using the C API. It also adds types though and maintains Lua idioms as much as possible.
[1]: https://github.com/teal-language/tl/discussions/339
[2]: https://github.com/pallene-lang/pallene
What are some alternatives?
napi-rs - A framework for building compiled Node.js add-ons in Rust via Node-API
luau - A fast, small, safe, gradually typed embeddable scripting language derived from Lua
zod - TypeScript-first schema validation with static type inference
OpenBBTerminal - Investment Research for Everyone, Everywhere.
MikroORM - TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. Supports MongoDB, MySQL, MariaDB, MS SQL Server, PostgreSQL and SQLite/libSQL databases.
packer.nvim - A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
.NET Runtime - .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
rpi-open-firmware - Open source VPU side bootloader for Raspberry Pi.
Wren - The Wren Programming Language. Wren is a small, fast, class-based concurrent scripting language.
luaforwindows - Lua for Windows is a 'batteries included environment' for the Lua scripting language on Windows. NOTICE: Looking for maintainer.
Prisma - Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB
pallene - Pallene Compiler