seedling
tool-conventions
seedling | tool-conventions | |
---|---|---|
1 | 3 | |
31 | 285 | |
- | 1.8% | |
3.2 | 5.6 | |
about 1 year ago | 8 days ago | |
- | Artistic License 2.0 |
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.
seedling
-
Features of a dream programming language: 2nd draft.
Webapp / app + systems development. In Rich Hickey's words: Information-driven situated programs. Ideally, also open to extension into more areas of programming. Scripting and prototyping, but also scalable to production use (app/webapp) Systems development (compiled)
tool-conventions
-
Isolates, MicroVMs, and WebAssembly (In 2022)
> Better interoperability
AFAIK, the examples you give all target a basic C ABI [0] or can be made to target the same ABI. In Rust, it means targeting wasm32-unknown-emscripten
The Rust team is also working on a "WASM ABI"[1] which would be useful in taking advantage of stuff like multi-value returns, and other compilers could just choose to target that. More likely, the C ABI on WASM will be updated to account for missing features, and that'll be the standard for interoperability in the WASM ecosystem.
[0]: https://github.com/WebAssembly/tool-conventions/blob/main/Ba...
[1]: https://github.com/rust-lang/lang-team/blob/master/design-me...
-
Features of a dream programming language: 2nd draft.
C ABI: Compatible with the C language Application Binary Interface (ABI). So code in the language is usable from other languages. Inspired by Zig. Since compiling to WASM is desirable, WASM's C ABI could probably be used, instead of a separate implementation towards the C ABI.
-
Crates for (mutable) statics with non const initialization.
There is maybe a solution. From what I found the linker will glue constructor functions and they have an associated priority. (look https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md here for the "linking meta data section"). I explored the ldd/wasm source code directory and it looks like there are also destructor functions. I have not found out in which sections such functions should be placed (after 1h of exploration). Would you like to pursue? I am ok to receive pushes or even share owner ship of the repository.
What are some alternatives?
ts-belt - 🔧 Fast, modern, and practical utility library for FP in TypeScript.
dwarf-2-sourcemap - A DWARF to SourceMaps converter for WASM
wyrcan
ramda - :ram: Practical functional Javascript
krustlet - Kubernetes Rust Kubelet [Moved to: https://github.com/krustlet/krustlet]
io-ts - Runtime type system for IO decoding/encoding
language-server-protocol - Defines a common protocol for language servers.
infernu - Type inference and checking for a safer JavaScript.
quokka - Repository for Quokka.js questions and issues
Immer - Create the next immutable state by mutating the current one
talk-transcripts - Transcripts of Clojure-related talks