How does this compare to "Accept interfaces, return structs" in Go?

Posted Apr 25, 2024 16:14 UTC (Thu) by davecb (subscriber, #1574)
In reply to: How does this compare to "Accept interfaces, return structs" in Go? by rds
Parent article: Existential types in Rust

Yes, it does

to post comments

How does this compare to "Accept interfaces, return structs" in Go?

Posted Apr 26, 2024 0:56 UTC (Fri) by wahern (subscriber, #37304) [Link] (1 responses)

> > Yes, but does it resolve the interfaces to a specific instance type at compile time? The article states that Rust does/will do this.
>
> Yes, it does

This doesn't sound right with respect to either Go or Rust. In Go interfaces are statically resolved to concrete types only opportunistically. It can't always do this because a function might choose which concrete implementation to return based on runtime logic.

IIUC, the same is true of Rust. In Rust you can return a `impl Trait` directly only if there's a single concrete implementation it could possibly return, otherwise it has to be boxed. Named existential type are just as strict: a named existential type can only have a single concrete implementation, period. The concrete type appears to be inferred from the usage context, but IIUC if the second context can't be coerced to the same concrete type as in the first context, then compilation will fail.

It couldn't be any other way, at least as a practical matter. (Though I could imagine a system of symbolic execution where the compiler generates code for all the alternations, but if you thought compile times were crazy now....) People seem to get all exited about various Rust features based on the fancy technical jargon and assume Rust is performing something magical. But people's memories are short, apparently. IIUC, existential types here are quite useful largely as a syntactic sugar when writing implementations, but otherwise more a boon to the compiler in circumscribing the complexity of the type resolution expected of it. The hype over what it offers async code seems overblown; it's not going to magically make opaque interface-like types with multiple distinct concrete implementations magically statically dispatchable when they're returned from a function which could return one or the other dynamically.

How does this compare to "Accept interfaces, return structs" in Go?

Posted Apr 26, 2024 13:56 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Yeah, I think this feature in Go promises only for example T = ∀X { a: X; f: (X → int); } whereas in Rust you're promised T = ∃X { a: X; f: (X → int); }

That is, in Go they're saying this has *any* type which has the specified property and it might vary, while in Rust we're saying that while we won't tell you what type it is, we promise there is *some* specific type which has that property.

The Rust compiler will learn what that type is, but it doesn't need to spell it, for the compiler this being "the type you get when you compile the closure on line #124 of this file" is fine, it's type #10295 but humans want names, both in terms of being able to understand what's going on, and in Rust because they are literally required by the language to spell the name of a type in the function signature, so hence without Existential types you cannot do this in Rust.

In C++ you don't have to spell names of types in most places, you can talk about types in terms of other things, for example decltype(a + b) is just "The type of the result if you were adding a and b together" but they still have the same distinction Rust has and for the same reason - it's expensive to handle that any type case, in a language like Go it's no cheaper when this happen but you're used to the language just not telling you the price of anything - it's girl menus at a posh restaurant, is the salad cheaper than the lobster? Who knows, the prices are on the menu the guy has.