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; Originally Posted by whiteflags Without the STL the C++ language isn't that useful. Try to do something, don't take too ...

  1. #46
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,101
    Quote Originally Posted by whiteflags
    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.
    The I/O component of the C++ standard library was not derived from the STL.

    EDIT:
    Quote Originally Posted by MutantJohn
    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 think you are confusing the Standard Template Library (STL), a third party library from which certain parts of the standard library were derived, with the standard library itself.
    Last edited by laserlight; 06-13-2014 at 04:24 PM.
    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

  2. #47
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,887
    Quote Originally Posted by Neo1 View Post
    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?
    I dunno. It certainly would be a dream come true if it did (in my opinion), but I am not qualified to say. I know C is popular in embedded systems, but also in the Linux world.

    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
    The most likely "property," I think, is that C is much simpler to implement than C++, which makes it faster and cheaper to implement one for new systems where the full power or complexity of C++ is not needed. I don't see Rust having an advantage here.
    Of course, it could be a number of other things, too, but I am not qualified to say since I don't have experience with nor know anyone who does.
    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. #48
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    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.
    O_o

    You are again stretching an example offered in clarification to an absurd level.

    I also definitely do not agree that Rust has not improved upon _some_ of the mistakes made with C++.
    With whom do you not agree? I have not said anything even remotely similar to "Rust has improved nothing over C++.".

    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.
    You really just don't get the point being made.

    What you think, what you see, what you care to imagine others have said, and what examples you stretch to fit a different purpose aren't the least bit relevant.

    If you are going to proselytize, to convince me or anyone else to "join the bandwagon", you can't just state your opinion. You have to make arguments which have at least some chance of changing the opinions other programmers have about the languages they choose to use.

    Let me go the other direction simply because he entered the discussion in any event. Telling Linus that C++ should be used because reasons to develop Linux will not change his opinion. Linux sees that C++ has a lot of problems that C doesn't have. I disagree. (I find him so very wrong he'd have to spend years in mediation on some mountain to find a way to be more wrong.) My opinion is irrelevant. I will never convince him to use C++ for kernel development because he thinks C++ will "get in his way". To the point, if he feels that way he is surely correct.

    I'll try one final time: you aren't going to convince anyone to use features that are perceived to be problems, and your opinion on those features being problems or solutions is not the least bit relevant because they and not you are ones who need convincing.

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

  4. #49
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    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.
    O_o

    I tend to grow more elaborate so I suppose we balance out.

    [Edit]
    Wait. I actually think I'm "losing" this discussion.
    [/Edit]

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

    No. You are wrong.

    I don't have the numbers or anything so I admit to speculation, but the first five or so years of C++ was spent without the STL seeing significant usage. The perception of templates, thus the STL, causing "bloated binaries" was ridiculously strong. I still have to argue about it these days.

    Even now, a lot of people avoid templates for some or other absurd rationale.

    The STL is important to the standard, but the STL is actually quite small, and now that standard C++ also has a large support structure of meta-programming, variadic templates, and "move semantics" barely a line entry in the complexity list.

    [Edit]
    If you are talking about the entire standard library, you are correct. C++ does have a massive standard library, but removing the support structure from C++ would be hardly different than removing the support structure from any other language. Python, for example, has standardized interfaces for "Pickle", "JSON", "XML", HTTP server communication, and database communication which makes Python great for the "server side", but those components are provided by libraries not the core language.
    [/Edit]

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

  5. #50
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    I think you are confusing the Standard Template Library (STL), a third party library from which certain parts of the standard library were derived, with the standard library itself.
    O_o

    To be fair, whiteflags probably made the same mistake.

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

  6. #51
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,750
    I can definitely accept that.

    I think I'm basically trolling, so I'll stop. I really don't care either way what happens to rust.

    I respect that you have at least a historical perspective and can tell me that I am wrong.

    I don't have the numbers or anything so I admit to speculation, but the first five or so years of C++ was spent without the STL seeing significant usage.
    I'm prone to forget that the STL is strictly templates, somehow. It's in the name. Oops.

  7. #52
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    I'll try one final time: you aren't going to convince anyone to use features that are perceived to be problems, and your opinion on those features being problems or solutions is not the least bit relevant because they and not you are ones who need convincing.
    Fine, what are these features that you perceive to be problems?
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  8. #53
    Registered User
    Join Date
    Oct 2006
    Posts
    2,539
    Quote Originally Posted by Neo1 View Post
    Fine, what are these features that you perceive to be problems?
    It's entirely irrelevant which features we're talking about. Different programmers will find different features to be problems. For example, I don't like the fact that, in C++, template classes and functions need to be fully defined in header files (effectively). Other people will have no problem with this fact, but they'll find immutable references to be a problem. It's a matter of personal taste and opinion, and those opinions are often so deeply ingrained, that you cannot possibly overcome them. In the end, it's a question of which tool is right for the job. I fail to see how a new language like Rust is any more "right" than C or C++ for a given job, since it's obviously a derivative of both C and C++.
    phantomotap likes this.
    Code:
    namespace life
    {
        const bool change = true;
    }

  9. #54
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    Fine, what are these features that you perceive to be problems?
    O_o

    I fear that, due to participation, I have misguided you somewhat. I spent some time with the official tutorial and "sandbox" last year when (elided) ran an article on the "new hotness". You aren't going to convince me to use Rust.

    You could though call me Kevin ([Size]*[/Size]) because I find the generics offered by Rust to be even uglier than in C++ while being less powerful and making me jump through hoops of "traits" flavored specialization instead of allowing me to rely on the assumption of eventual interface.

    [Edit]
    I'm leaving it because how?

    Really, how did I get a size from the size menu thingy without getting a size?
    [/Edit]

    Soma

    [Size]* I actually guffawed at that dumb reference.[/Size]
    Last edited by phantomotap; 06-13-2014 at 06:18 PM.
    “Often out of periods of losing come the greatest strivings toward a new winning streak.” -- Fred Rogers
    “Salem Was Wrong!” -- Pedant Necromancer

  10. #55
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,678
    Quote Originally Posted by Elysia View Post
    I'm against introducing a new language set out to replace existing languages C++ unless you have a very good for any reason.
    ,, =D
    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

  11. #56
    Registered User
    Join Date
    Jun 2005
    Posts
    6,522
    Quote Originally Posted by Neo1 View Post
    No, but i _did_ expect a reasonable awareness of the weaknesses of C/C++. I don't think that is what i got.
    You might have expected it, but you approached it by expecting people to acknowledge that the approach in Rust is significantly better. It has some neat features, but hardly qualifies as inherently better at everything.

    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.
    I suspect Elysia's point is that a lot of new languages get created based on the premise of being a "better <name a preceding language here that we're trying to supplant>", and most of them reflect preconceptions, narrow views, and limited understanding of the preceding language rather than introducing something genuinely new and improved.

    A lot of advocates of such new languages often demonstrate limited understanding of the preceding language as well. And expect people to accept the premise that their narrow view is an accurate reflection of the preceding language. As you have.

    Quote Originally Posted by Neo1 View Post
    Besides, "improving" C++ has become synonymous with simply expanding an already humongous language.
    That's not really true. The philosophy of C++ standardisation for years has been about extending the library to expand functionality, and only extending the language to support improvements of technique that can't be supported by expanding the library.

    It is true that C++ (and the library) do tend to grow faster than they contract. But that is true of almost any language. The only languages that aren't characterised by growth (in either their language or libraries) are those of limited utility (i.e. specific niches) that are stagnant. It is true that so-called "better" languages often start smaller than the language they claim to supplant, but they (or their libraries) rarely get smaller from there - they either stagnate or grow.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy in reply to you, it is likely you deserve it. Suck it up, sunshine, and read this, this, and this before posting again.

  12. #57
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by grumpy View Post
    You might have expected it, but you approached it by expecting people to acknowledge that the approach in Rust is significantly better.
    I most certainly did. Immutability by default is _plainly_ better than the opposite, compile-time memory management is _plainly_ better than dereferencing dangling pointers at runtime, the increased type-safety is _plainly_ better than that offered by C or C++. At least if program correctness is of any concern. I suppose you now get to call me arrogant for assuming most if not all other programmers would share these views.

    It has some neat features, but hardly qualifies as inherently better at everything.
    I'd say those features are more than just 'neat', but i wouldn't be as daft as to suggest it is better in _every_ aspect. As Elysia already mentioned, implementing a C compiler is likely a far simpler task than implementing a Rust compiler, which makes C a more obvious choice for various exotic embedded platforms. Also, even though it is brand new, Rust is already kind of a large language, the astute reader will surely have noticed this is not something i find to be an attractive property.

    I suspect Elysia's point is that a lot of new languages get created based on the premise of being a "better <name a preceding language here that we're trying to supplant>", and most of them reflect preconceptions, narrow views, and limited understanding of the preceding language rather than introducing something genuinely new and improved.
    If you want to claim this is the case for Rust then you still have all your work ahead of you.

    A lot of advocates of such new languages often demonstrate limited understanding of the preceding language as well. And expect people to accept the premise that their narrow view is an accurate reflection of the preceding language. As you have.
    I'm curious as to which part of my view on C/C++ that you consider narrow? I wouldn't be presumptious enough to call myself a C++ expert, but i have been using the language for a number of years now so i don't think it's fair for you to call my understanding of the language limited. At least not without expanding further on that point.
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  13. #58
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,356
    If you want to claim this is the case for Rust then you still have all your work ahead of you.
    O_o

    No. I'm sorry to have to point this out a severaleth (I didn't want to count.) time, but you have done that job for whomever should have been tasked.

    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.
    Immutable objects are simpler to reason about since you can make assumptions about variables and parameters that could not otherwise be made.
    Rust fixes many of the fundamental weaknesses of C++, for example, it doesn't contain the entirety of C within the core language.
    A proficient C++ programmer needs to be (nearly) fluent in C to be able to write and read good C++ code, even though the overlap between good C++ code and good C code is at this point nearly inexistant.
    The presence of C discourages new C++ programmers from properly adopting the object oriented mindset.
    Your comments reek of "preconceptions, narrow views, and limited understanding of the preceding language".

    I'm curious as to which part of my view on C/C++ that you consider narrow?
    I am not grumpy; I'm not even "not so grump", but I'll tell you that my favorite is "The presence of C discourages new C++ programmers from properly adopting the object oriented mindset.".

    The "object-oriented mindset" is garbage. You are wrong, but I wish you were right. The more C++ programmers I can prevent from developing the "object-oriented mindset" the happier I'll be as a person.

    I obviously disagree with Linus on C++ itself, but he isn't wrong about a lot of C++ programmers being garbage because of the "Oh. My. God. OOPS" nonsense.

    C++ is one of the few languages that really supports whatever patterns and paradigms you wish to throw at a compiler. The "object-oriented mindset" keeps people from using the right tool.

    Yeah. Sure. You didn't ask me, but you did ask.

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

  14. #59
    Registered User
    Join Date
    Jun 2005
    Posts
    6,522
    Quote Originally Posted by Neo1 View Post
    I most certainly did. Immutability by default is _plainly_ better than the opposite, compile-time memory management is _plainly_ better than dereferencing dangling pointers at runtime, the increased type-safety is _plainly_ better than that offered by C or C++. At least if program correctness is of any concern.
    Immutability by default is easier to analyse, certainly, but it also makes it harder to write programs with useful effects - since that requires something to be mutable.

    There are plenty of alternatives in C++ (and C) to avoid the existence of dangling pointers, let alone dereferencing them. In any event, not all forms of useful memory management can be effectively achieved at compile time - memory management, realistically, has aspects both at compile time and run time, with different advantages for different tasks.

    There is plenty of debate about the advantages and disadvantages of type safety - and not just limited to C/C++. It is certainly possible to identify disadvantages of the C/C++ type system, but it is not a slam-dunk that stronger levels of type safety is desirable.

    Quote Originally Posted by Neo1 View Post
    I suppose you now get to call me arrogant for assuming most if not all other programmers would share these views.
    You're demonstrating your traits in your post, and I don't feel any need to call you anything.

    Quote Originally Posted by Neo1 View Post
    If you want to claim this is the case for Rust then you still have all your work ahead of you.

    I'm curious as to which part of my view on C/C++ that you consider narrow? I wouldn't be presumptious enough to call myself a C++ expert, but i have been using the language for a number of years now so i don't think it's fair for you to call my understanding of the language limited. At least not without expanding further on that point.
    Soma has already pointed out how you're providing the counter-argument for your own views. No further effort on my part needed in that regard.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy in reply to you, it is likely you deserve it. Suck it up, sunshine, and read this, this, and this before posting again.

  15. #60
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,532
    Programming languages and programming paradigms all are variations on a single theme. It's not a programming language, it's not a programming paradigm, that is going to revolutionize the current industry practices. They will merely, as they always have, add their numbers to the long list of possible computer programming solutions at our disposal. With the exception of early periods of technological innovation, it is advancements in computer architecture the ones that can truly change the landscape and completely phase out our current, well established, decisively proven, and mostly correct, practices.

    We've been on long enough in this current computer architecture not to understand that we are already at the stage of milking every last bit of it. Every new solution we have presented to the problem of developing working software is slave to it. It cannot progress further into truly revolutionary practices, because... well, because there's nothing more to revolutionize. Looking at languages like Rust and even remotely thinking it has the power to phase out C or C++ is nothing more than an adherence to boring sensationalism, for one, or a lack of interest in observing the industry for what it really is; an ever increasing pantheon of slightly different solutions to the problem of creating working software in a timely fashion and with reduced maintenance costs.

    Maybe saying that there is nothing more to revolutionize is a bit of a stretch. But the alternative has apparently been believing in new messiah programming languages or paradigms. And that just feels even more idiotic.
    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.

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