[
https://issues.apache.org/jira/browse/THRIFT-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17106975#comment-17106975
]
Duru Can Celasun commented on THRIFT-5209:
------------------------------------------
I'm generally open to this sort of addition to Thrift's Go support and the diff
so far seems small enough to not create any maintenance headaches.
That said, I do have a few concerns:
- The transports and protocols supported for Go with the gc compiler is listed
[here|https://github.com/apache/thrift/blob/26e6c84cde490a22d39c43ba3903dd94bbb8497f/LANGUAGES.md].
Since TinyGo can't support all of them, it will need a separate entry on that
table.
- Tests. There are tests that use encoding/json. These will either have to be
updated, or have separate TinyGo versions guarded by build tags.
- Continuous Integration. TinyGo must be added to the Travis CI config and must
support [cross
tests|https://github.com/apache/thrift/tree/master/test#apache-thrift---integration-test-suite]
which tests every language against every other language.
- Server support. Are you planning to support servers or just clients? Servers
implement
[TServerTransport|https://github.com/apache/thrift/blob/26e6c84cde490a22d39c43ba3903dd94bbb8497f/lib/go/thrift/server_transport.go#L23-L34]
and usually depend on net.
> Personally I think I would lean toward using the "Android" model I described
> above with a single generator/library using a compiler option and build
> flags, respectively.
I agree.
> WIP: Support TinyGo
> -------------------
>
> Key: THRIFT-5209
> URL: https://issues.apache.org/jira/browse/THRIFT-5209
> Project: Thrift
> Issue Type: New Feature
> Components: Go - Compiler, Go - Library
> Reporter: Benjamin Gould
> Priority: Minor
>
> TinyGo ([https://tinygo.org/)] provides a compiler for the Go programming
> language that is an alternative to the standard Go compiler and is based on
> LLVM. It uses the standard Go toolchain to compile programs to Go's SSA
> format, and then translates the SSA to LLVM IR that can subsequently be
> compiled for various microcontrollers, wasm, or Linux. The important
> takeaway from that explanation is that since TinyGo programs use the standard
> Go compiler for the compiler frontend, is not is a subset of the Go language
> - it is the same language, with some small caveats.
> The main caveat as far as Thrift support is concerned is that not all
> packages in the standard library are supported yet, including the {{net}} and
> {{encoding/json}} packages. This presents an obvious problem for using
> Thrift, since these packages are imported by the Thrift Go library.
> Additionally, some small tweaks to the code from the compiler are necessary
> to work around limited support for the {{reflect}} and {{database/sql
> packages}}.
> In general, Thrift can work with TinyGo, but until TinyGo gains more complete
> support for the standard library it does require a compiler flag and
> excluding a number of features of the Thrift Go library.
> Initial support for TinyGo is found here:
> [https://github.com/bgould/thrift/tree/fc2f380a2a390860160df851e9a9698f8e3c66f4]
> However I have the following questions about the best way to proceed:
> # Should TinyGo support be implemented in the compiler via a flag on the Go
> generator that eliminates references to packages unsupported by TinyGo such
> as reflect and database/sql from the generated code? This would be similar
> in concept I think to the -android option to the Java generator.
> Alternatively, should a separate generator altogether be added, in the same
> way that Java and JavaME are separate generators in Thrift? For reference,
> the scope of the changes to the Go generator for supporting TinyGo are
> roughly this -
> [https://github.com/bgould/thrift/commit/f1a57bf94731a262b68d5a519bcbbb4c8c303a23#diff-36ef31e670e3df20e286373dfb7ecc23]
> # Similarly, the changes in the Thrift library can mostly be implemented by
> adding build tags to exclude unsupported transports etc when compiling for
> TinyGo (the TinyGo compiler sets a {{tinygo}} build tag automatically for all
> TinyGo builds). It would also be feasible to maintain a separate library
> that is explicitly compatible with TinyGo. Again, the analogy of the
> distinction between Java/Android and Java/JavaME applies here I think. The
> sorts of changes necessary are like this:
> https://github.com/bgould/thrift/commit/f1a57bf94731a262b68d5a519bcbbb4c8c303a23#diff-90f0f50bdfa55c6a4a1d53580c103ae0
> The main reason I am asking these questions is that I would really like to
> land this feature, and the same time want to make sure it does not create
> undue burden on Thrift maintainers working on supporting the standard Go
> implementation. Personally I think I would lean toward using the "Android"
> model I described above with a single generator/library using a compiler
> option and build flags, respectively. You opinion and feedback are of course
> greatly appreciated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
