Brad,
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:
> (...)
> Assuming this actually worked, it might considerably lower the bar for
> adopting Go, and allow it to be used to dev
On Saturday, March 25, 2017 at 4:32:20 AM UTC+1, Brad wrote:
>
> Interested in any feedback about the idea of making a Go -> C++
> transpiler. []
>
A very important point it to get a precise multi-threaded garbage collector
in C++. This is painfully difficult, and if you succeed (perhaps b
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
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 an
Probably a weird and orthogonal suggestion : transpile go-->rust and
eliminate the gc overhead without dealing with the horrible syntax, if that
is even feasible..
>
> 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++
Thanks, yes I'm casually familiar with both projects but will dig deeper.
It's true that some big parts of what I'm describing have already been
done, targeting other languages.
On Monday, March 27, 2017 at 6:42:27 PM UTC-7, Andrew Chambers wrote:
>
> I suggest looking at the prior art of gophe
I suggest looking at the prior art of gopherjs and Elliot stonehams haxe
based transpiler.
On 28/03/2017 2:19 PM, "Brad" 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
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
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 compi
> it might considerably lower the bar for adopting Go
I think Go as a language and the tooling make the bar quite low already. With a
small time investment it becomes a very productive language for most developers.
Choosing a project which makes sense to completely write in Go, and sharing
tha
I think it's a fine idea. For a decade C++ was actually compiled to C, via
cfront. It well past time that Go returns the favour.
This would also help flush out a lot of unspoken assumptions about what a Go
program requires from the underlying operating system.
--
You received this message bec
My thought was that the translation would be one-way - you would avoid
hacking on the C++ part unless you were completely abandoning the Go part.
I see the point on the disparity between what it would take to migrate a
project to Go vs the effort to build such a project. Although part of my
mo
On Sat, 25 Mar 2017 03:49:55 -0700 (PDT)
andrewchambe...@gmail.com wrote:
> Its a bad idea for many reasons.
>
> - The actual implementation is harder than convincing someone to just
> use the official Go compiler.
> - Some features don't map cleanly to C++
> - C++ programmers won't like it, and
Its a bad idea for many reasons.
- The actual implementation is harder than convincing someone to just use
the official Go compiler.
- Some features don't map cleanly to C++
- C++ programmers won't like it, and neither will go programmers.
- Nobody will fund the maintenance of this compiler and i
14 matches
Mail list logo
