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 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.
