Doesn't match Google Go

I’m trying to understand what Elements-Go is.

I put a simple Go program into Water, compiling to CLR, and the output is not correct.

package RemTest1

import (
“fmt”
)

type User struct {
name String
}

func (user User) String() String {
return fmt.Sprintf(“User: name = %s”, user.name)
}

func main() {
user := User{name: “foo”}
fmt.Println(user) // User: name = foo
}

In Google Go, this program outputs “User: name = foo”

In Water, compiling for CLR, this program outputs “{foo}”

I’m not exactly surprised by this, because CLR doesn’t support row polymorphic structural typing, but what is happening here is not Google Go. It seems more like a transpiler that maps Go constructs into CLR objects that behave like CLR objects, not Go objects (which is not going to work to actually run existing Go code).

Which begs the question… What is the goal of Elements-Go?

Is it intending to be compatible with Google Go? And if so, why doesn’t this simple program work? (i.e. seems like you should have some basic structural typing test cases)

And if it’s not intending to be compatible with Google Go, what is it for?

One way to make Go objects run correctly on CLR might be to declare all the types “dynamic” and let CLR do dynamic dispatch. That would create the duck-type like behavior of structural-subtyping. Though given that the above simple program doesn’t work like Go, I’m suspicious of whether the Elements Go compiler is doing Go compatible row-polymorphic structural type-inference.

You can see my broader related question here…

I’ll need to have someone form the compiler team to have a look at this one Monday; On first sight (but i’m not the Go expert, myself), this looks like it should work. It seem that String() maybe does not correctly get mapped to .NET’s .ToString() under the hood, but we’ll have to see. Thanx for reporting this!

—marc

Thanks, logged as bugs://84311