Thread: Let's talk about Rust!

Originally Posted by grumpy

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.

No, no it doesn't. The narrow views that you claim i have of C++ seems to be matched to an equal extent by the narrow views you have of Rust. The only thing that _needs_ to be mutable is the state of the stdin/stdout buffers, network sockets etc. and Rust encourages developers to maintain totality when dealing with these interfaces. Everything else can be seen as a series of transformations from one state to the next, rather than a series of mutations. In general you could say that immutability eliminates side-effects, which as you say makes the code easier to analyse and understand since any flaws in the code are made more readily apparent. It also makes code easier to test. You can easily compare different states to each other, which means a memoized version of a piece of code becomes trivial to implement. There is a whole slew of functional programming languages in which immutable variables are the only kind of variables, precisely so referential transparency can be enforced. I don't think many people consider writing programs with useful effects a much harder task in any of those languages than it is in C++, in fact the opposite may be true.

There are plenty of alternatives in C++ (and C) to avoid the existence of dangling pointers, let alone dereferencing them.

While the tools have improved greatly, we can still do better.

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.

Now you're just being intentionally vague - which advantages are there to manually managing memory at runtime?

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.

Nonsense, type safety is the extent to which a programming language discourages or prevents type errors. More type safety is always an improvement. Again, this is contingent on the fact that you place any value on program-correctness.

You're demonstrating your traits in your post

As are you.

Phantomotap:

While i didn't ask you, i kind of had a feeling you would bite when i wrote that, so in a way i _did_ ask you. Let me rephrase it then.

The presence of C discourages new C++ programmers from not writing C.

I'm not going to enter a debate about the merits of OOP.

Originally Posted by Neo1

No, no it doesn't. The narrow views that you claim i have of C++ seems to be matched to an equal extent by the narrow views you have of Rust. The only thing that _needs_ to be mutable is the state of the stdin/stdout buffers, network sockets etc. and Rust encourages developers to maintain totality when dealing with these interfaces. Everything else can be seen as a series of transformations from one state to the next, rather than a series of mutations. In general you could say that immutability eliminates side-effects, which as you say makes the code easier to analyse and understand since any flaws in the code are made more readily apparent. It also makes code easier to test. You can easily compare different states to each other, which means a memoized version of a piece of code becomes trivial to implement. There is a whole slew of functional programming languages in which immutable variables are the only kind of variables, precisely so referential transparency can be enforced. I don't think many people consider writing programs with useful effects a much harder task in any of those languages than it is in C++, in fact the opposite may be true.

Is this immutability like Erlang?

Nonsense, type safety is the extent to which a programming language discourages or prevents type errors. More type safety is always an improvement. Again, this is contingent on the fact that you place any value on program-correctness.

That is not always true. Type safety comes at a price: it becomes more difficult to make the program do what you want. The tradeoff is, of course, that the compiler catches more bugs at compile time. To some applications, type safety is a large hindrance. It's not an ultimate tool that solves every problem.

The presence of C discourages new C++ programmers from not writing C.

Not true. People write C in C++ because they are mostly either more comfortable with it or don't know any better alternatives, or simply don't want to learn.
Hence, it is the fault of their education or because they are in a transition phase or because they are simply more comfortable with some paradigm (when you learn another language with a completely different paradigm, you tend to fight against it instead of learning it).

Originally Posted by Elysia

Is this immutability like Erlang?

I'm not familiar with Erlang, but a quick Google tells me Erlang uses single-assignment; so that would be a tentative yes.

That is not always true. Type safety comes at a price: it becomes more difficult to make the program do what you want. The tradeoff is, of course, that the compiler catches more bugs at compile time. To some applications, type safety is a large hindrance. It's not an ultimate tool that solves every problem.

I never claimed that type safety is an ultimate tool that solves every problem, i claimed that more type safety is always better than less type safety. If a very type safe environment is making it harder to make your program do what you want, it is only because it is forcing you to do it in a way that prevents type errors. I maintain that is always a good thing. I suppose Phantomotap will have something to say about type safety 'getting in the way' at this point, but if it is getting in the way of the programmer making type errors then that is fine by me.

Not true. People write C in C++ because they are mostly either more comfortable with it or don't know any better alternatives, or simply don't want to learn.
Hence, it is the fault of their education or because they are in a transition phase or because they are simply more comfortable with some paradigm (when you learn another language with a completely different paradigm, you tend to fight against it instead of learning it).

