6 ms·

> 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

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

modeless 9y ago
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.
- Rusky 9y ago
  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.
  - srssays 9y ago
    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.
  - Amezarak 9y ago
    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."
  - pjmlp 9y ago
    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.
    - Rusky 9y ago
      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"?
      - pjmlp 9y ago
        It is described in the Non-lexical lifetimes RFC under "Closure desugaring". https://github.com/nikomatsakis/nll-rfc/blob/master/0000-nonlexical-lifetimes.md 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.
- dgfgfdagasdfgfa 9y ago
  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.
- MaulingMonkey 9y ago
  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.)
  - vvanders 9y ago
    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.
    - darklajid 9y ago
      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.
      - vvanders 9y ago
        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.
- chii 9y ago
  > ... 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.
- naasking 9y ago
  > 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.

modeless 9y ago

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.

Rusky 9y ago
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.
- srssays 9y ago
  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.
- Amezarak 9y ago
  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."
- pjmlp 9y ago
  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.
  - Rusky 9y ago
    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"?
    - pjmlp 9y ago
      It is described in the Non-lexical lifetimes RFC under "Closure desugaring". https://github.com/nikomatsakis/nll-rfc/blob/master/0000-nonlexical-lifetimes.md 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.
dgfgfdagasdfgfa 9y ago
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.
MaulingMonkey 9y ago
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.)
- vvanders 9y ago
  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.
  - darklajid 9y ago
    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.
    - vvanders 9y ago
      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.
chii 9y ago
> ... 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.
naasking 9y ago
> 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.