How suitable is rust for application dev?


#1

How does rust stack up against java,c++,js for application dev?

Just a curious thought.

Thank you !


#2

What kind of applications? Desktop? Web? Low-level/High-level?

Apologies if I misunderstood anything.


#3

Desktop applications. Please dont apologise . :slight_smile:


#4

Generally

The development time will increase slightly, depending if your algorithm needs to do a lot of simultaneous/concurrent mutable access to an array(or things of the similar sort, like pointer cycles, things you’d get away in C/C++ easily), then you’d need to approach it differently and redesign the algo a bit.

I’d say the type system helps catch a lot of things(a lot of places have talked about static type vs dynamic type, so i’ll skip it here). The pattern matching also helps making sure you’ve handled everything(say if you match against an Error, then the compiler will complain if you forgot a branch). Other stuff inspired by ML, FP family langauges help a lot with usability as well.

Practically

Memory safety is enforced mostly statically in Rust compared to all other stuff thanks to borrow checker, and so on.

Other than that, for concurrency/parallelism, performance, Rust is pretty similar to C++. (I might be wrong here as I don’t actively use C++).

Rust has a much better concurrency story than Java IMO, namely locks are heavily tied to Data in Rust(e.g. in Mutex<T>, RwLock<T> you can’t modify T without locking it first), but in Java, what data is associated to the lock is enforced solely by the programmer. You put a lock in your class, and you need to remember to lock and unlock appropriately manually.

Not much experience with JS, so can’t say much here.

The other possibility you might want to consider is Go. The go routines might be enough most of the time, and it’s a simpler language if you’re looking to get team members/contributors/larger community.

Other things to consider which are not tied to the language design, but to ecosystem, runtime, etc

  • Portability
    • Rust compiles on a lot of things
    • Java has JRE, which may be a big plus when distributing your app. OTOH some people(including me) might be very reluctant to install JRE just to run your app.
  • GUI
    • My impression is that Rust is somewhat lacking in this area
  • TUI
    • Rust seems to be pretty good for this
  • FFI
    • Rust binds to C very easily
  • Number crunching
    • Stable Rust does not support SIMD yet, you’ll need to use external code via FFI etc to get SIMD accelerated assembly code built into your app
  • Networking
    • Rust seems to be very good for net code(with tokio and other crates)

#5

Thanks for the detailed info…ill surely be needing a GUI for my app…I have heard QT is superb witj C++…Does it support rust as well?


#6

Very unfortunately I have yet to do any GUI development on Rust, nor have I used too many apps that use a GUI in Rust.

There are crates that provide access to Qt, QML, GTK+ in one way or another, so yes you can get Qt/QML to work with Rust, but the ease of development may vary depending on how you approach it.

There is a crate for pure Rust GUI as well(conrod).

You can give the list a shot.

Personally, I’d be prepared to using Rust for core code, and using other languages(e.g. Python, C++) for GUI.


#7

oh…thats possible ?..front-end of the application in say QT using C++ or python and the back-end in pure rust ?


#8

Yep, that is always possible, but may not be worth the effort.

There are namely two ways.

First way is to write your core code in Rust, then expose them via FFI and compile as a static lib, then use the static lib from C++ or Python or anything that supports C like FFI. If you want to distribute your app entirely via Cargo, then you’ll need to do a bit more heavylifting in your build.rs using this method.

Second way is probably very excessive, and takes far too much effort. You write the GUI as a separate app from the core app, then you do a lightweight, local cient server model. You can have your two apps to communicate via pipes, via ZeroMQ, or other libraries that do inter-process communication.

But either way, if you think you absolutely need Rust, and are willing to face some obstacles just to get your app complete with a GUI, then you should make sure your core code is very modular, so you can try all three methods above : using crates(easiest), using FFI and call Rust code from GUI code(not too bad, doable), or using client server model(absolute last resort).


#9

At now I am working on exactly application like this: GUI on C++/Qt,
and backend (core) on Rust. Backend in Rust is not pure, it uses several C/C++ libraries. All bridges: C/C++ 3th-party library <-bridge 1-> Rust backend <-bridge 2->GUI C++/Qt is automatically generated.
For code generation in bridge 1 I use bindgen, for bridge 2 I use rust_swig.


#10

Great stuff !!! …thank you !


#12

I’m actually using Rust at work. I’ve found that on the surface Rust’s GUI story isn’t overly great, mainly because there are already lots of other languages with strong GUI frameworks (C++ and Qt, Java Swing, GTK in Python/C, C# and Windows, etc) and the focus for the language has been elsewhere.

That said, Rust is an awesome language for implementing the business logic of your application in! At work we’ve got a legacy program written in Delphi and then I’ve added several modules as external DLLs written in Rust. The Rust code is considerably faster and I’ve found it to be several orders of magnitude more robust, with it not uncommon for the Delphi code to crash due to memory issues or have concurrency-style bugs like multiple things mutating the same datastructure and invalidating each other’s pointers/logic.

The compile times can be quite painful though. It’s probably because I have so many dependencies, but a full release build with a cold cache can often take over 10 minutes (although rebuilding after a change is normally less than 5 seconds). This is compared to the Delphi compiler where, thanks to the simple type system and single-pass compiler, it’s uncommon for it to take more than 10 seconds to compile 100,000+ lines of code.


#13

One day Rust will probably be the ultimate language for system applications development. Currently, you may need to reinvent the wheel in a few areas. Development is slow, but I find that my Rust code is an order of magnitude less buggy than say, C++ code so it’s a trade off I’m willing to make.

I’m currently developing an application with a highly dynamic GUI that doesn’t fit within the bounds of most GUI frameworks. Unfortunately for my use case I found conrod too slow and limiting. GTK and QT are inapplicable. So, I’m writing my own framework on top of gfx-rs. The work is straightforward but there’s a lot of it.

I also did a prototype with an Elm webui and Rocket backend. That was certainly a more direct route to having something that works, but it may not be appropriate for some applications.

So if none of the existing GUI libraries are what you’re looking for you may have to roll your own, at which point Rust may not be suitable depending on how much time you have to spend on the project. But if you do decide to roll your own and release it, the community will no doubt be ecstatic to have another GUI library.


#14

There are some experimental GUI rust libraries like https://github.com/nc4rrillo/indigo (nightly-only) or https://github.com/christolliday/limn