I can agree that there might be many different reasons for sticking to C as a newcomer to C++, if you can agree that if C was not present, no such thing would be possible.

Originally Posted by Neo1

I'm not familiar with Erlang, but a quick Google tells me Erlang uses single-assignment; so that would be a tentative yes.

Erlang is a functional programming language, which means it does not allow you to reassign variables or its state once created. It also requires you to use pattern matching instead of statements and recursion instead of iteration.
If that's the kind of language Rust wants to be, I want no part of it.

I never claimed that type safety is an ultimate tool that solves every problem, i claimed that more type safety is always better than less type safety. If a very type safe environment is making it harder to make your program do what you want, it is only because it is forcing you to do it in a way that prevents type errors. I maintain that is always a good thing. I suppose Phantomotap will have something to say about type safety 'getting in the way' at this point, but if it is getting in the way of the programmer making type errors then that is fine by me.

But my point is that sometimes type safety gets in the way. Consider you want a vector of different Ts. How do you do that? You could use polymorphism if all your Ts have the same interface, but you will have to pay for the overhead. Alternatively, you just use hoops and loops to make it possible to use different Ts in the same vector. It's possible, but it's complicated. And all of this simply because we have a lot of type safety. So yeah, while type safety is good, it is not always good. Sometimes it can be a panacea.

I can agree that there might be many different reasons for sticking to C as a newcomer to C++, if you can agree that if C was not present, no such thing would be possible.

Well, alright, fine. I can admit that much. But if C weren't preset, how many of those people would be using it?
I guess this might also be another way of saying what you're saying, but... the fact that the C subset exists means that we get some stupid teachers who think that only teaching the C subset of C++ is a good idea, hence giving birth to "C+" programmers. I don't blame the "C" subset. I blame the world.
Meh. I think you're winning this one, though poorly worded, I think it was.

Originally Posted by Neo1

The narrow views that you claim i have of C++ seems to be matched to an equal extent by the narrow views you have of Rust.

You're the one who - whether you realise it or not - took a narrow view on C++ and disparaged other expressed views, because you wanted an uncontested discussion of where Rust is better. In a C++ forum, it's hardly surprising that some folks would return the favour.

The difference, in your mind at least, is that you're justified because you're right so, by definition, alternative views are due to people being close minded. On that basis, I'm not buying any further into this discussion.

Originally Posted by Elysia

Erlang is a functional programming language, which means it does not allow you to reassign variables or its state once created. It also requires you to use pattern matching instead of statements and recursion instead of iteration.
If that's the kind of language Rust wants to be, I want no part of it.

Rust has pattern matching and recursion. It also has regular conditionals and for/while loops. Nobody is forced to stick to immutable variables either, it is just the default type of variable.

But my point is that sometimes type safety gets in the way. Consider you want a vector of different Ts. How do you do that? You could use polymorphism if all your Ts have the same interface, but you will have to pay for the overhead. Alternatively, you just use hoops and loops to make it possible to use different Ts in the same vector. It's possible, but it's complicated. And all of this simply because we have a lot of type safety. So yeah, while type safety is good, it is not always good. Sometimes it can be a panacea.

Strong type safety and type casting are not mutually exclusive. You are allowed to cast any numerical type to any other numerical type. A raw pointer can be cast to or from any numerical type or different raw pointer type. Anything other than that and you are in 'unsafe' territory. If the size and aligment of the types you are casting to/from match, you can use transmute() within an unsafe block and in those cases an argument can definitely be made that the language is getting in your way, but then i think another argument could be made that what you're doing is likely not very smart and even if it is necessary it is uncommon enough that having to wrap it in an unsafe block is not a big deal.

You're the one who - whether you realise it or not - took a narrow view on C++ and disparaged other expressed views, because you wanted an uncontested discussion of where Rust is better. In a C++ forum, it's hardly surprising that some folks would return the favour.

I wanted no such discussion. I just didn't expect the overwhelming amount of time i'd have to spend defending why the language is justified. You claim i'm the one who took a narrow view on C and C++, yet the first replies to this thread were nothing but shallow dismissals so if anyone is returning the favour, it is me.

It seems not many were willing to put in the effort to actually find out what the advantages or disadvantages of the language are, but everyone was willing to chime in.

The difference, in your mind at least, is that you're justified because you're right so, by definition, alternative views are due to people being close minded. On that basis, I'm not buying any further into this discussion.

Informed alternative views are fine, yet i don't think we've seen many of those in this thread when it comes to merits of the language itself, and certainly none from you.

Originally Posted by Neo1

