On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:
>
> The 'real' motivation is simple -> an increased awareness of the benefits of Rust within the C++ community.

It seems to be some kind false narrative that Rust is savior of all and will create a new world. The more I learn Rust, the more I realize that's not the case.

If you look at Rust error handling (the proposed std::Result) it is less powerful than exceptions in D (or C++, C# and several others). D can even handle multiple exceptions, even if that is seldom used. Basically you can catch any exception up the call chain and polymorphism really makes this possible. It is easy to add new exceptions as well as reusing existing ones thanks to this.

If you look at Rust Result<T, E>, it is basically a wrapped return value and the type in E must be known to the caller so cannot easily pass it up the chain. Type E can be anything but adding your own error types becomes cumbersome. Rust might also provide an Error trait (Rust way of structs with virtual methods) which is more generic so that you can add your own custom error type. However, this Error trait is in general allocated on the heap so not even Rust is immune to heap allocated error handling.

For simpler error handling Result<T, E> is a better match as E is in general an immutable string, an integer or nothing.

On Saturday, 26 February 2022 at 20:59:53 UTC, IGotD- wrote:
> On Friday, 25 February 2022 at 21:03:21 UTC, forkit wrote:
>> [...]
>
> It seems to be some kind false narrative that Rust is savior of all and will create a new world. The more I learn Rust, the more I realize that's not the case.
>
> [...]

Case in point,

https://nnethercote.github.io/2022/02/25/how-to-speed-up-the-rust-compiler-in-2022.html

>  Decoder trait used for metadata decoding was fallible, using Result throughout. But decoding failures should only happen if something highly unexpected happens (e.g. metadata is corrupted) and on failure the calling code would just abort. This PR changed Decoder to be infallible throughout—panicking immediately instead of panicking slightly later—thus avoiding lots of pointless Result propagation, for wins across many benchmarks of up to 2%.

Beware of always copying other language designs.

On Sat, Feb 26, 2022 at 08:59:53PM +0000, IGotD- via Digitalmars-d wrote: [...]
> It seems to be some kind false narrative that Rust is savior of all and will create a new world. The more I learn Rust, the more I realize that's not the case.

Exactly.  The Rust hype these days are reminiscient of the Java hype back in the 90's.  Java was touted as the be-all and end-all of programming that will solve all of your programming problems and present none of its own. Well, 30 years later we have learned some good things from Java, but we have also realized its shortcomings, and that it's really NOT what it was originally hyped to be.


> If you look at Rust error handling (the proposed std::Result) it is
> less powerful than exceptions in D (or C++, C# and several others).
[...]
> If you look at Rust Result<T, E>, it is basically a wrapped return value and the type in E must be known to the caller so cannot easily pass it up the chain. Type E can be anything but adding your own error types becomes cumbersome.
[...]

Thanks, that's exactly what I've been trying to say, except you said it better. :-D

Error handling using sum types, etc., are at the core just a cosmetic makeover of C's return codes.  It puts the onus on the caller to check for every return code and take appropriate action. AND it's not easily propagated up the call chain, because the error type E returned by func1 may not be the same type E returned by its caller, so you cannot simply pass it along; you *have* to manually map it to your own error return type.

In theory, your own error return type would be a sum type of all error returns of the functions you call plus your own error codes. In practice, I honestly doubt if anyone would bother doing this; I expect the tendency would be to simply map every error from dependent functions to the equivalent of INTERNAL_ERROR, i.e., a generic, non-descript, unhelpful code that tells the caller nothing about what the actual error is.

Basically, it would be identical to how you use error codes in C, except dressed in prettier syntax.  The fundamental problems with C error code handling remain unchanged.

For example, it does not address the issue that often, the information required to decide how to handle an error is not readily available in the caller, but can only be found higher up the call chain. The Rust way is just glorified C return codes that doesn't solve this problem in any way.


T

-- 
People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)

On Saturday, 26 February 2022 at 23:00:24 UTC, Ola Fosheim Grøstad wrote:
>
> That "critical mass" is the key issue, so what is good for C++ does not translate to other languages.

c++'s critical mass is more of happy accident, than anything (i.e. there were no serious contenders for that same market at the time, or for a very long time since).

Same is true for C.

Same is true for Java.

Then C# came along...

There are plenty eager to see a better c++.

I personally do not think Rust is that alternative. Why? Because they used computer science alone to create a new language for 'modern times'.

Instead, they should have combined computer science with psychological science, and they would have come up with a better syntax that is less cognitively challenging (something C++ is working hard towards.. well..in part).

On Sunday, 27 February 2022 at 04:57:28 UTC, __StarCanopy wrote:
>     ) // Outcome!(int, IsNegativeError, IsOddError)

My apologies, the places of IsOddError and IsNegativeError should be reversed.

On Sunday, 27 February 2022 at 01:29:58 UTC, forkit wrote:
> On Saturday, 26 February 2022 at 23:00:24 UTC, Ola Fosheim Grøstad wrote:
>>
>> That "critical mass" is the key issue, so what is good for C++ does not translate to other languages.
>
> c++'s critical mass is more of happy accident, than anything (i.e. there were no serious contenders for that same market at the time, or for a very long time since).
>
> Same is true for C.
>
> Same is true for Java.
>
> Then C# came along...
>
> There are plenty eager to see a better c++.
>
> I personally do not think Rust is that alternative. Why? Because they used computer science alone to create a new language for 'modern times'.
>
> Instead, they should have combined computer science with psychological science, and they would have come up with a better syntax that is less cognitively challenging (something C++ is working hard towards.. well..in part).

Why do I still bother with C++, when my work languages are Java and .NET languages?

While they stole C++'s thunder on GUI and distributed computing, their runtimes, or native bindings to the host platforms, or GPGPU programming bindings, require dealing with C++ in one way or the other.

Using D instead, would be great, but in those scenarios it would be adding just another layer to debug between the work that has to be delivered in Java/.NET anyway, and the SDKs that are C++ only, so why bother.

Same applies to any language pretending to take away C++'s throne in such domains.

What D needs is focus on being great at a specific domain, as most IT departments pick languages based on platforms, not the other way around.