Quick update: I have reasons to believe it should be possible to get rid of the ~2.5GB Android NDK dependency, replacing it with a ~100MB Zig dependency (because @andrewrk is crazy enough to ship Zig with a magically squished C cross-compiler).
How was your experience with Nim doing all that?
I love it for prototyping. I feel if I need to draft some algorithm/design in my notebook in pseudo-code, I will be able to just translate it straight away to a very similar-looking code in Nim. In my eyes, it’s basically more or less like Python with static typing. I love that it feels concise yet easily readable, in my opinion. I find Nim to be a perfect fit for my hobby projects, a great enabler for trying to materialize my ideas. It still keeps some air of whimsy for me, which helps me to not get bogged down by too much seriousness when prototyping.
I’m not yet sure how well it can work for bigger, later stage projects. The Nim compiler itself is one such project; I think it stays quite readable, but I personally find it hard to navigate. However, this may be solved if there’s some IDE support (i.e. “go to definition”) available; I haven’t searched for it yet. I’m also not sure about eventual “robustness” at later phases. By this, I mean error handling. Exceptions are great for prototyping, as I can just push forward and ignore them, knowing I’m fully OK with crashes & stack traces. For eventual full-blown robustness, I would think I might theoretically prefer a more Go-like approach, forcing me to analyze each and every line for possible errors & their handling. The language is also still expected to change somewhat IIUC, at least in semantics (e.g. potential removal/reduction of GC use). Though, static typing may help ameliorate that. (I suppose people may complain as with Elm upgrades, but I hope it should be similarly doable in the end, if somewhat annoying.)
Things I dislike are: too hard to find stuff/browse in the standard library docs (Go docs are the gold standard for me in this area); stdlib APIs are a mixed bag — sometimes great, usually acceptable, sometimes messy, occasionally downright braindead. Also, there are some areas of the language I think I don’t have a good feel for yet, as a newbie. Thus I’m not sure if they’re dubious, or I just haven’t grasped their idea/idiom yet. I currently tend to assume it’s probably the latter and I need some more time to get accustomed to some stuff, to internalize it and let my mind find its ways with it (as tends to be required with every new language).
Finally, please note this project of mine is a relatively simple design — just pushing some bytes around, squeezing and moving them here and there. No database, no concurrency, no isolation/permissions, not even networking. Not much experience on those yet on my side, in Nim. Still, I would not be surprised if they were quite nice to work with too.
Appreciate the review. Yeah, it should be fine for prototyping. Python-like but faster.
This is very interesting. I wonder how many alternative dex/apk builders are out there.
I know that Godot, the open source game engine, is looking to reimplement their Android exporter to be independent of external tools being installed by the user.
Cool, thanks! Good to know, so I should probably contact them, they could be interested.
As to alternatives, I didn’t find many. I mean, there’s absolutely smali, which is basically the alternative dex assembler/disassembler; but it is also written in Java, so it requires JVM. Which is something I wanted to try and avoid too. (And I was also plain curious to explore how much work it could be to just do it by hand. Which showed up to be surprisingly little!) Other than that, there was the official Jack & Jill Java->.dex compiler/toolchain, but it was discontinued.
Thanks for those links, it’s interesting to see the landscape of alternatives in which a (new) project fits.