Strong type safety and type casting are not mutually exclusive. You are allowed to cast any numerical type to any other numerical type. A raw pointer can be cast to or from any numerical type or different raw pointer type. Anything other than that and you are in 'unsafe' territory. If the size and aligment of the types you are casting to/from match, you can use transmute() within an unsafe block and in those cases an argument can definitely be made that the language is getting in your way, but then i think another argument could be made that what you're doing is likely not very smart and even if it is necessary it is uncommon enough that having to wrap it in an unsafe block is not a big deal.

You're missing the point. Storing different types of objects contiguously in memory and traversing them in order is often ideal for speed (common in games), but hard due to the type system. Rust isn't going to fix this. We're not talking about pointers here. We're talking about std::vector<T_x>, where x is different for every object. Hence, the first element can be an int, the second can be MyObj, the third can be std::string, etc. This is where the type system gets in the way, and yet it's so common!

Originally Posted by Elysia

You're missing the point. Storing different types of objects contiguously in memory and traversing them in order is often ideal for speed (common in games), but hard due to the type system. Rust isn't going to fix this. We're not talking about pointers here. We're talking about std::vector<T_x>, where x is different for every object. Hence, the first element can be an int, the second can be MyObj, the third can be std::string, etc. This is where the type system gets in the way, and yet it's so common!

I'd challenge the statement that this is commonly done in games, this seems like a horrible design to me. Nonetheless, if someone really wants to do this they can, by jumping through hoops, regardless of whether they are using Rust or C++. You'd have to make a conscious effort to get around the restrictions set in place by the type system, for both languages, which i think should be kind of a red flag. Circumventing the type system in Rust is a matter of marking the code unsafe, i'd say there is a multitude of different ways to accomplish that in C++ (my first impression is to use boost::any).

Either way, the stricter type safety of Rust does not really factor in, in this oddly specific example of yours.

Originally Posted by Neo1

I'd challenge the statement that this is commonly done in games, this seems like a horrible design to me.

It makes absolutely perfect sense. Games tend to use an event-driven model where many things needs to be done on the rendering thread, among other stuff. So there are different events and they all need to execute. How do you do that? Well, the obvious example would be to derive them all from a common base class and use polymorphism. But then you need to allocate on the heap. That's slow. To make matters worse, you need to iterate these events and execute them, but since they're all scatter around the memory, you get lots of cache misses. That's slow.

In fact, someone tried to optimize this very scenario by using a workaround. The gain? A 50x speedup! Yes. 50 times. If it's not worth it trying to put different objects contiguously in memory like that for 50 times speedup, I don't know what is.

Originally Posted by Elysia

It makes absolutely perfect sense. Games tend to use an event-driven model where many things needs to be done on the rendering thread, among other stuff. So there are different events and they all need to execute. How do you do that? Well, the obvious example would be to derive them all from a common base class and use polymorphism. But then you need to allocate on the heap. That's slow. To make matters worse, you need to iterate these events and execute them, but since they're all scatter around the memory, you get lots of cache misses. That's slow.

In fact, someone tried to optimize this very scenario by using a workaround. The gain? A 50x speedup! Yes. 50 times. If it's not worth it trying to put different objects contiguously in memory like that for 50 times speedup, I don't know what is.

I just don't see how this in any way works as an argument against stronger type safety always being an advantage? If you want to do type unsafe things, then the only way you're gonna be able to do it without working around the type system is to use a language with no concept of types at all, like assembly. Otherwise you'll have to do some sort of circumvention, both Rust and C++ have ways of doing that. If, as is usually the case, you do not want to do type unsafe things then the stricter type system will be a boon.

A good type system will allow these things without hoops and loops and while still remaining safe. Why should we have to break the type system to do something? We're still not working "against" the type system. We're not trying to assign an int to a string or or a string to an int, so why should the compiler stop us from achieving this? I mean, in languages like javascript, this is trivial to program. But in C++ (and Rust), it's not. Why? It's completely safe, working code.

The presence of C discourages new C++ programmers from not writing C.

O_o

o_O

Wrong. Elysia has already told you this multiple times. A C++ programmer taught good C++ from scratch doesn't write C.

The experience with C and lack of experience with C++ discourages new C++ programmers from not writing C.

Does a C programmer have habits used in coming to C++? Absolutely. Is that in any way unique to C++? No. People are simply prone to stick with what they know.

You claim i'm the one who took a narrow view on C and C++, yet the first replies to this thread were nothing but shallow dismissals so if anyone is returning the favour, it is me.

