5 ms·

I'm a functional programmer (Lisp, OCaml, Erlang), and I only touch C++ when I have to wrap it in something to interface with a higher-level language. Most of

I'm a functional programmer (Lisp, OCaml, Erlang), and I only touch C++ when I have to wrap it in something to interface with a higher-level language. Most of the cases where I run into this problem and end up feeling like I didn't gain much, if anything, from doing a straight C implementation are situations with deeply nested data structures. I get that the thinking is that the benefit is that once I've made the compiler stop complaining, my memory management model should at least be sound and safe, and that is a win. Though immediately following that I start to have dream-like fantasies where this entire static analysis stage is simply bolted onto C instead of being a whole new language. Afterall you can do some pretty impressive stuff with nothing but a pile of preprocessor macros (see Objective C).

Manishearth 11y ago
Functional idioms don't translate cleanly either :) If you're using Rust for FFI from functional languages (or any language, really) you need to use a fair amount of unsafe code to get the interface correctly. There's not much benefit for simple things (aside from cases like these: https://gist.github.com/steveklabnik/1a3ec0ca676aaddf766e https://gist.github.com/steveklabnik/1a3ec0ca676aaddf766e), but for more complex things it works out pretty nicely.
pcwalton 11y ago
> Most of the cases where I run into this problem and end up feeling like I didn't gain much, if anything, from doing a straight C implementation are situations with deeply nested data structures. Your feeling doesn't line up with what has been observed in practice. Empirically, people do not get the memory management right in C. They mess up, again and again and again. In Rust, however, the compiler enforces that you get it right. > Though immediately following that I start to have dream-like fantasies where this entire static analysis stage is simply bolted onto C instead of being a whole new language. I don't think it's really possible to bolt Rust's semantics onto C. Too much will break: in particular C code is not written with inherited mutability, which is critical to Rust. You could maybe do something like the proposed lifetime stuff in C++, which still requires lots of annotation, enough to effectively be a whole new language. Rust has a lot better ergonomics anyway. > Afterall you can do some pretty impressive stuff with nothing but a pile of preprocessor macros (see Objective C). Objective-C isn't "a pile of preprocessor macros", and it would be completely impossible to implement the lifetime system using the preprocessor.
- dave_ops 11y ago
  The first versions of Objective-C were most definitely implemented as pre-processors to C compilation.
  - pcwalton 11y ago
    That's not the same as using the C preprocessor to implement the language.
    - aabshar 11y ago
      test
jbandela1 11y ago
At this year's CppCon Herb Sutter the chair of the ISO C++ committee addressed just this issue of lifetime safety. Here is a video of his talk and includes a demo of the upcoming static analysis tool that can do this with very minimal annotations https://m.youtube.com/watch?v=hEx5DNLWGgA https://m.youtube.com/watch?v=hEx5DNLWGgA I remember thinking when watching the talk that this was a very bad day for Rust as C++ could now do most of what Rust was promising
- pcwalton 11y ago
  The lifetime stuff in C++ is full of annotations, with effectively just as many required as Rust. I think of it effectively as a separate language. It's also significantly more complex, with points-to analysis instead of inherited mutability, and the restrictions on pointer aliasing on function entry seem very restrictive compared to what RefCell provides. I think that Rust's system has proven itself to be about as simple and easy to use as you can get in this space. I also think that you cannot just "bolt on" a lifetime system to an existing language that was not designed for it without large amounts of annotation, modification of existing code, and additional learning curve.
  - pjmlp 11y ago
    The danger here to Rust is the usual "worse is better". OS vendors will happily just add GSL and static analysis driven support to C++, with Rust becoming the language that drove them to do that and that is it. Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. They might lack full Rust like safety, but they are a good enough incremental approach to safety, come with integration with their existing tools and libraries. Which leaves Rust adoption for systems programming to other OS vendors, e.g. embedded space or open source OSes. Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.
    - pcwalton 11y ago
      > Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. Swift at least isn't in the same space as Rust. It's a fully garbage-collected language. > Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role. And Rust has the most memory-safe low-level systems code available today. It also has Cargo and crates.io, which allow that code to be easily reused. By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.

