I see what you're saying. One unfortunate thing about this approach is that it doesn't help in cases where the Go runtime isn't supported/ported.
I'm thinking of embedded environments as an example - to implement garbage collection probably requires a very careful approach and something custom for the specific platform in question. For this example of garbage collection (and each facet needs it's own consideration - reflection, scheduling, etc.), on more "normal" platforms it could work to either a) use Go's garbage collector, or b) use one of various standalone garbage collection libraries, e.g. http://tinygc.sourceforge.net/ Whereas in the embedded environment you may want a completely different implementation. My thought on how this would end up going would be to translate code like this: example.go: type SimpleStruct struct { A int } func doSomething() { ss := &SimpleStruct{} // something happens here to force heap allocation above, instead of stack } gets translated into something like: example.c: typedef { int A; } SimpleStruct; void doSomething() { SimpleStruct *ss = ZERO(HEAP_ALLOCATE(SimpleStruct)); } The idea being that HEAP_ALLOCATE is a macro and can has a definition somewhere that is environment-specific and swappable. I'm not familiar enough with the guts of the Go runtime to know what it would take to implement that macro by calling into the Go RT. On Thursday, March 30, 2017 at 8:06:24 PM UTC-7, mura wrote: > > Just thought about maybe this could be used to generate the C header and > source files for C binding. > > Currently we have to write a hybrid language called cgo for FFI. It's not > always the best approach. > I'd like to have a C header that can be included to implement a 'driver' > for the Go runtime and using the driver as a bridge to the system shared > libraries. > > And then the complicated stuff for Go <-> C could probably be removed from > the runtime and delegate to the C driver. > > > 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.
