Regarding your announcement about Gold. It’s not clear in what direction your development will going.
Are you plan to extend Go language to be able making frontend GUI applications? In that case, we need inheritance, properties, and events in Go.
Or your plan is to enable go libraries in “Island”? In that way, we will able to use these libraries with other languages, but we need channels, go-routines and go style interfaces in Oxygene and other languages to be able to use these libraries.
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 ;).
Yeah, I’ll make sure this get added for the next build. Workaround fr the meantime, the projects are the same for both IDEs, so you can just create a project in Water and then one int in VS for further work. You can also just create an Oxygene project in VS and rename the .pas file to .go, as well.