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; Surprised anyone hasn't brought up this exciting new language on CBoard yet! The Rust Programming Language While it is still ...

  1. #1
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964

    Let's talk about Rust!

    Surprised anyone hasn't brought up this exciting new language on CBoard yet!

    The Rust Programming Language

    While it is still very much at the pre-alpha stage, it is being hyped as the new C replacement all across the tubes.

    Someone has already started work on porting the GNU coreutils to Rust:

    https://github.com/uutils/coreutils

    ...under the MIT license no less

    Functional goodies like pattern matching, algebraic data types combined with guaranteed memory safety and a sensible ABI. What's not to like?
    Last edited by Neo1; 06-12-2014 at 06:16 PM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  2. #2
    Registered User Alpo's Avatar
    Join Date
    Apr 2014
    Posts
    495
    Does "crate" come from another language, or is it unique?

  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,539
    Quote Originally Posted by Neo1 View Post
    guaranteed memory safety
    ...and as an inescapable consequence, guaranteed reduced performance.

    The idea that this could replace a language that's been used to great success for more than 40 years seems a little far-fetched. It's interesting, to be sure. Coming from a C/C++/C# background, it's a little bit of a learning curve, but in a few ways, it resembles go. I think it's a great idea to try to shake up the programming world from time to time, but the barrier to entry is just so incredibly unforgiving, that I doubt that it will gain much of a foothold. I honestly hope to be proven wrong.
    Sebastiani likes this.
    Code:
    namespace life
    {
        const bool change = true;
    }

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

    I've seen the "new C replacement" more times than I could count.

    As long as C evolves, I don't see that actually happening anytime in the next forty-five years.

    Soma
    Sebastiani, Epy and Elkvis like this.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    ...Do we really need this? Why is this better than C/C++/[insert your language here]?
    I'd rather people spend time and energy in improving existing languages than creating new ones...
    Returning pointer to a local variable? Most compilers warn on that.
    Communicating between threads? Only need a good library addition for that to work reliably. No need for a new language!
    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. #6
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,751
    Needing a language is mostly knowing how to write its code, knowing it can do the job, and it being available for you to use on platform XYZ. Thus, I've never thought languages had to be "needed," but some inventions definitely want something to be true. Killing C is like killing Batman; the entire rogues gallery wants to do it. There are even fanboy languages that want to improve other languages, too.
    Last edited by whiteflags; 06-13-2014 at 07:26 AM.

  7. #7
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elkvis View Post
    ...and as an inescapable consequence, guaranteed reduced performance.
    True, the way Rust manages memory is with reference counted smart pointers, like C++. So if C++ with smart pointers is fast enough for some task, then Rust will be too (Once the compiler is more mature and can optimize as well as modern C++ compilers do now).

    Obviously this will be slower than the raw pointers of C, but Rust retains the level of control that C provides.

    Quote Originally Posted by Elysia
    ...Do we really need this? Why is this better than C/C++/[insert your language here]?
    Well, of the top of my head:
    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.
    Many of the more eccentric properties of C++ are not present in Rust, for starters, it actually has a standard ABI.
    All variables are immutable by default.
    All strings are encoded as UTF8, a minor but delicious property IMO!
    Better type-safety, there is no implicit casting of built-in types and you cannot 'downcast' a pointer from a general type to a specific type like in C/C++.

    I'd rather people spend time and energy in improving existing languages than creating new ones...
    Forgive me, but this smells a bit like something an old and dusty C++ programmer would say. We'd still be using FORTRAN if this was the prevalent frame of mind.

    Returning pointer to a local variable? Most compilers warn on that.
    Well, the memory safety guarantees that they boast about goes a little beyond just returning pointers to local memory ;-)

    Communicating between threads? Only need a good library addition for that to work reliably. No need for a new language!
    Errr, if this was true then race conditions wouldn't be a problem would it? Just some good library additions and then that is fixed.

    Well concurrency and race conditions are huge problems and they are problems that C++ and other existing systems programming languages have failed to address.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  8. #8
    Registered User
    Join Date
    Oct 2006
    Posts
    2,539
    Quote Originally Posted by Neo1 View Post
    True, the way Rust manages memory is with reference counted smart pointers, like C++. So if C++ with smart pointers is fast enough for some task, then Rust will be too (Once the compiler is more mature and can optimize as well as modern C++ compilers do now).
    Obviously this will be slower than the raw pointers of C, but Rust retains the level of control that C provides.
    I think with optimizations enabled, the get(), operator* and operator-> are likely to be inlined, so they become as fast as raw pointers.

    Well, of the top of my head:
    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.
    This may be helpful, but it does introduce some overhead, no matter how efficient you try to make it.

    Many of the more eccentric properties of C++ are not present in Rust, for starters, it actually has a standard ABI.
    This is a relatively small concern. Plenty of languages have a standard ABI. It doesn't make them great languages.

    All variables are immutable by default.
    I fail to understand how this is a good thing. How do you modify a variable passed by reference?

    All strings are encoded as UTF8, a minor but delicious property IMO!
    This is a plus, given the ever-shrinking world in which we live.

    Better type-safety, there is no implicit casting of built-in types
    I'd consider that a bad thing. No automatic promotion of int to long? No conversion of any pointer to void*? This seems like a recipe for programmer headaches.

    you cannot 'downcast' a pointer from a general type to a specific type like in C/C++.
    Never? I realize that using RTTI and dynamic_cast can be a sign of poorly-designed code, but sometimes it is actually necessary, and if there's no mechanism to achieve that, then this language is clearly deficient.

    Forgive me, but this smells a bit like something an old and dusty C++ programmer would say. We'd still be using FORTRAN if this was the prevalent frame of mind.
    No need to start hurling insults. C++ has gotten much better with the last update (C++11), and promises to improve even more with the next minor update. This is akin to saying "the first automobile was slow, noisy, and inefficient, so let's stop making cars, and make something else."

    Errr, if this was true then race conditions wouldn't be a problem would it? Just some good library additions and then that is fixed.
    Every system that supports concurrency has the potential for race conditions. It is a rather immutable law of concurrent programming.

    Well concurrency and race conditions are huge problems and they are problems that C++ and other existing systems programming languages have failed to address.
    C++ has made progress in this area. They added tons of thread support features in C++11. No language feature or library can completely prevent race conditions. The programmer is still responsible for writing code that behaves as expected.
    Code:
    namespace life
    {
        const bool change = true;
    }

  9. #9
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elkvis View Post
    I think with optimizations enabled, the get(), operator* and operator-> are likely to be inlined, so they become as fast as raw pointers.
    Yet somehow the same is not possible with the Rust smart pointers?

    This may be helpful, but it does introduce some overhead, no matter how efficient you try to make it.
    How so? If it is handled at compile-time then it wouldn't need to be checked at runtime.

    This is a relatively small concern. Plenty of languages have a standard ABI. It doesn't make them great languages.
    Having a standard ABI doesn't make a language great, not having a standard ABI certainly doesn't either. Which is prefferable?

    I fail to understand how this is a good thing. How do you modify a variable passed by reference?
    Immutability is a cornerstone of the functional programming philosophy.
    Immutable objects are simpler to reason about since you can make assumptions about variables and parameters that could not otherwise be made.
    Immutable objects are inherently thread-safe.
    They can result in a reduction of memory usage since identical values can reference the same piece of memory. Copying also becomes a simple matter of copying a reference/pointer.

    If a variable needs to be changed it has to be declared mutable, in Rust passing it by reference implies transfering ownership of the variable from the caller to the callee. That's my impression of how it works, i'm no good at Rust yet (and i'm not going to be until the language is in a stable state) so i might be wrong.

    I'd consider that a bad thing. No automatic promotion of int to long? No conversion of any pointer to void*? This seems like a recipe for programmer headaches. [....] Never? I realize that using RTTI and dynamic_cast can be a sign of poorly-designed code, but sometimes it is actually necessary, and if there's no mechanism to achieve that, then this language is clearly deficient.
    As you say, sometimes doing these unsafe things are necessary. In Rust you can wrap any piece of code in an 'unsafe' block, which pretty much turns the language into plain C in the sense that you can do whatever you like, but you'd better be sure you know what you're doing.

    No need to start hurling insults. C++ has gotten much better with the last update (C++11), and promises to improve even more with the next minor update. This is akin to saying "the first automobile was slow, noisy, and inefficient, so let's stop making cars, and make something else."
    On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.

    Every system that supports concurrency has the potential for race conditions. It is a rather immutable law of concurrent programming.
    Thats fine, but then some systems are more prone to race conditions than others and i think C is one of the worst languages in this regard.

    C++ has made progress in this area. They added tons of thread support features in C++11. No language feature or library can completely prevent race conditions. The programmer is still responsible for writing code that behaves as expected.
    Hey, i'm not the one that made the argument that this is a non-issue.
    Last edited by Neo1; 06-13-2014 at 08:40 AM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  10. #10
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,359
    Forgive me, but this smells a bit like something an old and dusty C++ programmer would say. We'd still be using FORTRAN if this was the prevalent frame of mind.
    O_o

    1): Did you really expect to come to a C/C++ board talking about the "replacement" of C without someone defending C/C++? If so, you are a very naive. If not, the comment is purposefully trolling.

    [Edit]
    Sorry. The next comment seems as if I am trying to insult. I am not. My intent was to draw your attention to the way you're proselytizing.
    [/Edit]

    2): Trolling or simple Naiveté, the "part of the core language" comments reek of every other yahoo who parades a new language.

    3): The features bound to a standard, library or "core language", is part of the language. A complex feature is difficult to implement correctly regardless of where that feature lives. The "whizzy" features of Rust may be great, but "whizzy" features will not see as significant as adoption if more difficult to implement. The more readily shared implementations of libraries built on "lower level" features is a good thing. (I'd much prefer library only additions to C/C++. You can easily shunt a library, but you can't readily extend a compiler if the feature has an entirely different grammar.)You can even see that exact scenario play out in Rust; look at the thoughts related to "unsafe". If "unsafe" did not exist, the language would not be as readily capable of "self hosting".

    4): We, as in C/C++ programmers, may indeed have still been using FORTRAN. The flavor of FORTRAN we would be using would be truly amazing with sixty years of wide adoption and incremental improvements. Fortran has evolved, but people using Fortran are the ones who push evolution. The "fandom" of Fortran simply don't want the kind of features you are discussing.

    Elysia is the one making the argument that we already have something that works, so why bother improving upon it.
    The comment ,though, is definitely trolling. Elysia simply wants to put effort improving the existing models.

    Soma
    Last edited by phantomotap; 06-13-2014 at 08:48 AM.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  11. #11
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    Quote Originally Posted by Neo1 View Post
    Well, of the top of my head:
    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.
    Many of the more eccentric properties of C++ are not present in Rust, for starters, it actually has a standard ABI.
    All variables are immutable by default.
    All strings are encoded as UTF8, a minor but delicious property IMO!
    Better type-safety, there is no implicit casting of built-in types and you cannot 'downcast' a pointer from a general type to a specific type like in C/C++.
    I like how "smart pointers" are a language feature, but the question is still how much more they will detect than std::shared_ptr/std::unique_ptr.
    ABI is a problem, true, but hopefully the standard committee will fix that in the coming years. There are already proposals around that.
    The rest is nice, but again, is it worth another language for it? You can use UTF8 by default in C++ by encoding all string literals properly. You can use const on all variables.

    Forgive me, but this smells a bit like something an old and dusty C++ programmer would say. We'd still be using FORTRAN if this was the prevalent frame of mind.
    *shrug* I'm all for better languages, but if history tells us anything, it's that newer languages are not always better. It really has to prove itself by adding things that just cannot be added to existing languages.

    Errr, if this was true then race conditions wouldn't be a problem would it? Just some good library additions and then that is fixed.

    Well concurrency and race conditions are huge problems and they are problems that C++ and other existing systems programming languages have failed to address.
    All I see is that they're proposing a library addition that lets threads communicate with each other via messaging. Hardly ground breaking. The same thing can be emulated in other languages with a simple library add-on. I don't see this "fixing" anything, less being ground-breaking improvements.
    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.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    Quote Originally Posted by Neo1 View Post
    On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.
    My point is:
    Instead of reinventing the wheel to make The Wheel 2.0, why not improve the existing wheel? The foundation is already there. It has been tested and used by thousands and thousands over people over many, many years. Its quirks are well known. Its limitations are well known. Its advantages are well known. Compare that to the "new" wheel. How long before we know its limitations, advantages and disadvantages? How long before it becomes "fixed" to the point where it works for most?
    Never did I say to stop improving something. I want C++ to keep improving. I don't want it to stop.

    I realize that sometimes the foundation is sometimes fundamentally broken and all you can do it patch it to keep it working (*cough* Internet *cough*). However, I do not think C++ is broken in such a way, and I do not see Rust as improving upon any of the broken fundamentals in C++ which cannot be patched in later.
    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.

  13. #13
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by phantomotap View Post
    O_o

    1): Did you really expect to come to a C/C++ board talking about the "replacement" of C without someone defending C/C++? If so, you are a very naive. If not, the comment is purposefully trolling.
    No, but i _did_ expect a reasonable awareness of the weaknesses of C/C++. I don't think that is what i got.

    The comment ,though, is definitely trolling. Elysia simply wants to put effort improving the existing models.
    Improving existing languages is fine by me, Elysia suggested that it is strictly a better thing than trying to come up with new languages, which i don't agree with at all.

    Besides, "improving" C++ has become synonymous with simply expanding an already humongous language.

    2): Trolling or simple Naiveté, the "part of the core language" comments reek of every other yahoo who parades a new language.
    Call it what you want, the fact that dereferencing a std::unique_ptr whose value has moved causes a runtime error in C++, while doing the same in Rust causes a compilation error is not insignificant in the least. I'll gladly be called a yahoo if it means i no longer have to deal with such runtime errors!

    3): The features bound to a standard, library or "core language", is part of the language. A complex feature is difficult to implement correctly regardless of where that feature lives. The "whizzy" features of Rust may be great, but "whizzy" features will not see as significant as adoption if more difficult to implement. The more readily shared implementations of libraries built on "lower level" features is a good thing. (I'd much prefer library only additions to C/C++. You can easily shunt a library, but you can't readily extend a compiler if the feature has an entirely different grammar.)You can even see that exact scenario play out in Rust; look at the thoughts related to "unsafe". If "unsafe" did not exist, the language would not be as readily capable of "self hosting".
    I'm not quite sure i follow you here, could you reword or expand upon this?

    Edit:

    Quote Originally Posted by Elysia
    I realize that sometimes the foundation is sometimes fundamentally broken and all you can do it patch it to keep it working (*cough* Internet *cough*). However, I do not think C++ is broken in such a way, and I do not see Rust as improving upon any of the broken fundamentals in C++ which cannot be patched in later.
    Patching it to keep it working is exactly what is happening to C++. There is now two ways of writing C++ code: The wrong way, using C-style pointers, arrays and pretty much C-style everything and then there is the right way which is to use proper RAII, smart pointers and so on. The way i see it, Rust is C++ without the 'wrong way', a lot of functional programming concepts mixed in and with better syntax.
    Last edited by Neo1; 06-13-2014 at 09:03 AM.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  14. #14
    Registered User
    Join Date
    Oct 2006
    Posts
    2,539
    Quote Originally Posted by Neo1 View Post
    Yet somehow the same is not possible with the Rust smart pointers?
    How so? If it is handled at compile-time then it wouldn't need to be checked at runtime.
    There still needs to be some run-time checking. If they guarantee pointer safety, then they have to check for valid pointers on every access.

    ...but you'd better be sure you know what you're doing.
    No different from C and C++, or any other language, for that matter.

    On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.
    My point was that C++ has improved greatly, because it has been improved over the years, and because people didn't just give up on it. If everyone listened to people like Linus Torvalds, there would be no C++. The first version of anything is always going to be a little rough. You can't just abandon it because it doesn't perfectly suit your needs when it's first created. I like the idea of new languages. They can help to steer the older languages in the direction that the world is heading, but it doesn't mean we have to give up the old ones too.

    Thats fine, but then some systems are more prone to race conditions than others and i think C is one of the worst languages in this regard.
    I'll definitely agree with you on C. It has practically no safety at all.
    Last edited by Elkvis; 06-13-2014 at 09:08 AM.
    Code:
    namespace life
    {
        const bool change = true;
    }

  15. #15
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    Quote Originally Posted by Neo1 View Post
    Improving existing languages is fine by me, Elysia suggested that it is strictly a better thing than trying to come up with new languages, which i don't agree with at all.

    Besides, "improving" C++ has become synonymous with simply expanding an already humongous language.
    No, I did not imply that. I do believe making new languages is a good if they can fix or improve on fundamental problems in existing languages that cannot actually be fixed in such languages in satisfying way. For example, type safety in C++. It's unlikely we're going to be able to get rid of implicit conversions which can be evil at times, so it would make sense to make a new language to fix that. However, that is not enough. You have to consider the fact that new languages need to mature, too. C++ is a big language. How long is it going to take Rust to get to the same point while fixing the fundamental weaknesses? I don't think C++ is fundamentally broken and needs fixing. I also don't see what Rust truly offers that makes it "so much better" that it warrants replacing other "mature" languages.
    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.

Page 1 of 12 1234567891011 ... LastLast
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, 11: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, 07:29 AM

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