o_O

What?

Your problem is that your "lure" is so easily dismissed that few people will give such nonsense any sort of credibility. I have, yes literally, seen dozens of languages that were going to replace C and C++ and Javascript and PHP. The very idea of a new language having such a different feature set replacing any other language is laughably foolish. No experienced programmer is going to take "$(Language1) is going to replace $(Language2)." seriously because we've all seen that claim prove false many times.

How do you not get that very simply thing? C already has several viable alternatives. Rust is in no way unique. Rust is just a different flavor in a box already saturated with different flavor. The people using C are still using C because they have chosen, for whatever reasons, to use C. My opinions do not matter. Your opinions do not matter. No language will ever be replaced while the community around the language sees no value in switching.

You sound like every other yahoo proselytizing a new language.

*shrug*

I have given you multiple chances, and I even asked then told you to support your claims with something substantial. You mocked the very notion that you should have to defend your opinions. You even specifically refused to enter a debate about the merits of "OOP" which you implicitly claimed as superior despite the fact that I was complaining about the "object-oriented mindset" which is problem people have not tools.

*sigh*

Your comments still reek of "preconceptions, narrow views, and limited understanding of the preceding language".

I'm out.

Soma

Originally Posted by phantomotap

Wrong. Elysia has already told you this multiple times. A C++ programmer taught good C++ from scratch doesn't write C.

The experience with C and lack of experience with C++ discourages new C++ programmers from not writing C.

Does a C programmer have habits used in coming to C++? Absolutely. Is that in any way unique to C++? No. People are simply prone to stick with what they know.

It is absolutely unique to C++ in the sense that no other language contains its own predecessor as a subset (at least none that i know of?). I did not say everyone who writes C code and passes it off as C++ does so for the sole reason that C is available now did i? You're putting words in my mouth. Whatever their motivations are for doing so is completely irrelevant, what is relevant is that C++ _enables_ them to do it. No other language does this. Java might be based on C++ to some extent, and people coming to Java from C++ might at first not succeed in writing idiomatic Java due to their previous habits, but they will have a very hard time indeed of writing actual C++ code and passing it off as Java to anyone but a blind person. So yes, this property is absolutely unique to C++!

Your problem is that your "lure" is so easily dismissed that few people will give such nonsense any sort of credibility. I have, yes literally, seen dozens of languages that were going to replace C and C++ and Javascript and PHP. The very idea of a new language having such a different feature set replacing any other language is laughably foolish. No experienced programmer is going to take "$(Language1) is going to replace $(Language2)." seriously because we've all seen that claim prove false many times.

By virtue of the fact that previous languages which have been said to have potential to replace C were not Rust means that the claim that Rust might do so is a different claim entirely, and cannot be dismissed simply by referring to previous cases. This is a fallacy.

How do you not get that very simply thing? C already has several viable alternatives. Rust is in no way unique. Rust is just a different flavor in a box already saturated with different flavor. The people using C are still using C because they have chosen, for whatever reasons, to use C. My opinions do not matter. Your opinions do not matter. No language will ever be replaced while the community around the language sees no value in switching.

I get that completely, none of the previous languages which have been proposed as a replacement for C has prompted the community around C to migrate. You even say yourself that this could be for 'whatever reason', yet when a new language comes along that might or might not possess the values that could prompt a migration, it is shrugged off as irrelevant or unjustified since we already have C.

I have given you multiple chances, and I even asked then told you to support your claims with something substantial.

I do not 'claim' that Rust will replace C or C++, i hope it will. I've stated that Rust is superior to C / C++ in a number of different ways and have provided arguments to back this up. What are these claims that i have yet to back up? Less than a page ago you told me there is no argument i could offer to someone who sees what i claim to be a solution to a problem as a problem in and of itself, so really there is no winning with you is there?

You mocked the very notion that you should have to defend your opinions.

I have done no such thing whatsoever!

You even specifically refused to enter a debate about the merits of "OOP"

Yes because it has nothing to do with the subject at hand? Also i know your views on the matter and it leads nowhere.

which you implicitly claimed as superior

What on earth are you talking about? The gist of my argument in fact had nothing to do with OOP, my point was that the presence of C within the language of C++ can facilitate newcomers to create non-idiomatic C++ code, as we see countless examples of on this board on a daily basis.

Your comments still reek of "preconceptions, narrow views, and limited understanding of the preceding language".

¨

And your comments reek of the cynicism that many years of experience can foster. Take a vacation or something.