Thread: Let's talk about Rust!

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:

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.

Originally Posted by Neo1

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.

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

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

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

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?

Originally Posted by Neo1

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

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]

Originally Posted by Neo1

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.

Originally Posted by Neo1

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.

Originally Posted by Neo1

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.

Originally Posted by grumpy

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.

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

Originally Posted by Neo1

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.

Originally Posted by Neo1

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.

Originally Posted by Neo1

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.

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.