our current plan covers two main scopes:
on all platforms, have full support for the Go language syntax, 100% compatible with standard Go. IOW, any Go code (that dopes not depend on libraries/APIs) should compile as-is, for .NET, JVM, Cocoa and all Island platforms.
for a subset of platforms (plan is, .NET and Island except WebAssembly) — because of runtime limitations there), have the full standard Go library compile and thus be available. IOW, literally any standard Go code (including code that sues Go APIs) should compile and work, as is, on .NET, Cocoa and most Island platforms.
Our main end goal is exactly that it will be possible to b ring in existing libraries implemented in Go, and re-use them transparently from the other Elements languages (be it directly, or omg some cases wrapped in Elements RTL abstractions (e.g. one could imagine Elements RTL’s HTTP class to use a standard Go HTTP implementation under the hood, form platforms where there’s no OS-native one we can use).
As for Go projects, in general, you’ll be able to do write “the same kind of” projects you’d write in standard Go. Of course you can use all the platform native APIs from Gold — eg on .NET you have full access to the .NET framework, you can new cup a WPF form, or whatever your heart desires). But (at least as of right now), we’re. not planning to make the drastic extensions to Go that’d be needed to actually write GUI apps (eg WinForms, WPF, AppKit/UIKit, Android) in pure Go, since — as you noticed — we’d need to add support to only for properties, events and such “small” stuff, b ut we’d also need to add support for classes.
I’m not saying that’s off the table indefinitely, but right now, that’s our focus is Go compatibility and the ability to use existing Go code (and write Go-style code) in projects. Be that using a library you found somewhere, or writing a new algorithm in Go yourself because you think it’ll be easier in that language. But you won’t be writing your UIViewControllers in Go, just yet.
Does that make sense?
Note that part (1) should be fully functional (albeit of course on “beta” level) in 2349, for all platforms (and feedback appreciated). For part (2), there’s still some ways to go, but we can probably open the library on GitHub up to early testers soon (especially if they’d be willing to contribute to getting it solid ;).