My thought was that the translation would be one-way - you would avoid hacking on the C++ part unless you were completely abandoning the Go part.
I see the point on the disparity between what it would take to migrate a project to Go vs the effort to build such a project. Although part of my motivation here is the potential for running a subset of the Go language in an environment where it otherwise won't be supported. That said, the more I look through the Go lang spec it becomes apparent that, yes, some really important features don't map to C++ well at all (or could require significantly different implementations in different environments). Garbage collection (or an alternative like reference counting), inline functions/closures, channels, etc. It gets pretty crazy pretty quick. And leaving those out would dramatically cut down the amount Go code that would convert correctly, thus largely defeating the purpose. On Saturday, March 25, 2017 at 4:08:55 AM UTC-7, Konstantin Khomoutov wrote: > > On Sat, 25 Mar 2017 03:49:55 -0700 (PDT) > andrewc...@gmail.com <javascript:> wrote: > > > Its a bad idea for many reasons. > > > > - The actual implementation is harder than convincing someone to just > > use the official Go compiler. > > - Some features don't map cleanly to C++ > > - C++ programmers won't like it, and neither will go programmers. > > - Nobody will fund the maintenance of this compiler and it will > > quickly be abandoned. > > There's also the problem of the conversion being one-way: if a C++ > programmer spots an error in the generated code, it has to be traced > back to the Go source, be fixed there and the C++ code re-generated. > (And the another problem is that like with many "transpilers", a tiny > change in the source might trigger swaths of changes in the generated > content. And this also hints at that only the "reference" code base > could be sensibly version-controlled.). > > So this approach is OK for cases like Facebook having been transpiling > their PHP to C++ (because no one is supposed to hack on the generated > code base -- just compile it and run), but much less so for having > programmers hacking "on both sides" of the codebase. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
