thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duru Can Celasun (Jira)" <>
Subject [jira] [Commented] (THRIFT-5209) WIP: Support TinyGo
Date Thu, 14 May 2020 06:54:00 GMT


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|].
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
which tests every language against every other language.

- Server support. Are you planning to support servers or just clients? Servers implement [TServerTransport|]
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:
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Go - Compiler, Go - Library
>            Reporter: Benjamin Gould
>            Priority: Minor
> TinyGo ([] 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: []
> 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 - []
>  # 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:
> 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

View raw message