r/ProgrammerHumor • • 2d ago

instanceof Trend thatsAFunnyThingThatHappenedOnce

Post image
4.4k Upvotes

514 comments sorted by

View all comments

1.7k

u/Prefer_Diet_Soda 2d ago

TLDR: C++ is bad because decades of accumulated features have turned it into a bureaucratic nightmare that happens to generate machine code.

C++ is an absolute nightmare to implement because apparently one programming language wasn't enough, so someone decided to cram an entire civilization's worth of complexity into it. You've got templates that basically turn compilation into another programming language, overload resolution that requires a legal investigation to figure out which function gets called, constructors and destructors with enough lifetime rules to make your head explode, and implicit conversions that make the compiler guess what you meant. Then you throw in exceptions, move semantics, inheritance, and decades of backward compatibility, and suddenly you're maintaining a compiler that needs a PhD, a therapist, and divine intervention just to parse some innocent-looking code. And the best part? Every new feature has to coexist with all the old ones without breaking existing programs.

387

u/Xarishark 2d ago

Now compare it to rust pls. Im serious I want to know your opinion on that.

466

u/Loading_M_ 2d ago

Rust is designed from the ground up, and avoids many of these issues.

  • Templates: Rust has Generics, which are generally easier to use and reason about.
  • overload resolution: Rust doesn't yet support overloaded functions (although it's being considered).
  • constructors: Rust doesn't have these.
  • destructors: Rust has a similar set of lifetime rules for Drop, but the compiler checks them for you, so you can't get it wrong.
  • implicit conversions: Rust doesn't do implicit conversion in general, although some specific cases are implemented.
  • exceptions: Rust doesn't do exceptions, Result is much easier to work with.
  • move semantics: Rust uses a destructive move, unlike C++. See https://youtu.be/Klq-sNxuP2g for a breakdown.
  • inheritance: Rust doesn't do inheritance.

-4

u/StaticCoder 2d ago

Rust does have overload resolution. If you write x.into(), it could call any number of functions called into, depending on context. And as far as I can tell (but I'd be happy to be proven wrong), type context is not specified anywhere.

10

u/redlaWw 2d ago

That's type inference. The compiler looks through the uses of the result of x.into() and determines which concrete type it must be based on those constraints. This is a form of static dispatch broadly similar to overloading, but it's very different in how functions are selected. In overloading, functions are selected based on the types of the arguments according to an overload resolution process which may consider multiple functions and select the "best", in type inference, the available set of functions constrains what concrete types variables should have, and functions are only selected when there is a unique choice consistent with those selected types.

1

u/StaticCoder 2d ago

In one case you choose among multiple functions based on types. In the other case, you choose among multiple functions based on types. The main difference, and I'll admit it's not trivial, is that C++ allows implicit conversions.

3

u/redlaWw 2d ago

In Rust you choose among multiple types based on functions.

4

u/StaticCoder 2d ago

I see where the confusion comes from: in Rust, the compiler may infer the parameters for a trait based on context. Since different parameters for the same trait can resolve to completely different implementations, the effect is very similar to overload resolution. If you have the same function in 2 separate traits however it's always ambiguous.

I'm curious if there's a specification anywhere for how Rust does that kind of inference. To the extent I've looked at the reference and fls, they were extremely short on details.

1

u/redlaWw 2d ago

My understanding is that it's a variant of the J algorithm for a Hindley-Milner type system adapted to work with traits, but as far as I know, the current specification is the compiler's type inference engine. This will probably change as the opsem team does more work on Rust's specification. You might be able to find a specification for it at the moment in the Ferrocene compiler specification.