Benjamin Gould created THRIFT-5209:
--------------------------------------

             Summary: 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


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)

Reply via email to