A ANSI-C (probably with GNU extension if helpful) transpiler/backend would
be much more useful than a C++ one.
C is far more widespread and easier to integrate. C *and* C++ projects can
both integrate C source. But C projects cannot integrate C++ source.
The users who want to build the gc compiler from source could use the C
output to bootstrap it, instead of installing Go 1.4.x or another binary
release. It's more likely that a system happens to have a C compiler
installed.
On Saturday, March 25, 2017 at 11:32:20 AM UTC+8, 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.
