Graal: Golang Support

[joegrasse]

Will Go be supported in the future?

[thomaswue]

It could be possible via a Go => LLVM => GraalVM bridge. There is this project https://go.googlesource.com/gollvm/ and this project https://github.com/go-llvm/llgo. The former looks more up-to-date. We will investigate what it takes.

[eginez]

For what is worth I tried running lli with https://github.com/go-llvm/llgo and found that lli was failing to load some of the native libraries. I created a docker image that can be used for testing docker pull eginez/graalgo, fair warning is a big image(~17Gb)

[lukasstadler]

Yes, the relationship between the gollvm-created bitcode and the Go runtime library is somewhat special - FWIW, even llvm's own "lli" seems to be unable to handle it.
We're looking into various ways to make that work, we may need to introduce a special hook for Go code.

[chengenzhao]

If bitcode way is not working, well maybe not that perfect
is it this project helpful?
https://github.com/PDZaninov/GoLang-Compiler
TruffleGoLang-Compiler
Contributors: Baiwen Huang, Kyle Remmert, Petar Zaninovich, Trevor Ching, Vincent Kim

This is a student project done for Oracle for CMPS 116/117 at UCSC.

Oracle’s Multilingual Engine (MLE) allows multiple languages to freely interoperate. This enables users to work with a language of their choosing when working with Oracle’s database products. The MLE relies upon the Truffle framework and Truffle languages to execute source code within the database process space. The goal of this project was to incorporate a subset of Go into Truffle’s suite of languages.

[CAFxX]

It could be possible via a Go => LLVM => GraalVM bridge.

Wouldn't going through truffle be better than LLVM in this case? Compiled Go programs contain a pretty big/multithreaded runtime (including a user-mode scheduler tightly integrated with the garbage collector and the built-in I/O event loop) that would need to run on top of the graal runtime. Even if suboptimal going the LLVM way may work at least in simple cases (footgun number one is likely going to be the presence of two GCs) but it would be pretty unusable for anything non-trivial involving cross-language interop (that would also depend on cgo, since there's no other supported way of doing interop with the standard go runtime). With a "trufflego" approach these issues wouldn't apply - although it would require signifcant work to get them right.

(I'm gleefully glossing over the fact that going with truffle would require reimplementing a significant part of the runtime, as well as a Go interpreter -- and that therefore the amount of work is not even remotely comparable)

[eginez]

golang is about release a compiler that can target wasm, I wonder if we could use that target and load it through graaljs and have that be the interop channel with java

[ScalaWilliam]

I'm interested in this.

[psanders]

Same here!

[thomaswue]

We did get more requests for this feature recently. If anybody has some concrete example scenarios in mind for running Go on GraalVM; e.g., what would be the main expected benefits (interoperability? performance? tooling?), please share.

[chengenzhao]

We did get more requests for this feature recently. If anybody has some concrete example scenarios in mind for running Go on GraalVM; e.g., what would be the main expected benefits (interoperability? performance? tooling?), please share.

We do have an example
currently we are using Vert.X toolkit and we hope we could use Goroutine in the verticle just like Kotlin Coroutine, which will make async code relatively easy to write.
For Kotlin Coroutine, we have to launch the coroutine scope, but in Golang, we dont have to do that, we could go keywork to simplify the async code, Java has similar feature which is Project Loom but it takes time to complete, so if we could write the code in Golang then the vertx-lang-golang/go4x would be a perfect match in this scenario.

[chengenzhao]

Vert.X has a language support based on Graal, which is es4x project
https://reactiverse.io/es4x/
and we could create similar projects to use Golang e.g. go4x
we do have many people experienced in vertx-codegen tool
so if Graal could run Go language, we could generate vertx-lang-go/go4x to wrap vertx apis
and provide these apis to Go users, for now, about green thread/fiber/coroutine etc.
Golang is the easiest way to write, we could benefits from this feature
A similar scenario is Kotlin Coroutine support which makes Kotlin code easy to write in Vert.x
e.g.
https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/
so we could generate a similar feature for Vert.X

[marcellanz]

We did get more requests for this feature recently. If anybody has some concrete example scenarios in mind for running Go on GraalVM; e.g., what would be the main expected benefits (interoperability? performance? tooling?), please share.

@thomaswue it would lower the bar entering go applications in environments where the JVM is traditionally established, both by expertise, tooling and its operational foundation. think about companies that restrict their decision to use a language if it runs on the JVM.

[eginez]

I think a killer use case is just to leverage libraries written in Java from Go and viceversa. The java ecosystem is very rich in the open source as well as within corporations. Allowing people to run software in go(or java) without having to re-implement well tested libraries would be key feature for graalvm. This is specially true given go is gaining grounds as a backend language.

[joegrasse]

My use case, and the reason I opened the original issue, was so that I can use Go to write stored programs in MySQL, instead of javascript.

[eginez]

Here is an experimental solution I was playing: https://gist.github.com/eginez/d69e3e1c4045eb692a274bd2bd5d31d6

[thomaswue]

How does this tre project compare to https://go.googlesource.com/gollvm/? I see that this was discussed further up. It seems still like this gollvm project could be a more solid way to create llvm bit code from go.

[eginez]

agreed the above post is demonstrative only

[spangaer]

Being able to parse a terraform script in to JVM using it's original parser implementation would be a nice use case.
;)

[eginez]

The support for WASM in GraalVM opens yet another door to run go in the GraalVM. This time through go's wasm backend.