3 ms·

It's not just a matter of putting in enough man-hours to create decent bindings. Native-C++ libraries are hard to write good bindings for in the best of times,

It's not just a matter of putting in enough man-hours to create decent bindings. Native-C++ libraries are hard to write good bindings for in the best of times, typically requiring C wrappers with limited functionality and/or significant runtime overhead. Creating workable and safe (but still non-idiomatic) bindings for a C++ library from a language like Rust with a very different object model (can't use C++ templates or define new C++ subclasses; functions called from Rust must not throw C++ exceptions) and a far stricter type system than either C or C++ (borrow checking, lifetimes, thread-safety enforced at the type level) can be next to impossible. Even if you succeed, the result will be restricted to the least common denominator supported by both C++ and Rust and will never feel like a native Rust library. This is not to say that Rust could not benefit from the significant effort which has gone into developing Qt, but a Rust port of Qt might be more workable than bindings to the C++ toolkit.

j1elo 5y ago
> a Rust port of Qt might be more workable than bindings to the C++ toolkit. That's an interesting idea! it might be worth considering it, at least. I wasn't thinking of a full-blown bindings that cover 100% of the API which is an immense task and, as your sibling comments thinks, was a mistake. A more opinionated stance of what parts of the Qt features are deemed necessary seems more feasible in the short to medium term. I wasn't advocating for one specific way of doing it, but for the more general sentiment that reinventing the wheel and creating a new toolkit from scratch is definitely the most expensive of all the options, in terms of human effort, time dedicated, and progress achieved. We'd basically be decades later than other OSS options, why not build upon their shoulders instead?

j1elo 5y ago

> a Rust port of Qt might be more workable than bindings to the C++ toolkit. That's an interesting idea! it might be worth considering it, at least. I wasn't thinking of a full-blown bindings that cover 100% of the API which is an immense task and, as your sibling comments thinks, was a mistake. A more opinionated stance of what parts of the Qt features are deemed necessary seems more feasible in the short to medium term. I wasn't advocating for one specific way of doing it, but for the more general sentiment that reinventing the wheel and creating a new toolkit from scratch is definitely the most expensive of all the options, in terms of human effort, time dedicated, and progress achieved. We'd basically be decades later than other OSS options, why not build upon their shoulders instead?