sxml
kaydle
sxml | kaydle | |
---|---|---|
2 | 3 | |
5 | 70 | |
- | - | |
3.7 | 1.2 | |
21 days ago | 8 months ago | |
TypeScript | Rust | |
Mozilla Public License 2.0 | Mozilla Public 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.
sxml
- The KDL Document Language
-
Deno Is Now on MDN
> wrt Java
Not just Java. Python, Ruby, Node etc suffer from the same problem. And I am taking as an end-user here.
I once downloaded something based on one runtime which then proceeded to download another runtime which it needed to run one little script. There are programs out there that have node/npm as a dependency.[1] People are crazy.
> your 3 listed reasons make a very argument for "a normal compiled language"
One of my hobbies involves writing compilers and parsers.[2][3] I have tried a lot of "normal" languages and have stuck to Java (in spite of its excessive verbosity) for work reasons. Some languages I cannot tolerate for aesthetic reasons.
For now, there is no alternative to TypeScript.
> you wrote software 2 ways: shellscripts and Java. You replaced them with...any entirely new interpreted language(JS)
I used to run a mixed-environment (Windows + Unix) and a lot of glue code that drove other software had to be written twice (sh/bash + cmd/bat) before WSL came along. That problem has disappeared.
I also used to write a lot of tools (servers and cli apps) in Java. Some of those I have moved over TypeScript-on-Deno.
> I'm not denigrating JS/deno/node/whatever
I used to look down on JS a decade or so back. My experience with Rhino and now Deno changed that. There is a lot of stuff that I do now which I simply would not do if I have to fire up an entire Java project to do that.
[1] https://archlinux.org/packages/community/x86_64/nodejs/
[2] https://github.com/s-i-e-v-e/ut
[3] https://github.com/s-i-e-v-e/sxml
kaydle
-
impl serde::Deserialize... is it really that complicated?
Now, in practice, most deserializers will transparently forward themselves through visit_newtype_struct (json, yaml, MessagePack). However, because deserialize_newtype_struct has access to the type name being deserialized, and some deserializers will use this type name to inform custom behavior. For instance, in my (in-progress) implementation of KDL uses type names (including newtype names) to inform the names of nodes in homogeneous lists, bridging the gap between serde's collection-oriented model and KDL's node-oriented model. You can also see that the json and MessagePack serde implementations use special typenames to opt-in to custom behavior (like serde-json's raw-value feature).
- The KDL Document Language
-
The KDL Document Language, an alternative to YAML/JSON/XML
My implementation is here: https://github.com/Lucretiel/kaydle/blob/main/kaydle-primitives/src/number.rs
What are some alternatives?
deno - A modern runtime for JavaScript and TypeScript.
kdl - the kdl document language specifications
kdl4j - KDL Parser for the JVM
ron - Rusty Object Notation
Kaitai Struct - Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby
json5 - JSON5 — JSON for Humans
import-maps - How to control the behavior of JavaScript imports
kdl-rs - Rust parser for KDL