On Thu, Mar 10, 2016 at 6:52 PM, Nigel Tao wrote:
On Fri, Mar 11, 2016 at 6:34 AM, wrote:
On Thursday, 10 March 2016 11:22:22 UTC+1, minux wrote:
1. some environment, for example, App Engine, forbid using assembly,
Could you elaborate - how is that a drawback? That is a choice that makes
sense for the App Engine, but it doesn't really affect other platforms.
I think what Minux is trying to say is that, if package foo uses
assembly (and the author doesn't remember to use e.g. an appengine
build tag), then a Go App Engine app can't use package foo. That is
transitive - if I have a Go application that I'd like to run both on
and off App Engine, and I import package bar, which imports package
qux, which imports foo, then again, the magic of "go get" is broken.

Sure, the standard library is provided on App Engine, rather than
brung along with the app code, but it means that, if I can think of a
new feature, a bug fix, or optimization to make to flate, then I can't
simply fork the flate package and change an import path.
I'm not at all worried about this. It's easy to add the appengine tags,
like Klaus already has in his fork of compress/flate (
https://github.com/klauspost/compress/blob/master/flate/crc32_amd64.s for


You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 11 | next ›
Discussion Overview
groupgolang-dev @
postedMar 10, '16 at 10:22a
activeMar 11, '16 at 9:27p



site design / logo © 2021 Grokbase