Open richarddavison opened 3 weeks ago
If reasonable, please consider to add a note on the expected AWS-managed LLRT runtime for Lambda service. It should slightly improve cold starts due to the runtime caching, making LLRT even more appealing to use
Have you considered adding stdin for reading user input?
https://github.com/quickjs-ng/quickjs/issues/374
The ideal situation is that the upstream qjs-ng and qjs will be merged, but it seems that this is not going well.
The ideal situation is that the upstream qjs-ng and qjs will be merged, but it seems that this is not going well.
We'll soon move to qjs-ng. We're waiting for https://github.com/DelSkayn/rquickjs/pull/369 and https://github.com/DelSkayn/rquickjs/pull/373 to be finalized. This is not to far away.
Very exciting 🎉
Would Partially native web streams
look to cover this: https://github.com/awslabs/llrt/issues/318
or would that be more inline with 2025 Native Streams
Very exciting 🎉
Would
Partially native web streams
look to cover this: #318or would that be more inline with 2025
Native Streams
Likely the latter. We’d rather ship a more complete steams API than cut corners. But depending on how fast we can progress with the more feature complete stream API we can also do a lighter version similar to the spawn streams.
The roadmap sounds promising! I'm just wondering, if v1 is released, would LLTR become one of the default runtimes on AWS Lambda?
Below is a high level list of LLRTs priorities and roadmap items. Note that these are not final and are subject to change.
2024
2025