I have been using this for a few weeks, as a newcomer to Rust. Although it has some issues, I would not try to develop Rust code without it. It is incredibly useful and works well enough for day-to-day use.
Some of the issues I've found:
* Code completion sometimes simply fails to work. For example, inside future handlers (probably because this involves a lot of type inference).
* When errors are detected only the first line of the compiler error message is accessible in the UI, often omitting critical information and making it impossible to diagnose the problem.
* It is often necessary to manually restart RLS, for example when your cargo.toml changes. It can take a very long time to restart if things need to be recompiled and there isn't much in the way of progress indication.
* This is more of a missing feature, but type inference is a huge part of Rust, and it's often difficult to know what type the type inference engine has chosen for parts of your code. There's no way to find out using RLS in VSCode that I've seen, or go to the definition of inferred types, etc.
Other issues I've seen as a newcomer to Rust:
* It's very easy to get multiple versions of the same dependency in your project by accident (when your dependencies have dependencies), and there is no compiler warning when you mix up traits coming from different versions of a crate. You just get impossible-seeming errors.
* Compiler speed is a big problem.
* The derive syntax is super clunky for such an essential part of the language. I think Rust guides should emphasize derive more, as it's unclear at first how essential it really is. Almost all of my types derive multiple traits.
* In general, Rust is hard. It requires a lot more thinking than e.g. Python or even C. As a result, my forward progress is much slower. The problems I have while coding in Rust don't even exist in other languages. I'm sure this will improve over time but I'm not sure it will ever get to the point where I feel as productive as I do in other languages.
> The problems I have while coding in Rust don't even exist in other languages.
Yes, Rust probably requires more thinking to program in than C. But C's hard-to-troubleshoot runtime segfaults become hard compiler errors (with line numbers and useful error messages!) in Rust. Trust me, I've had plenty of fights with the borrow checker. But, once I finally get it to compile successfully, I know that my program isn't going to fail at runtime by accessing memory in some invalid/incorrect way.
This is true and I love this about Rust. However from a pragmatic point of view, I'm definitely spending a lot more time wrestling with the type system than I ever spent debugging memory errors in C. Overall I am less productive. As I said that may change, but I am not certain that it will.
To me the benefit of Rust's type strictness is not productivity, but security. I would not write any network-facing code in C today. I would choose Rust over C even with the productivity hit. But other languages, such as Go, might be a better choice if productivity is higher.
90% of Rust's draw to me is that the type system will give me a proper fight by default, instead of C++'s constant uphill battle of researching and opting into everything under the sun, filtering out the false positives, and then fixing the latent and not so latent problems uncovered by such efforts.
I haven't been nearly as lucky as you when it comes to avoiding memory errors (and debugging them). Large very active multi-team projects with years to decades of version history behind them results in a huge haystack. Individual memory or threading bugs can eat weeks or more, and with that many committers - I think there's some kind of quadratic or worse time sink in there. Memory safe languages fix some of that, and are massive productivity boosts as a result, by either preventing or making shallow such bugs.
To me it's not that Rust's borrow checker sounds like some good idea on paper, or just for security. To me, Rust's borrow checker is merely a unified, consistent, standard, and enabled by default implementation of much of what I'd been hacking together through the haphazard use of extensions, static analysis, runtime tools, and disabled by default annotations in C++ - since before I even knew what Rust was - with the specific aims of boosting my productivity and reducing my stress. The security is a nice bonus too.
I've "replaced" C++ with C# in a lot of cases. Rust is threatening to replace most of the remainder (except for existing projects which need to be maintained and don't make sense to rewrite.)
It's pretty straightforward though. Just declare a delegate with the same type signature as a your C function callback. Add that as the signature passed in to a native function and C# will make sure to marshal it to a standard C function pointer.
Only catch is if you want to keep a hold of the pointer in native you need to make sure to create a GCHandle to the passed in delegate with an identical lifetime. Otherwise the GC will collect the delegate from underneath you.
> ... a lot more time wrestling with the type system than I ever spent debugging memory errors in C
that's because for programs that you wrote in C, there exists hidden issues that you never paid a cost to fix (which, potentially saved you the effort if in practise it never was problematic). In rust (or haskell perhaps?), you pay that cost up front, and then the "time lost" to debugging/runtime issues had it been in C wouldn't show up as a "reward"!
I find this to be a troubling way to think about programmer productivity - a lot of opponents to functional programming or formal methods use this point against it. Spending this large an amount of time, solving issues that _may_ not be a real issue in production, just isn't worth the cost. I don't agree, but i suppose it's a judgement call for the programmer.
This is just anecdotal, but for me productivity in Rust is way higher than C++. Sum types and pattern matching, affine types, the choices made by the standard library, and Cargo all contribute to that.
I suspect once you get your head wrapped around Rust's type system idioms things will get better. I am interested to see how this turns out for people in general, though.
Basically if you have a struct to represent, lets say a Window, and inside of it try to reference instance variables on a closure that would handle a button click for example, self will be moved.
There are a few workarounds, but all of them are less ergonomic than any mainstream GUI toolkit.
There was an initial hard slog around the borrow checker, but once it all clicked it's been very smooth sailing. The only thing I've had trouble with in the months since is when I went to write some macros, but that was more me not reading the docs closely enough. I'd say I am very productive in it now and I don't view any of Rust's features as being a productivity problem.
If you're struggling with Rust, I'd say keep going until you get that "click."
C++ is somewhat of a low bar, because of the state of the art in package management in C++ land is "download a header-only library". C++ does have sum types in the form of boost::variant, but boost is an abomination.
The danger to Rust is that for many projects it wins by default because the alternative languages are immature, rather than because its performance/security capabilities are actually worth the productivity trade-off compared to other languages.
Once Swift matures a bit, it will take a lot of the lustre from Rust.
Productivity is certainly very high in go compared to rust; however, I've found that confidence about how the code executes is much easier to acquire in rust if it compiles.
Regarding the type system, it's definitely a sharp learning curve; there are certain patterns that are trivial in C++ that I still don't quite understand how to best translate. I suspect non-lexically-bound lifetimes will help a lot here iff they are viable.
However, debugging is a complete breeze compared to C++ because of a) the borrow tracker and b) the errors are much more readable because of a general lack of template soup.
> there is no compiler warning when you mix up traits coming from different versions of a crate. You just get impossible-seeming errors.
There is a check when error messages are generated to detect messages like "expected X, got X" and add a warning that you might be mixing different versions of the same crate.
There are probably some cases that slip through, but if you file an issue with your specific example or look into the compiler yourself, you might get it fixed (my one patch in rustc handles "a::b::X" being reexported and accessed as "a::X").
> This is more of a missing feature, but type inference is a huge part of Rust, and it's often difficult to know what type the type inference engine has chosen for parts of your code. There's no way to find out using RLS in VSCode that I've seen, or go to the definition of inferred types, etc.
VS Code has a 'code lens' feature that allows extensions to display annotations above each lines of code - you can see it in action if you install e.g. the Git Blame extension.
Some language plugins use that feature to display inferred types; the Rust plugin could do the same.
the plugin seems to do it sometimes. definitely a useful feature when learning. can do codelens too so you don't have yo hover. would be a nice option.
Some of the issues I've found:
* Code completion sometimes simply fails to work. For example, inside future handlers (probably because this involves a lot of type inference).
* When errors are detected only the first line of the compiler error message is accessible in the UI, often omitting critical information and making it impossible to diagnose the problem.
* It is often necessary to manually restart RLS, for example when your cargo.toml changes. It can take a very long time to restart if things need to be recompiled and there isn't much in the way of progress indication.
* This is more of a missing feature, but type inference is a huge part of Rust, and it's often difficult to know what type the type inference engine has chosen for parts of your code. There's no way to find out using RLS in VSCode that I've seen, or go to the definition of inferred types, etc.
Other issues I've seen as a newcomer to Rust:
* It's very easy to get multiple versions of the same dependency in your project by accident (when your dependencies have dependencies), and there is no compiler warning when you mix up traits coming from different versions of a crate. You just get impossible-seeming errors.
* Compiler speed is a big problem.
* The derive syntax is super clunky for such an essential part of the language. I think Rust guides should emphasize derive more, as it's unclear at first how essential it really is. Almost all of my types derive multiple traits.
* In general, Rust is hard. It requires a lot more thinking than e.g. Python or even C. As a result, my forward progress is much slower. The problems I have while coding in Rust don't even exist in other languages. I'm sure this will improve over time but I'm not sure it will ever get to the point where I feel as productive as I do in other languages.