26 ms·

What about cross platform with UI and requiring high performance? Eg anything for consumers with image processing. Hard to beat C++ and Qt in this case, IMO.

pedrocr 8y ago
For the UI rust has bindings for a lot of stuff and it's easy to generate more. There are also more and more native options. It's also very good for that use case because it makes certain high-performance things much easier/safer. Threading is a joy for example. I've worked on an image processing project in C for a while and am now doing one in rust and would never want to go back. The code is much cleaner and easy to maintain. The zero-cost abstractions really pay off, and the safety guarantees means you don't spend so much of your time chasing heisenbugs from subtle threading and locking issues.
- danieldk 8y ago
  For the UI rust has bindings for a lot of stuff and it's easy to generate more. I use Rust as my main language, but as far as I have seen gtk-rs is the only somewhat mature binding for an existing UI toolkit. This is not coincidental, since Gtk+ is a C (with objects) toolkit, it is much easier to bind than toolkits in other languages. Unfortunately, outside Linux, Gtk+ also looks pretty out of place. AFAIK, there isn't any binding for e.g. Qt or Cocoa that has wide API coverage and is mature. Definitely not for production-level work. I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc.
  - pedrocr 8y ago
    I searched and saw some Qt bindings as well, but didn't check if they're complete. I've decided to just do 100% rust so I use conrod instead of bindings. But the cases where I've tried the GObject stuff it did indeed seem pretty well done, at least in the Gstreamer case. I'd expect that over time even this gets fixed and Qt bindings become first class as well. > I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc. This is the worst case and is not that bad. It does force you to write in two languages but on the other hand it enforces a cleaner UI vs backend split and that's not a bad habit to have.
earenndil 8y ago
I don't know about rust, but d has bindings to gtk and qt, in addition to its own hardware-accelerated ui library (dlangui), and nim can include c headers directly and so easily use gtk. Nim, rust, and D are all capable of c-level performance (numbers, pointer munging, etc. are all available the same as in c).
- snovv_crash 8y ago
  So you can take the same codebase with these and deploy a UI plus libraries to Linux, Windows, Mac, Android and iOS? In a production ready manner?
  - earenndil 8y ago
    (Note: this applies only to d as I don't know enough about the other two to say) not ios, but aside from that, yes.

pedrocr 8y ago

For the UI rust has bindings for a lot of stuff and it's easy to generate more. There are also more and more native options. It's also very good for that use case because it makes certain high-performance things much easier/safer. Threading is a joy for example. I've worked on an image processing project in C for a while and am now doing one in rust and would never want to go back. The code is much cleaner and easy to maintain. The zero-cost abstractions really pay off, and the safety guarantees means you don't spend so much of your time chasing heisenbugs from subtle threading and locking issues.

danieldk 8y ago
For the UI rust has bindings for a lot of stuff and it's easy to generate more. I use Rust as my main language, but as far as I have seen gtk-rs is the only somewhat mature binding for an existing UI toolkit. This is not coincidental, since Gtk+ is a C (with objects) toolkit, it is much easier to bind than toolkits in other languages. Unfortunately, outside Linux, Gtk+ also looks pretty out of place. AFAIK, there isn't any binding for e.g. Qt or Cocoa that has wide API coverage and is mature. Definitely not for production-level work. I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc.
- pedrocr 8y ago
  I searched and saw some Qt bindings as well, but didn't check if they're complete. I've decided to just do 100% rust so I use conrod instead of bindings. But the cases where I've tried the GObject stuff it did indeed seem pretty well done, at least in the Gstreamer case. I'd expect that over time even this gets fixed and Qt bindings become first class as well. > I think currently the only viable solution is to write a core in C++, expose C functions and write the UI in C++, Swift, etc. This is the worst case and is not that bad. It does force you to write in two languages but on the other hand it enforces a cleaner UI vs backend split and that's not a bad habit to have.

earenndil 8y ago

I don't know about rust, but d has bindings to gtk and qt, in addition to its own hardware-accelerated ui library (dlangui), and nim can include c headers directly and so easily use gtk. Nim, rust, and D are all capable of c-level performance (numbers, pointer munging, etc. are all available the same as in c).

snovv_crash 8y ago
So you can take the same codebase with these and deploy a UI plus libraries to Linux, Windows, Mac, Android and iOS? In a production ready manner?
- earenndil 8y ago
  (Note: this applies only to d as I don't know enough about the other two to say) not ios, but aside from that, yes.