State of Rust Survey 2020 results
blog.rust-lang.org
blog.rust-lang.org
It was run by our survey working group, of which I am not involved. So I can’t take any credit here.
Was this just based on self-report? An alternative interpretation could be that C/C++ programmers are just more confident.
I of course, think that C FFI is as good as I personally need it to be. It's as good or better than most other languages that are not C.
I think at least for non-mutable stuff, C++ string_view (approximately rust &str), span (approximately rust slices), and the like should make at least some operations as simple as pointer casts, but having tooling to automate the boilerplate would be nice, and they're also new/not that widely supported (std::span is from C++ 20). And mutable stuff, if you want to be able to write idiomatic/ergonomic code on both sides, seems like a much bigger lift.
Compare that to C, where the story is often as good as "import the header and you're done".
I'm not sure if there's a good path to a long-term solution, but I've been pushing to get nice C APIs in all the libraries I'm invested in, specifically because of this issue.
So while .NET type type doesn't cover all of C++, it does cover enough not to have clunky C interfaces, and nowadays many Windows APIs only have such COM/UWP interfaces as public API.
Microsoft is in the process of adding Rust to their COM/WinRT infrastructure.
One of the beauties of COM is that it is interface based component model, so it goes quite well with languages that have interfaces/traits as feature.
[0] I really don't care if in C or a different language, but I'm not aware of relevant programming subcultures where that simplicity of interfacing is such an important pillar to their culture and their success.
Yes, C is clunky and primitive, it was my opinion in 1992 coming from Turbo Pascal 6, and it hasn't changed since.
Seriously, here is just one taste of the intricacies of the COM: https://www.codeproject.com/Articles/9190/Understanding-The-...
This is 90's enterprise OOP technology. There is no good excuse to use this other than technical debt.
There is no good excuse to use outdated articles to attack technology one hates.
Here, some 2020 stuff to educate yourself.
https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...
When I attack C's clunky and archaic coding, I do so with full knowledge of C17 and how little it has changed with K&R C that I learned in 1992, in API design and OS security.
https://github.com/rytc/enet_single/blob/master/enet_single....
WinRT is no mess, and I look forward to the day everyone has to put up with them, now that both application models are being merged anyway.
SWIG is what people really want.
IMHO going through C APIs is fine, because C++ interoperability is much harder and a moving target, just because the language surface is so much bigger than plain C.
(I was only thinking of calling)
See Zig as an example for excellent C interoperability.
As soon as a C/C++ compiler toolchain and build tools need to be involved in a Rust project you're basically loosing all advantages of Cargo and are back to the relative brittleness of cross-platform C/C++ builds.
I’m also curious if the % using nightly number is getting skewed by the population growth of Rust itself rather than language feature changes itself (assuming the study is actually sensitive enough to confidently state a 2% change is outside of the error margin).
Generally I’d say the async stuff is still pretty confusing. Like not if you’re entrenched in the Rust ecosystem but it seems like you have to choose the runtime you build around (Tokio vs async_std) and they’re drastically different maturity levels and feature sets so it’s more complex then just picking one as now you have to make sure the entire dependency train is consistent (or you end up with multiple competing implementations running within a system) which I’m concerned about as you scale up the complexity of a codebase (and writing code that doesn’t have to care is similarly difficult it seems where you kind of have to choose a specific dependency to get access to even basic I/O).
The other rough edge is that certain lifetime stuff in Rust still is over specified I’d consider. The example is unpacking a struct to be parameters for a function. Like
do_something(&mut self.x, &self.y)
The other one is it feels like the compiler has reduced in power from suggesting what modification needs to be made. Either:
1) I’m writing more complex/different code than before. Possible since I’m doing an async codebase from scratch vs contributing to a more established Rust codebase.
2) most of the corrections it made before have already been incorporated in the automatic stuff the compiler is now inferring meaning the remaining pieces are the hard ones that have never had corrections in the first place.
3) the focus on auto-correction suggestion has diminished so new features are going in without considering as well as before how to guide the user to fix the issue (or these are harder suggestions in this space that haven’t been explored yet as the original suggestions were easier/better studied). The focus switch could even be intentional (other areas of the language need more focus) 4. I’m sure there’s other possibilities.
The final nit I’d note is one around crate discoverability. There’s a lot of crates out there and there’s a lack of documentation on them (ie are they abandoned, “finished”, active development) and selection criteria (ie which crate should I use given my project dependency chain, perhaps crowdsourced ML suggestions from other projects like a “Netflix” recommendation with ability to inject additional details like “I’m looking for something that provides certain algorithmic or memory guarantees, is async or not, etc” if those things aren’t available from the existing dependency but a new thing being added). The data is there nominally as fancy charts because that’s kind of easy but the harder proactive advice with explanations is the real gold no one has done and can really push Rust to the next level for engineering efficiency.
#![feature(bound_cloned)]
#![feature(const_float_classify)]
#![feature(const_fn)]
#![feature(const_fn_floating_point_arithmetic)]
#![feature(const_generics)]
#![feature(const_panic)]
#![feature(once_cell)]
#![feature(option_result_contains)]
#![feature(or_patterns)]
#![feature(str_split_once)]
or_patterns are pleasant syntax sugar.
bound_cloned, option_result_contains, str_split_once are minor convenience shortcuts for things you can do slightly more verbosely on stable.
The other half are all about const generics and const fns. You can emulate some of them on stable, but the cost far outweighs that of switching to nightly in my case.