Sorry.
I mean do not bother providing a gccgo variant of the go runtime. Stick
with the official golang compiler at 1.11. I don't see the small speedup
in init time as being enough to justify supporting two variants of go
actions.
--dave
Michele Sciabarra wrote on 12/11/2018 10:37:56 AM:
Let’s stick with the 1.11 stock compiler, produces greater portability abs
allows us to make updates to the base linux image with low risk for braking
an exec built previously
Not worth for the init, in general a busy app doesn’t suffer a lot of cold
start and on the flip side a infrequent app
I am perfectly fine if we do not provide a gccgo runtime, it was not a big
work, and I did it to see if it is possible to generate small executables also
for go, since the swift one is very small.
Aside from the fact that actionloop-gccgo-v1.10 is the faster runtime both in
run and init time
Sorry not sure what you mean. Do you suggest I apply the change to use
gccgo in the official runtime, even if it is stuck at go 1.10 (the
latest is go 1.11) or I drop the idea of providing another runtime that
is faster to initialize? Would not be better to release both a gccgo
1.10 and a golang
In order to address confusion immediately, I created a section named
"Developer builds" and set about to create unambiguous text to position
these as unofficial "nightly" (or interim) builds with no status, as well
as rename the current "Releases" as "Official Releases" and augmented its
text
Hello all,
I was concerned about the fact that the Go runtime is a bit slow at init time.
As I suspected, the problem is in the size of the executable, that is almost
2Mb. This is structural for Go since it compiles statically.
Then I created a variant of the go runtime, using GccGo. GccGo is
