cpp-vs-rust VS inox2d

> They seem to have chosen to use mold for C++ and not for Rust after seeing that it gave little benefit for small projects, but I would expect that to change as the project scales.

The benchmarks show Mold for both Rust and C++. This wasn't explicitly stated in the article; sorry. https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...

Very well-researched article (in my uninformed opinion because I've done virtually no benchmarking). I'd summarize it as, Rust doesn't significantly improve build times over C++ for a project where you need to frequently recompile to test the logic of the code. I gather that the Rust code is pretty idiosyncratic (using raw pointers rather than slices and custom owned and borrowed string containers with i32 length and capacity fields), but I don't know why more idiomatic Rust code would be faster to compile, and it could be very different, so a worse comparison. The results aren't relevant for me because I use Rust mainly for the language features and don't have a project with terrible compile times or the need to often rerun tests, but there might be other C++ projects in the same boat as quick-lint-js that would consider moving to Rust if it compiled faster than C++. Hopefully the efforts of people like u/nnethercote will make that happen.

I'm writing Inox2D, which is kind of a rewrite of Inochi2D in Rust. The aim is to reach more use-cases such as web with WASM and even potentially embedded development, but at the very least an implementation in a low-level non-garbage-collected language.

Inox2D, an experimental native Rust implementation of Inochi2D.

inox2d - official experimental reimplementation of Inochi2D, an open-source alternative of Live2D for animating 2D puppets in various contexts such as games or vtubing. inox2d isn't really meant to be a replacement over the current implementation, but more of a complementary one that extends it's use-cases, for example embedded devices and web integration with WASM.

Hey, I'm working on inox2d which uses glow.

For example, I wouldn't want to separate this into multiple files, would make it harder to see where all the deserialization logic is.

For example, I'm working on Inox2D, a reimplementation of Inochi2D in Rust.

I absolutely get that. It was actually very clear in a project of mine. I work on inox2d which is a native implementation of Inochi2D in Rust (Inochi2D being a FOSS puppet animation system, like Live2D which is used by vtubers and light novel engines notably).

For example, on my Inox2D project, I was using serde to deserialize some JSON payload. But that came with some hacks I had to do, like have a temporary struct that gets converted to the final one because it wasn't possible to serialize it by itself, and add extra-dependencies to make the system extensible while also supporting external structures I used like Arena from the indextree crate.

You can find it at https://github.com/Inochi2D/inox2d. If you know stuff about OpenGL and low-level rendering in general I'd really appreciate some help as I myself am very new to this stuff.