Go Roadmap?
Carl
current? Any chance of getting an update?
State-of-the-art garbage collector and a debugger, that would be cool.
Will they become available for all Go compilers when they are done?
Are there any tentative projected availability dates?
comments:
When I wanted to do my first little program with Go, I immediately
missed a debugger, its somewhat of a hurdle to overcome.
Better optimization for Gc is important, but it might be less of a
priority if Gccgo was more feature complete, just a thought.
Native client would be very cool for obvious reasons, however ARM
support does not seem to be fully in the cards. Intels late Atom
offering could be the game changer for that one.
I think there will be many more people hunting around for an elegant
language that does not need some form of VM to run on, built from the
ground up for concurrency and Multi-core Architectures.
Cheers
chris dollin
> When I wanted to do my first little program with Go, I immediately
> missed a debugger, its somewhat of a hurdle to overcome.
What was your little program?
(Haven't felt any particular need for one so far, meanwhile am spitting
nails at the Eclipse Java debugger for distracting me with control-flow
details.)
Chris
--
Chris "allusive" Dollin
Evan Shaw
> I found the Roadmap on Golang.org under Resources. Is that still
> current? Any chance of getting an update?
It's a little out of date. There are some things on there that are done:
- Improved CGO including some mechanism for calling back from C to Go
- SWIG support
- Implement gccgo garbage collection (uses the same garbage collector as gc)
There's some work going on in the area of debugging. See
http://code.google.com/p/go/source/detail?r=c8c57ec793f3 (I don't know
exactly what this gives us; I haven't tried it out yet.)
- Evan
Scott Lawrence
> On 19 August 2010 16:10, Carl <2ca...@googlemail.com> wrote:
>
>> When I wanted to do my first little program with Go, I immediately
>> missed a debugger, its somewhat of a hurdle to overcome.
>
> What was your little program?
give tracebacks and pretty much the only thing I ever used gdb for was
tracking down segfaults.
> (Haven't felt any particular need for one so far, meanwhile am spitting
> nails at the Eclipse Java debugger for distracting me with control-flow
> details.)
Ugh... please don't remind me.
--
Scott Lawrence
Andrew Gerrand
> I found the Roadmap on Golang.org under Resources. Is that still
> current? Any chance of getting an update?
It's pretty accurate. SWIG support is pretty-much done. NaCl support works.
> State-of-the-art garbage collector and a debugger, that would be cool.
> Will they become available for all Go compilers when they are done?
The design of new garbage collector is underway, and will hopefully be
available for both 6g and gccgo when it's complete.
We're pretty close to having support using gdb on 6l-linked binaries.
> Are there any tentative projected availability dates?
No, sorry.
> Better optimization for Gc is important, but it might be less of a
> priority if Gccgo was more feature complete, just a thought.
Why so?
Andrew
Carl
Gccgo could do the optimization compilations, when needed for
deploying applications, it wouldn't matter much if it is slower on the
compiles at that stage. The rationale is that it is a lot of work and
requires deep skills to produce optimal code for each architecture its
an effort that does not necessarily have to be duplicated.