pest VS json

And some related parser tools: - https://github.com/kevinmehall/rust-peg - https://github.com/pest-parser/pest - https://github.com/lalrpop/lalrpop

I had recently completed the first year of my Computer Science class at school and will begin my second year soon. My schools' class forces the use of Java programming language, and I absolutely hated it. So, over the course of a little less than a month, I wrote my own programming language, in Rust (objectively best programming language), using pest, to be as similar to Rust as possible, but compiling to Java.

I second pest.rs. Using it is fairly intuitive and there's also a live playground on their website which is great for quickly developing and testing your AST (abstract syntax tree) parser for whatever language you're implementing.

This is where you'll run into trouble. People who write parsing-related Rust crates generally write things like pest that expect their syntax to be defined completely at compile time so the parser can be run through the compiler's optimizers for best performance.

Give https://pest.rs a try.

For now I have used pest to generate an AST that borrows from the given input. But if I can manage to make the parser generic over the return type it may be worth a refactoring.

Oh wow. So serde_json doesn't roundtrip floats by default, it uses some imprecise faster algorithm https://github.com/serde-rs/json/issues/707

Good thing there's msgpack I guess.

tokio / hyper / toml / serde / serde_json / json5 / console

Serde JSON, an extension of the serde crate that enables the serialization and deserialization of Rust structs.

To serialize and deserialize data, we'll employ the popular serde crate along with serde_json. This will allow us to easily convert between Rust types and JSON when working with API requests and responses. For async operations we'll use the Rust futures crate.

From the Cargo.toml file above, we can see that the Perseus version at the time of publication is 0.4.2 and has the following dependencies that are common to both the engine side (server-side) and client side of a Perseus application: sycamore, serde, and serde_json.

serde_json

Number parsing uses a fairly naive but uses a lossless algorithm in musli-json. In serde_json they use a fork of lexical I haven't wrapped my head around. I wanted something simple to start with.

Your best best would be to use an enum. Either your own or something like the one from serde_json depending on what you are trying to do.

Don't do that if you care about memory usage. In your toy program, I wouldn't be surprised if memory usage was a lot better if you used Box instead. (even if it doesn't look like it, you can handle almost all the use cases of serde_json::Value with it, often not much less convenient)