Like Tree31Likes

Let's talk about Rust!

This is a discussion on Let's talk about Rust! within the General Discussions forums, part of the Community Boards category; Program correctness is as much an afterthought in C as the correct use of the language is in English. The ...

  1. #91
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,467
    Program correctness is as much an afterthought in C as the correct use of the language is in English. The rules are there, the semantics, as is a whole generation of books educating programmers in the correct use of the language. Rust will offer the exact same challenges and will be crowded by the exact same insufferable programmers for whom program correctness is an afterthought.

    Your problem with the C programming language, Neo, is one of false attribution. Direct your batteries to your fellow programmers instead, and you'll quickly realize we've been blessed not with one, or two, or three, but a large number of excellent application/system programming languages.

    (Pepe annoyed me very much today. The Portuguese humiliating loss at the WC. Going to watch Ghana-USA now. Go Team Africa! Sorry fellow Americans.)
    Last edited by Mario F.; 06-16-2014 at 04:04 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #92
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    Quote Originally Posted by Elysia View Post
    Name a few of these improvements that Rust brings which C++11 cannot imitate.
    Name a few improvements that C++ brings which assembly cannot imitate.

    But in all seriousness, he already has.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  3. #93
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Quote Originally Posted by Yarin View Post
    But in all seriousness, he already has.
    Named some points, yes, which have been shot down already. Neo speaks as if these are absolute improvements, not just in his/her opinion. Therefore, I seek some of these "other improvements" that C++11 cannot imitate in any easy way that are significant enough to warrant attention.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #94
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    Quote Originally Posted by Elysia View Post
    Named some points, yes, which have been shot down already. Neo speaks as if these are absolute improvements, not just in his/her opinion. Therefore, I seek some of these "other improvements" that C++11 cannot imitate in any easy way that are significant enough to warrant attention.
    If by "shot down" you mean simply ignored (Elkvis did try, but he didn't quite understand).... Right out of the gates:
    Quote Originally Posted by Neo1 View Post
    The unique_ptrs and shared_ptrs of Rust are part of the core language, rather than part of the standard library. This means Rust can give some compile-time guarantees about leaks and dangling pointers.
    That's a big deal, you can't imitate that in C++.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  5. #95
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Quote Originally Posted by Yarin View Post
    That's a big deal, you can't imitate that in C++.
    Not good enough. Nice to have, but ultimately, in big systems, I imagine it won't mean so much. While C++ cannot fully imitate this, it comes close enough.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #96
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,074
    Not gonna lie, compile-time guarantees about leaks and dangling pointers is pretty sweet. Maybe Rust is worth checking out. It's like C++ and functional programming had a baby.

  7. #97
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,606
    Sweet it may be, but it is limited to where the compiler can prove it's wrong. If it cannot prove it is wrong, it is not going to give you a compile error. So it may be nice for newbies and small projects, but for larger ones, I hardly think it will matter.
    Mario F. likes this.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #98
    Registered User
    Join Date
    Jun 2005
    Posts
    6,298
    Quote Originally Posted by Elysia View Post
    Sweet it may be, but it is limited to where the compiler can prove it's wrong. If it cannot prove it is wrong, it is not going to give you a compile error. So it may be nice for newbies and small projects, but for larger ones, I hardly think it will matter.
    Indeed.

    The only way to be sure all possible leaks and dangling pointers are detected without running it is to do a complete static analysis of the program and any library functions or (exploit knowledge of) compiler built-ins the program uses, and verify that all possible program states are in valid ranges.

    Whole-of-program static analysis is difficult - and the reason that programs which do comprehensive static analysis are often VERY expensive, are rarely used on small programs, and novices very rarely get to use them.

    Even primitive forms of static analysis are quite time consuming, because of the number of dependencies of state that can arise between functions that call (or are called by) each other - and because a program that can accept inputs (from user, from files, from whatever) has many more possible states. There are ways and means of simplifying static analysis (for example, annotations of preconditions and post conditions of functions, so the analyser doesn't have to drill down and analyse the source of every called function) but it is hardly trivial.

    Built-in reference-counted smart pointers can help, but they're hardly a panacea. They're also not the only available option - there is nothing stopping a compiler vendor building in knowledge of the standard library into a compiler (there are several compilers, for a range of languages including C and C++, which exploit knowledge of the standard library to improve diagnostics or to optimise performance).
    Right 98% of the time, and don't care about the other 3%.

  9. #99
    Registered User
    Join Date
    Jun 2014
    Posts
    3
    The only way to be sure all possible leaks and dangling pointers are detected without running it is to do a complete static analysis of the program and any library functions or (exploit knowledge of) compiler built-ins the program uses, and verify that all possible program states are in valid ranges.
    Rust doesn't guarantee to prevent memory leaks (although I find it generally makes them harder to create), but it can absolutely guarantee at compile time that you don't have dangling pointers, without needing to use any complex whole-program static analysis. This is true no matter the size of the program, and doesn't require use of smart pointers - it's enforced by the way the language is constructed. The only place you can cause dangling pointers is in unsafe blocks, which deactivate a lot of safety restrictions and give you more flexibility. In typical rust code such blocks are uncommon, and if you do experience an issue with respect to memory safety, the places you need to audit are clearly marked.

    Just to clear up some misconceptions in this thread:

    - Rust's unique pointers are a compile-time construction only. They have zero run time overhead.
    - Rust's reference counted pointers are thread-local, and thus don't require atomic operations. They're quite cheap as a result. They're also not used all that commonly in typical rust code.
    - Rust has changed enormously over the past year or two. Don't believe anything much about the language that wasn't written in the last 6 months :-).

    Probably the biggest contribution of rust is the borrow checker. This allows you to safely pass unique pointers into other functions (for example) without moving the value - rust will statically guarantee that the lifetime of the 'borrowed' value is less than the lifetime of the owning pointer. Of course in C++ you can pass the raw value in, but that's not guaranteed to be safe. Likewise, you can also borrow ref-counted objects safely, without having to increment the reference count.

    Another useful fallout of the way rust is constructed is that the compiler knows an awful lot about aliasability of data. In the future the compiler will make a lot more use of that to improve performance.

  10. #100
    Registered User
    Join Date
    Jun 2014
    Posts
    3
    It looks like there's some confusion in this thread regarding the features of Rust.

    1. Rust does not have built-in reference-counting. Nor does it use garbage collection at all, or any other form of dynamic memory management.
    2. Rust guarantees memory safety at compile time, without imposing any runtime overhead whatsoever (this blew my mind when I realized that such a thing was possible). It does this by restricting the ownership of data (think of everything as being automatically marked with `const restrict`, and the compiler guaranteeing that this is correct). It has move semantics by default, and requires explicit action if you want to clone something.
    3. References in Rust are first-class, and you can safely store references in data structures. If you mess up, the compiler is guaranteed to yell at you. Here's a good talk discussing how this works: https://air.mozilla.org/guaranteeing...afety-in-rust/
    4. Because of all the ownership tracking that the compiler does, Rust code is guaranteed to contain no data races. That's not to say that race conditions in general are impossible, just data races. This is a pretty great feature for multithreaded programs.
    5. None of this static analysis is expensive.
    6. Rust doesn't require a runtime, and Rust code can expose a C-compatible interface. This means that you can write a library in Rust that can be called from any language that can call into C.


    So Rust is not a silver bullet. Even though the memory management is both perfectly safe and "free" in terms of performance, it requires thinking hard about ownership of data and thus is not "free" in terms of programmer productivity. It's only intended to replace C++ for security-critical applications (such as web browsers, which is why Mozilla is backing the project), though I'm sure other people will value not having to ever deal with segfaults/null pointer dereferences/use-after-free/dangling pointers/iterator invalidation/etc.

    The reason why a new language is warranted here is because C++ can't guarantee memory safety without breaking backwards compatibility with all existing C++ code. C++11/14 are doing great jobs of evolving the language towards safety, but it's still only a shadow of what you can do with a language designed around safety from the ground up.
    Last edited by kibwen; 06-18-2014 at 09:28 AM.
    stahta01 likes this.

  11. #101
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,260
    O_o

    Two new posters registering within a few hours of each other making the same points in the same thread about a language that is neither C nor C++ on a board with C in the name?

    Call me crazy, but I don't believe that is in any way kosher.

    Soma
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  12. #102
    Registered User
    Join Date
    Jun 2014
    Posts
    3
    Shrug. When I see misinformation, I prefer to correct it. It's a bit silly that this discussion went on for seven pages without anyone actually bothering to look at Rust at all, or understanding the problems that it's attempting to solve.

  13. #103
    Registered User
    Join Date
    Jun 2014
    Posts
    3
    Quote Originally Posted by phantomotap View Post
    O_o

    Two new posters registering within a few hours of each other making the same points in the same thread about a language that is neither C nor C++ on a board with C in the name?

    Call me crazy, but I don't believe that is in any way kosher.

    Soma
    No offense was intended - I don't mean to denigrate C++ or troll - I just got linked here from elsewhere and thought I'd try to clear up some confusion in the thread.

  14. #104
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,727
    This is supposed to be a discussion, not an election or popularity contest, so sockpuppets do not matter as long as they are well behaved since it is a matter of the strength of points raised, not the number of votes cast. Given that the email addresses of AlisdairO and kibwen are separate (not say, easily manufactured gmail aliases), and the IP addresses recorded are different (means almost nothing, of course, but sockpuppet masters do make mistakes), I would give the benefit of the doubt that no one here was so desperate as to create new email accounts simply to try and add supportive voices to the discussion.

    Quote Originally Posted by AlisdairO
    I just got linked here from elsewhere
    Where might that be? A link might be good.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #105
    Registered User
    Join Date
    Jun 2014
    Posts
    1
    Quote Originally Posted by laserlight View Post
    Where might that be? A link might be good.
    Let's talk about Rust! : rust

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Do I talk too much?
    By GoodStuff in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 05-20-2003, 10:45 PM
  2. Who wants to talk on AIM?
    By Death Wish in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 07-05-2002, 06:29 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21