[c] In defense of the spine-c runtime #2893
Description
Hey there. Recently, I noticed this comment indicating that spine-c will be phased out with Spine 4.3. I totally understand the desire to consolidate the C and C++ runtimes, and I expect that in the C/C++ world, there are way more game devs utilizing C++ than C. In that respect, it makes perfect sense.
I also understand that, as a result of this, the C runtime receives a lot less love than the others. I imagine it's quite disheartening to see basic issues being filed, like the couple of issues I have filed before. It indicates that the spine-c runtime isn't getting any serious use.
I believe that the benefit of keeping spine-c separate, rather than being a C wrapper over C++ code, is being overlooked. I wanted to voice my concern, and show support of the spine-c runtime. I must admit that it's for pretty selfish reasons, but I think it's still worth calling out.
The selfish reason is that I maintain rusty_spine, which is a Rust library for the Spine runtime. rusty_spine is a Rust transpilation of spine-c, made possible by c2rust. The practical benefit of transpilation is a bit hard to explain succinctly, so I hope some of it might be obvious. The primary motivating factor in my case is that I want to develop web games, in Rust, and Rust itself makes this very easy. By relying on a C++ runtime, I can't rely solely on Rust, but will also need a C++ compiler like emscripten. My game will now need to rely on the C++ standard library, in addition to the Rust standard library. In the context of web games, this also makes the binary size larger, which is really not ideal.
In contrast to spine-cpp, spine-c has a stupidly simple runtime. In the case of unix systems, the runtime is bundled with the operating system in the form of libc. In my case, running in the web, I was able to provide everything necessary in only about 1000 lines of code (when removing comments and test code). That's it - that's all spine-c needs to run.
By killing off spine-c, I believe all that's left are Spine runtimes that bring with them large standard libraries and opinionated (and often complicated) build tools that heavily discourage use of Spine outside the select few officially supported cases. It's maybe presumptuous of me to say, but the interest in Rust and Zig in recent years seems to indicate a changing of tides away from C++, so requiring its use feels like it could alienate future use cases. It seems to me that, despite this, through tools like c2rust and C's overall simplicity, C remains timeless. A better indirection might be to have spine-cxx rely on spine-c.
Finally, I want to point out that the stated reasoning in the comment I posted was that the C runtime might have more overlooked issues. I admit that when I started using spine-c, it had many obvious issues, but once the obvious issues were ironed out, it has been perfectly useable. There might be some impression that the runtime is too far deteriorated to be worth maintaining, but I think that's not true.
I want to play devil's advocate here, because I totally understand the maintenance cost of another runtime. In the case of rusty_spine, it sees very little use from what I can tell. There's actually a graph over at crates.io to get a better idea. Additionally, my Bevy plugin hasn't even been updated for the latest two Bevy versions (primarily due to significant changes in Bevy APIs and a lack of time on my part to catch up) - and not much interest, from the community, to rectify that situation. It's hard for me, at this point, to suggest that by killing spine-c and this particular use case, that you're impacting very many people.
Additionally, there are other avenues to continue supporting rusty_spine, besides transpilation. Most likely, it will involve moving to interfacing directly with spine-cxx. It will be a non-insignificant amount of work on my part, but in the end, it might be easier to maintain for everyone. Transpilation is not without its headaches, and is a more bespoke solution. The issue of interopting between C++ and Rust is one that will smooth over with time, and may already be perfectly serviceable.
I wanted to raise these points before I spent much time investigating other options for rusty_spine. If the decision remains to remove spine-c, I totally understand that. I also have to admit that I'm not too familiar with things like haxe, and possibly other runtimes, that might offer a solution I'm not seeing, so corrections on my understanding would be appreciated. Thanks for your time!