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.
