Thread: Let's talk about Rust!

  1. #31
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elkvis View Post
    Out of curiosity, is Neo1 the author of Rust? He/she seems to be defending it quite strongly. I understand that new things can be exciting, but I don't get the rather obstinate defense of said new thing.
    I'm not the author of Rust, the Mozilla foundation is. I didn't plan on spending the entire thread justifying the creation of Rust i must say, but then i didn't plan on finding such a generally negative attitude towards a possible replacement for C or C++ as i did.

    Don't make a new language unless the old language's complexity is severely hampering its progress
    See i'm of the opinion that we should be making tons of new languages, exploring new concepts and ideas. One of them might stick.

    Edit:

    As previously mentioned, people (myself, for one) still do use Fortran. Fortran didn't stop at the 77 standard, since then there have been many revisions to the standard: 1990, 1995, 2003, 2008, 2015 (coming soon).
    Nothing against FORTRAN, just needed an example of an old language.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  2. #32
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by MutantJohn View Post
    So basically, the answer is to use both...
    And then we get down to the Achilles Heel. Why aren't we doing that? Answer: Because it's too difficult!
    It's why x264 still is very CPU-dependent, among others.

    Isn't this idea already done through chips with integrated graphics? Or are integrated chips like a weird Frankenstein creation?
    As far as I know, they're still two separate entities: one CPU and one GPU, though they share the integrated memory bus.
    But we're getting closer with the unified memory architecture. What is needed now is single instruction set for the processor and truly incorporate the GPU into the CPU so that instructions that are more relevant for GPUs are sent off to processing on small, simple cores.

    Quote Originally Posted by Neo1 View Post
    See i'm of the opinion that we should be making tons of new languages, exploring new concepts and ideas. One of them might stick.
    I'm all for experimental languages, and for new languages for research purposes.
    I'm against introducing a new language set out to replace existing languages unless you have a very good reason.
    Last edited by Elysia; 06-13-2014 at 01:40 PM.
    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.

  3. #33
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Interesting. So, I started reading a bit more about APUs and it's rather intriguing. It implies that we no longer need to buy a separate CPU and GPU, just one single APU. It'd make writing hybrid programs much simpler.

    Still, it feels like a lot of this motivation does come from the recognition that GPUs are powerful in their own right (yes, not every application benefits) and that combining both CPUs and GPUs into a single unit fixes a lot of the issues with this currently very stitched together code.

  4. #34
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    I'm all for experimental languages, and for new languages for research purposes.
    I'm against introducing a new language set out to replace existing languages unless you have a very good reason.
    The difference then boils down to whether or not there is any reasons to replace either C or C++. I can think of a thousand good reasons, but apparently none of them are good enough to warrant the effort according to you.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  5. #35
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Neo1 View Post
    I can think of a thousand good reasons, but apparently none of them are good enough to warrant the effort according to you.
    You have mentioned but a few which mostly boils down to that C++ is a big, complex language. I'm not sure you can replace C with Rust, though, since C is supposed to be light-weight.
    I am for replacing a language if there is sufficient motivation. It has to be good enough to throw away years of engineering of the language.
    Last edited by Elysia; 06-13-2014 at 02:05 PM.
    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. #36
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    I disagree that marking potentially unsafe code as 'unsafe' is the same as making the programmer jump through hoops. It informs the compiler that it should not issue errors or warnings about potentially dangerous instructions in the code and it tells humans reading the source code that here is something which is known to be unsafe, yet necessary, and that (hopefully) care has been taken to cover all possible points of failure manually.
    O_o

    To be blunt, I'd be a fool to think you'd see the hoops I see. You are obviously, as stated even, thinking Rust as solving the problems of the C++ language. You don't see the issue as "hoop jumpery" because you see the issue as a solution. Of course, everyone defends their own designs with the great "Solution" label. ([Edit]For the jerks, I am including myself in the subset of "everyone".[/Edit]) You started this discussion on a C/C++ board. You are responsible for making the argument if you want me to see what I see as "hoop jumpery" as a solution; you can't just say you disagree because you don't think of as "hoop jumpery".

    I feel like you're saying that all of the added correctness and abstraction that the Rust memory management system affords the programmer, is collectively worth less than the ability to write unsafe code without the hassle of having to mark it unsafe.
    I intended no such thing. You've taken one example, an example offered to clarify a general point, to stretch into the absurd.

    I'll make the explanation, after a fashion, more exact.

    Rust offers $(Programmer) the $(Feature) feature. The Rust feature $(Feature) is conflicting with designs $(Programmer) intends to use to solve a problem. $(Programmer) does not want that feature. $(Programmer) must disable that feature. $(Programmer) has to spend time disabling that feature. Rust does not now offer feature $(Feature) because $(Programmer) have disabled that feature. $(Programmer) can now use Rust to solve the problem.

    $(Language) does not have $(Feature) feature. $(Programmer) does not have to spend time disabling feature $(Feature). $(Programmer) can spend all the time available to solve the problem.

    [Edit]
    The above is also an explanation of why Rust has no chance whatsoever to actually replace C.
    [/Edit]

    I, personally, like the guarantees that take place during program compilation, but one of the reasons I prefer C++ so much is that I enjoy a lot of different fields. I often need to "push metal", and I don't want the tools stopping me. The tools I have are intended to help me. Every hour I spend fighting my tools is time I don't have for solving my problems. (I can't help but say, this sort of thing is why I don't do "Linux From Scratch" anymore. I enjoyed the experience, but I spent way more time "developing" the system than actually using the system.) I can't justify jumping through hoops when other tools don't make me jump through those hoops.

    As above, I'd be a fool to think you'd see the same hoops. C++ has a lot of hoops. (The "available by default" exception mechanism in C++ has caused a lot of issues, and many new C++ programmers are terribly fooled by the apparent option to ignore exceptions.) You like those Rust features being "available by default"? Awesome. I have no doubt then that you'd see plenty of "hoop jumpery" in my C++ code. You may indeed be able to say that "You do what you want, where you want, how you want, and Rust mostly stays out of your way.".

    The way i see it, our tools will never improve if we are not willing to make mistakes. C++ no longer represents the best we can do when it comes to systems programming languages, let us reiterate, make some mistakes and hopefully end up with a better tool in the end.
    o_O

    Your argument is missing one crucial ingredient: if you don't learn from the mistakes, you don't get the better tool.

    Yes. Developing "yet another post C++ language" on the foundations of C++ is a mistake.

    What i see is a third option, somewhere between the C approach and the GC approach, where the language is designed in a way to make the compiler help us avoid memory flaws in the program.
    My libraries and applications have thousands of lines of code dedicated to various "firewalls". (In other words, my libraries are "designed in a way to make the compiler help us avoid memory flaws in the program".) I've spent years throwing my code at dozens of compilers. (Literally every line of library code I've written in the last three years has passed through at least five compilers.) I run my code through "Valgrind". I write dozens of automated tests. I exhaustively--aka "all possible inputs"--test as much code as possible. I branch test every other bit of code. Every flaw that lives in my code is because I made the sort of mistakes that don't get discovered until the moon aligns and someone slaughters a goat. My code doesn't have the sort of flaws that Rust could prevent.

    No. I don't consider that "hoop jumpery". Well, I do consider that "hoop jumpery", but I do that because I care about quality. I'd run my Rust code, if I used Rust, through a similar process.

    You should join the bandwagon, we have a great view and cocktails with little umbrellas in them!
    I hate to burst your bubble, but I consider Python and Javascript better than Rust. I know the legends say "I'm totes into data metap yo!", but I actually just focus on designs that enable "use polymorphism", and Rust isn't as good at "use polymorphism" as those language.

    If I were to join a different bandwagon, I'd probably push for proposed changes to Python sooner rather than later so I could just keep using what I've learned the last several months. To be clear though, I have focused on Python for the last several months, and I hope the caretakers make such changes. I have no qualms about leaving C++ behind for a language with less "hoop jumpery".

    Soma
    “Salem Was Wrong!” -- Pedant Necromancer
    “Four isn't random!” -- Gibbering Mouther

  7. #37
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    You have mentioned but a few which mostly boils down to that C++ is a big, complex language. I'm not sure you can replace C with Rust, though, since C is supposed to be light-weight.
    So is Rust. As with C, all you really need is a stack. Anything else is optional. You could rewrite the Linux kernel in Rust if you really wanted (and waited until the language is finished, and had a bazillion dollars and a billion man-years).

    Phantomotap:

    I see manual memory management as the 'hoop jumpery'. If i understand you correctly you feel it is my responsibility to argue why this is the case, but i'm not sure i know where to start with that. In my view it is fairly self-evident that manual memory is the same as jumping through hoops to get the desired behaviour from the program.

    Your argument is missing one crucial ingredient: if you don't learn from the mistakes, you don't get the better tool.

    Yes. Developing "yet another post C++ language" on the foundations of C++ is a mistake.
    In what sense is Rust being developed on the foundations of C++? It borrows concepts from many languages, C++ being one of them. I also definitely do not agree that Rust has not improved upon _some_ of the mistakes made with C++.

    I hate to burst your bubble, but I consider Python and Javascript better than Rust. I know the legends say "I'm totes into data metap yo!", but I actually just focus on designs that enable "use polymorphism", and Rust isn't as good at "use polymorphism" as those language.
    Rust offers trait-based polymorphism kind of like Java interfaces as well as bounded type parameters, i don't really see why either of those are worse than what either JS or Python has to offer.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  8. #38
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Neo1 View Post
    So is Rust. As with C, all you really need is a stack. Anything else is optional. You could rewrite the Linux kernel in Rust if you really wanted (and waited until the language is finished, and had a bazillion dollars and a billion man-years).
    You misunderstand the point of "light-weight."
    Either Rust will be C or C++, but it can never be both. C is minimalistic. C++ is monolithic.
    If you add only a minimal amount of features to the language, it could strive to be C, but it cannot be C++.
    If you do the it the other way, it can be C++, but it cannot be C.
    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.

  9. #39
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    You can tell when Elysia thinks he's winning the argument because his replies feature shorter sentences and he stops explaining how he reached his conclusions.

  10. #40
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    You misunderstand the point of "light-weight."
    Either Rust will be C or C++, but it can never be both. C is minimalistic. C++ is monolithic.
    If you add only a minimal amount of features to the language, it could strive to be C, but it cannot be C++.
    If you do the it the other way, it can be C++, but it cannot be C.
    In that sense Rust is closer to C++ than it is to C and is already quite large. I think the claim that it can or will replace C stems from the fact that it has the potential to match C in terms of raw speed yet surpass it in expressiveness and other such metrics. Emphasis on potential since it is certainly not there yet.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  11. #41
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    As a quick aside, do people keep calling C++ huge in the sense that they're including the STL?

    Because if you exclude the STL, C++ isn't exactly that large. It only has a few inherent features independent of the STL that C doesn't, namely objects, inheritance, polymorphism, constructors/destructors, overloading, lambdas... Am I forgetting anything? Using new and delete aren't exactly groundbreakingly complex so I didn't feel a need to include them.

  12. #42
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by whiteflags View Post
    You can tell when Elysia thinks he's winning the argument because his replies feature shorter sentences and he stops explaining how he reached his conclusions.
    There is no argument. I am merely expressing my views. If something is unclear, and you are interested, then ask. I cannot read your mind.

    Quote Originally Posted by Neo1 View Post
    ...I think the claim that it can or will replace C stems from the fact that it has the potential to match C in terms of raw speed yet surpass it in expressiveness and other such metrics. Emphasis on potential since it is certainly not there yet.
    The same can be said of C++, yet it has not replaced C.

    Quote Originally Posted by MutantJohn View Post
    Because if you exclude the STL, C++ isn't exactly that large. It only has a few inherent features independent of the STL that C doesn't, namely objects, inheritance, polymorphism, constructors/destructors, overloading, lambdas... Am I forgetting anything? Using new and delete aren't exactly groundbreakingly complex so I didn't feel a need to include them.
    I can think of at least two other things:

    Templates. Easily C++'s most complex feature.
    constexpr, or compile-time evaluation. Very complex. [I am thinking of C++14's constexpr.]

    But this is hardly everything. Just take a look at the size of the standard. The C++11 draft was 1374 pages long. Tons of stuff in there.
    Last edited by Elysia; 06-13-2014 at 03:10 PM.
    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. #43
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Without the STL the C++ language isn't that useful. Try to do something, don't take too long, and if you type #include, you lose.

    You just lost to hello world.

  14. #44
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    2,665
    Gosh, way to be super duper literal whiteflags.

    At least Elysia saw what I was going for and you're totally right, Elysia, I completely blanked on templates.

    And in most situations, you can just use old C libraries in lieu of such print commands from the STL. With standard C libraries, you can still make good use of C++ and its features.

  15. #45
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Elysia View Post
    The same can be said of C++, yet it has not replaced C.
    Weeeeelll, it has not completely replaced C, but it has certainly been taking big bites out of C's marketshare for some time now. Would you not say? Are we not constantly having discussions on this board where everyone claims C is mostly used for embedded programming these days?

    If C++ has not completely replaced C, that can be attributed to any number of properties of the language which Rust does not necessarily share. The most likely explanation is probably that C++ has one property that C does not: It is disliked by Linus Torvalds
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

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