Hacker News Reader

> 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.

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.

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.

I'd say it worked similarly for me.

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."

I cannot say the same due to lack of support for GUI toolkits, the way the borrow checker handles callbacks, or mixed debugging support.

You can get sum types in C++17 and with boost::variant in early versions.

That's fair, the ecosystem certainly isn't ready for every use case.

What specifically do you mean by "the way the borrow checker handles callbacks"?

It is described in the Non-lexical lifetimes RFC under "Closure desugaring".

https://github.com/nikomatsakis/nll-rfc/blob/master/0000-non...

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.

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.

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.)

C# and Rust are a wicked combo. The fact that you can pass delegates as fn pointers down to Rust is freaking sweet from an FFI perspective.

Do you have any pointers to projects doing this?

I'm very interested in rust and a C# guy during the day. A decent, as in 'serious', example showing rust integration would be quite appreciated.

Nothing public unfortunately.

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.

> I'm definitely spending a lot more time wrestling with the type system than I ever spent debugging memory errors in C.

There is no way you can reliably make this claim. It smacks of rosy retrospection bias.

Running `cargo tree -d` helps with checking if you have multiple versions of a dependency and where they come from.

You can install it with `cargo install cargo-tree`

> 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").

> I have been using this for a few weeks

> In general, Rust is hard

It's only in first weeks. Soon you will use borrow checker and lifetimes rules without any thinking, you will just do it automatically.

> 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.

With TS/JS, it will show this when you hover the cursor over the variable (or invoke it with a keyboard shortcut)

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.