Can the Rust programming language be used to develop programs for sale and / or programs that are not open source?
I also understand that Rust libraries would require Apache/MIT license to be included for that part of the software package, but I think that this does not limit the overall use of a commercial license for other proprietary software. Is that correct?
Is Rust mature enough to migrate an existing program to it?
Do you recommend an IDE?
Thanks Kindly
Mandatory: IANAL
Go and re-read the MIT and Apache licenses. They explicitly allow selling copies of the code under their respective conditions.
I hope so, since that's what I am doing for about a year now. I even wrote entire programs in it from scratch, which run on >1_000 digital signage devices here in Germany.
This is very subjective. I like and use RustRover and Code as a fallback. Sometimes I just use vim. Ymmv.
Thank you for information!
I'm a bit surprised about these questions. Have you read articles about Rust and the Rust Book already? If not, you should.
As for your questions:
cargo ftw!RE #6, libraries:
To clarify my question: Does rust support creation of shared libraries, e.g. .dll libs (Windows) and .so libs (Linux), or does rust only produce static libs.
When static libs are linked with a program, the program binary acquires the static library code, whereas shared libraries provides ability to call into a shared library that is loaded into memory separately from the program e.g. separately from the .exe (Windows).
Rust can both create and link to dynamic libraries, but with a caveat: Because Rust’s native ABI is not stable, the library’s interface has to be defined in terms of Rust’s FFI system even if you’re linking a Rust-built dynamic library to a Rust-built application.
Well-explained. Thank you! It appears to be a clever solution to allow flexibility to change the ABI with new versions of Rust rather than locking the ABI in. Logical.
Meanwhile, one could simply use the static library model for productivity, knowing that down the road, better shared library models are planned. True?
It is planned (see crabi), but I'm not sure there's much progress. If you need stable ABI you can (carefully) use extern "C" and #[repr(C)] to use C ABI.
Great information! Thanks!
I certainly hope so, we have been doing that for five years here!
Plenty of people have done that including myself. Although I think most Rust people and devs in general would advise against setting out on rewriting huge projects in Rust unless there is a very good reason for it. Like the need for speed or if the old code is so insecure it cannot be saved.
Not really. With Rust's insistence on type and memory safety the need for a debugger is greatly reduced. With Cargo the need for some IDE's idea of "project files" or whatever build system is not there. So what's left, one only needs a good editor, preferably with syntax highlighting, syntax error highlighting etc. I have been using the Zed editor for months now, it's simple and fast. And oh, it's written in Rust. https://zed.dev
I noticed zed has some vim key-bindings, but I think it does not go much deeper than the cursor movements?
Great information! Thank you. A functional editor coded in Rust is an indicator that Rust is mature! (Not to mention the editor itself looks interesting).
It does. I have no idea how well. I've been using vim for years and years and still only know and use a handful of its key bindings. Perhaps I use Zed so as not to have to.
RustRover, or CLion with the official Rust plugin. VsCode with rust-analyzer is also a popular option.
That depends on the domain of your application. Some cases are well-supported, some are more experimental.
Migration is also always a complex issue. You need to really think about the RoI of that. Do you have enough engineers who can work with Rust? Does Rust give you tangible benefits? How large and complex is your codebase? The answer very much depends on the specifics of your use case, and you should do your research,
But in abstract, yes. Rust is absolutely mature enough to migrate your app. The problems may be with your dependencies.
Sure, why not? If you are talking about distributing compiled libraries rather than internal tools or end-user application, the answer is more complex. Closed-source libraries are not a well-supported use case. There is also no stable ABI, unless you use the C ABI. You can always build a dynamic or static library with C API, but if you want Rust-native API then you are forced to provide your source.
No header files. The translation unit is a crate. Crates are built in parallel, if possible.
Obviously.
Definitely no worse than C++ or Typescript. In general Rust allows arbitrary compile-time computations, so you can make your build arbitrarily slow. But not by accident: you'd have to heavily use type-level computations, or procedural macros (something like diesel with its compile-time database schema validation is a common offender), or build scripts, or C/C++ dependencies. It's also easy to pull in huge dependency trees, if you're careless with your dependencies and want to do something complex.
Yes. Why are you even asking? Do you think this is a toy language?
In that case consider using the nightly toolchain and unstable language features. Many features are reasonably stable, but take a long time to fully stabilize due to some edge cases, or a simple lack of manpower.
Make sure to open an issue if you hit a compiler bug!
To give some context: Rust has been 1.0 since 2015, and in serious development for nearly 10 years before that.
It's in active, if currently still limited, use in Linux and Windows, and many cloud providers have rewritten critical parts of their infrastructure in Rust, including Cloudflare and AWS, among countless other industry success stories.
Rust is currently 14th on the TIOBE index (for what that's worth), just ahead of Apple's Swift, and Ruby; and also 14th on the stack overflow survey language use, right behind Go.
This is the language that the US government is recommending instead of writing new projects in C++ (to handwave a tiny bit).
This is a Real Big Boy Pants Programming Language: even if it's still on the upwards curve of industry adoption, it's already far more mature than pretty much any reasonable commercial readiness requirement would need, the exceptions being either defense or healthcare type industries that require formal validation... which is in progress; or the real dinosaurs that still have COBOL to maintain, let alone this newfangled "C" programming language (which, fair enough!)