I suggest looking at the prior art of gopherjs and Elliot stonehams haxe
based transpiler.
On 28/03/2017 2:19 PM, "Brad" <bradgar...@gmail.com> wrote:
> Thanks for all feedback here. It sounds like while there are some
> significant caveats this could work and would have value. I think the big
> question is what are all these integration points that are provided by the
> Go runtime that are not available in a C/C++ environment and how big of a
> task is it to implement them (even if the implementations are initially
> much more naive than what Go has).
>
> I also think the case for going with C as opposed to C++ is pretty strong,
> I'll definitely look at that (architecturally it could be set up so that
> either could be plugged in but the odds of ever getting around to
> implementing the second language choice seem fairly low).
>
> I will try to find time to rough out some initial stuff on this and will
> post an update if I get something that looks promising.
>
> On Friday, March 24, 2017 at 8:32:20 PM UTC-7, Brad wrote:
>>
>> Interested in any feedback about the idea of making a Go -> C++
>> transpiler. Here's the rationale:
>>
>> * Go as a language has lots of awesome things that make it highly
>> productive. Lots of Gophers would love to use Go for more projects but
>> some common issues include:
>> * Trying to convince your team or management to adopt Go over a "more
>> traditional" language can be a tough sell: Your PHB is likely to tell you
>> it's not worth the risk, because the next developer he hires may not like
>> Go and he'll be screwed, whereas he knows he can find someone who will
>> write C++ or Java.
>> * And there is also the issue of the environments in which Go will run.
>> On embedded platforms (e.g. Parallax Propeller, Arduino) you can write C++,
>> but you're not going to get a Go compiler for it.
>> * There's also the fact in a scenario where Go co-exists with C or C++,
>> Go has to have the main function and has to build the executable. Unless
>> you build a shared library, you can't just start implementing parts of your
>> project in Go and gradually phase things over.
>>
>> It's also worth noting that some of these scenarios just will never
>> support all the features of the Go language, and so full support will not
>> happen. You probably won't get goroutines on an Arduino, for example. But,
>> that doesn't mean it wouldn't be useful to be able to write Go code in
>> these cases that doesn't use that feature and is otherwise 100% correct Go.
>>
>> So, what if the following existed:
>>
>> * Tool that converts Go to C++:
>> * Comments and formatting are preserved - the resulting C++ is readable.
>> You can tell your boss "there's no loss here - if this doesn't work, we'll
>> throw away the Go code and keep working on the C++", even though you know
>> you will burn in hell for doing that ;)
>> * Language constructs which have an obvious simple mapping are just
>> directly converted (byte -> uint8_t, structs are structs, etc.)
>> * Things that can be done with C++ code but are just ugly (e.g. defer,
>> implemented with goto) would be done like that - the transpiler would just
>> emit that code.
>> * Features that are syntactic sugar around runtime implementations are
>> emits as calls to a stripped down version of the runtime that just does the
>> bare minimum to support what's needed: e.g. maps and slices are implemented
>> with a C++ template - the template is the same one that is just dropped in
>> the output as "map.h" and the transpiler emits code that uses it.
>> * Heap allocations are mapped to a GC lib implemented in C++ - same as
>> maps above, just more complicated. Same with channels.
>> * Reflection could be done by emitting a bunch of type info and making
>> all that work, but probably wouldn't get around to doing this in a first
>> version.
>> * "go" gets mapped to pthread_create(), cognew() or whatever.
>> * As much as possible this things are kept as some sort of simple
>> template of the corresponding C++ code to output, so you can easily adjust
>> how allocations or "go" or whatever are emitted for a particular
>> environment.
>> * The standard library would probably need to be forked, the things that
>> are heavily intertwined with the Go runtime ("runtime", "reflection", etc.)
>> would probably just not be available initially, and the ones that can be
>> patched and transpiled would be, and then some would probably just need a
>> separate implementation in C++ (e.g. "sync"). There would be an obvious
>> way to do this and it would be a normal thing in this scenario to say:
>> "let's drop in an implementation of fmt that supports only the barebones
>> formatting for use on embedded systems", etc.
>> * Features/packages that are not supported would result in a transpiler
>> error. I.e. some things "you just can't do" with this tool and that's okay.
>>
>> Assuming this actually worked, it might considerably lower the bar for
>> adopting Go, and allow it to be used to develop in environments where we're
>> not likely to see a port of the compiler any time soon. (Or where it's
>> literally impossible because there are things in the language that the
>> platform just can't do.)
>>
>> I could potentially devote some time to building this out, but I wanted
>> to see if anyone had feedback on the concept. I realize it's not a simple
>> project, but with the above setup it could be implemented incrementally.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/eUnAY0-Reew/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
