> There are a litany of benefits to Rust that include, but are not limited to
Other than Cargo, none of the advantages you mentioned are actually advantages, and are just basic features that are shared by multiple programming languages for decades.
If it's hard to justify Rust's use, why insist it's a decent tech stack for this sort of applications in spite of all of the evidence to the contrary?
I thought I made it clear - but apparently I should have been far more blunt - that I don't particularly value going in to a comment chain regarding "justify Rust's use for $X". I say this to point out that you're trying to imply:
> If it's hard to justify Rust's use
I don't consider it hard, I'm just not spending time on it because it's not worth it to me. If I felt it was worth it, I could discuss language features or so on (error handling, functional programming idioms, etc). It's covered fine elsewhere. ;P
> Why insist it's a decent tech stack for this sort of applications in spite of all of the evidence to the contrary?
This entire thread is due to my not buying the "evidence" that it's hard.
Go write in whatever language you want. I want to write in Rust, and I want a functioning GUI framework and I think people are overthinking it. shrug
Your empty claims hold no water. You stat you don't consider it hard to justify Rust's use, but you still failed to provide any suport, let alone a coherent argument, justifying it's use.
I get fanboys want to support their pet tech stack no matter what and in spite of all evidence, but hand waving over the problem doesn't lead to progress. It just pushes an irrational belief that helps no one, and just showcases a need to lose touch with reality.
It depends on the use-case. Also with Rust, unlike Swift for instance, you only put behind an Arc what needs to be, whereas in a managed language you pay the GC overhead for the entirety of your objects.
ObjC's and Swift's ARC (Automatic Reference Counting) is not just dumb "reference-count everything", the compiler does static lifetime analysis and removes redundant refcounting operations.
In theory at least this may actually yield better results than in C++ and Rust where refcounting is implemented as stdlib feature and optimizations rely on "zero cost abstractions" late in the compilation process.
But even ARC needs a lot of handholding and manual tweaking if performance matters.
Granted, it probably has improved a lot since 2016, but I didn't have an occasion to update my knowledge about Swift since then. Back then you definitely ended up with tons of pointless ARCs, but in fairness the compiler was brand new at that point so no wonder it wasn't good at optimizing stuff away.
Rust is often the best language for the meat of your program; it's nice to use it for the gravy too.
Many, if not most, programs are not primarily UI's. They exist to control something, calculate something, transform something, et cetera.
All of these need a human interface. Perhaps a command line and a config file is sufficient, but often an interactive UI helps.
You could create an API to your rust program and then write the UI in something else, but there are huge benefits in writing both in the same language.
- Cargo and the general ecosystem
- The relative ease of integrating with just about any other system
- The ability to just build a binary rather than dealing with bundling interpreted languages (like with general Python/Ruby/JS/etc)
See my other comment in this thread for why I consider that "higher overhead" to be meaningless for general applications.