Hacker News Reader

Comment by Zambyte | Hacker News Reader

The lack of baggage is definitely a huge improvement, but I believe Zig also has this advantage over C. Rust and C++ also seem to encourage a similar style of programming (particularly newer C++), and so do Zig and C. The former encourages creating a library of types with inheritance, using syntactic sugar where applicable (ie operator overloading), and a functional style, whereas the latter limits the programmer to simple compound types without inheritance (manual, explicit dispatching), obvious syntax, and an imperative style.

Both seem to have their place in the ecosystem to me, but I'm really excited to see Zig mature.

View on HN

> [Rust and C++] encourages creating a library of types with inheritance

You'll want to expand on and clarify your meaning here, as Rust does not have inheritance.

Traits encourage the same programming style, regardless of if it's technically inheritance or not.

I disagree completely.

It's not just a technicality, traits are not the same as multiple inheritance. They allow you to solve the same kinds of problems but traits don't introduce the mountain-loads of confusion, complexity and headache that multiple inheritance does.

Moreover, nothing forces you to use traits. You're just strictly better off using them in many cases. But you can always defer to writing overtly repetitive C style code if you want.

Yet, I have zero issues mapping COM approach to OOP into Rust, because it turns out as per CS type systems theory, there are many ways to achieve the same goal.

Practical example, Raytracing in one weekend port from C++ to Rust, keeping the overall architecture.

Second example, Microsoft bindings to WinRT for Rust.

Yes, I'd argue COM is specifically very limited in such a way that traits can be used to implement it mostly seamlessly. But regardless, the dispute is over "[Rust and C++] encourages creating a library of types with inheritance".

Anyone who has at least read and understood both of these languages can see that this is not true, even if you replace inheritance with traits in rust. Not only that, traits do not support the same range of things that inheritance does. They have overlap, but it's not a small difference. When you actually get down to real rust codebases, they end up pretty different even if they're heavy on traits. But again, there's nothing requiring you to use traits. You see them often in libraries because they are very useful for generic programming. But that doesn't mean you are forced to use them in your application code.

You are making the mistake to confuse inheritance with class inheritance.

There is also interface inheritance, which Rust allows for with trait bounds composition, now made even easier with trait upcasting.

With some macro help, one can even do COM style of multiple interface implementation with aggregation and delegation, to simulate class inheritance, like ATL allows for with template metaprogramming.

Rust doesn't have interface inheritance either.

Rust only has composition in this regard. Calling it inheritance in any way is just confusing terminology.

I never said multiple inheritance.

Multiple inheritance and SFINAE through templates are the only non-concept way of doing traits in C++

The way single inheritance is used in C++ is nothing like how traits are used in Rust.

Reply on news.ycombinator.com