Manishearth 11y ago

Functional idioms don't translate cleanly either :) If you're using Rust for FFI from functional languages (or any language, really) you need to use a fair amount of unsafe code to get the interface correctly. There's not much benefit for simple things (aside from cases like these: https://gist.github.com/steveklabnik/1a3ec0ca676aaddf766e https://gist.github.com/steveklabnik/1a3ec0ca676aaddf766e), but for more complex things it works out pretty nicely.

pcwalton 11y ago

> Most of the cases where I run into this problem and end up feeling like I didn't gain much, if anything, from doing a straight C implementation are situations with deeply nested data structures. Your feeling doesn't line up with what has been observed in practice. Empirically, people do not get the memory management right in C. They mess up, again and again and again. In Rust, however, the compiler enforces that you get it right. > Though immediately following that I start to have dream-like fantasies where this entire static analysis stage is simply bolted onto C instead of being a whole new language. I don't think it's really possible to bolt Rust's semantics onto C. Too much will break: in particular C code is not written with inherited mutability, which is critical to Rust. You could maybe do something like the proposed lifetime stuff in C++, which still requires lots of annotation, enough to effectively be a whole new language. Rust has a lot better ergonomics anyway. > Afterall you can do some pretty impressive stuff with nothing but a pile of preprocessor macros (see Objective C). Objective-C isn't "a pile of preprocessor macros", and it would be completely impossible to implement the lifetime system using the preprocessor.

dave_ops 11y ago
The first versions of Objective-C were most definitely implemented as pre-processors to C compilation.
- pcwalton 11y ago
  That's not the same as using the C preprocessor to implement the language.
  - aabshar 11y ago
    test

jbandela1 11y ago

At this year's CppCon Herb Sutter the chair of the ISO C++ committee addressed just this issue of lifetime safety. Here is a video of his talk and includes a demo of the upcoming static analysis tool that can do this with very minimal annotations https://m.youtube.com/watch?v=hEx5DNLWGgA https://m.youtube.com/watch?v=hEx5DNLWGgA I remember thinking when watching the talk that this was a very bad day for Rust as C++ could now do most of what Rust was promising

pcwalton 11y ago
The lifetime stuff in C++ is full of annotations, with effectively just as many required as Rust. I think of it effectively as a separate language. It's also significantly more complex, with points-to analysis instead of inherited mutability, and the restrictions on pointer aliasing on function entry seem very restrictive compared to what RefCell provides. I think that Rust's system has proven itself to be about as simple and easy to use as you can get in this space. I also think that you cannot just "bolt on" a lifetime system to an existing language that was not designed for it without large amounts of annotation, modification of existing code, and additional learning curve.
- pjmlp 11y ago
  The danger here to Rust is the usual "worse is better". OS vendors will happily just add GSL and static analysis driven support to C++, with Rust becoming the language that drove them to do that and that is it. Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. They might lack full Rust like safety, but they are a good enough incremental approach to safety, come with integration with their existing tools and libraries. Which leaves Rust adoption for systems programming to other OS vendors, e.g. embedded space or open source OSes. Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role.
  - pcwalton 11y ago
    > Microsoft (GSL + static analysis, C++/CX, System C#, .NET Native) and Apple (Swift) are already working on what might be their next systems programming language. Swift at least isn't in the same space as Rust. It's a fully garbage-collected language. > Remember, languages are a tiny portion of the whole eco-system. Tools, libraries and community play a bigger role. And Rust has the most memory-safe low-level systems code available today. It also has Cargo and crates.io, which allow that code to be easily reused. By contrast, existing C++ code isn't safe C++ code. It will have to be ported, often by drastically altering the idioms in use, and that takes a lot of time.