Among the improvements are the ability to inspect goroutines and to print native Go data types, including structs, slices, strings, maps, interfaces, and channels.
To learn more about Go and GDB, see the Debugging with GDB article.
Sunday, October 30, 2011
Debugging Go programs with the GNU Debugger
Last year we reported that Go's gc/ld toolchain produces DWARFv3 debugging information that can be read by the GNU Debugger (GDB). Since then, work has continued steadily on improving support for debugging Go code with GDB.
Tuesday, October 11, 2011
Go App Engine SDK 1.5.5 released
Today we released version 1.5.5 the Go App Engine SDK. You can download it from the App Engine downloads page.
This release includes changes and improvements to the App Engine APIs and brings the supporting Go tool chain to release.r60.2 (the current stable release). Also included in this release are the godoc, gofmt, and gofix tools from the Go tool chain. They can be found in the root directory of the SDK.
Some changes made in this release are backwards-incompatible, so we have incremented the SDK api_version to 3. Existing apps will require code changes when migrating to api_version 3.
The gofix tool that ships with the SDK has been customized with App Engine-specific modules. It can be used to automatically update Go apps to work with the latest appengine packages and the updated Go standard library. To update your apps, run:
/path/to/sdk/gofix /path/to/your/app
The SDK now includes the appengine package source code, so you can use the local godoc to read App Engine API documentation:
/path/to/sdk/godoc appengine/datastore Get
Important note: We have deprecated api_version 2. Go apps that use api_version 2 will stop working after 16 December 2011. Please update your apps to use api_version 3 before then.
See the release notes for a full list of changes. Please direct any questions about the new SDK to the Go App Engine discussion group.
Wednesday, October 5, 2011
A preview of Go version 1
We want to be able to provide a stable base for people using Go. People should be able to write Go programs and expect that they will continue to compile and run without change, on a timescale of years. Similarly, people should be able to write books about Go, be able to say which version of Go the book is describing, and have that version number still be meaningful much later. None of these properties is true for Go today.
We propose to issue a Go release early next year that will be called “Go version 1”, Go 1 for short, that will be the first Go release to be stable in this way. Code that compiles in Go version 1 should, with few exceptions, continue to compile throughout the lifetime of that version, as we issue updates and bug fixes such as Go version 1.1, 1.2, and so on. It will also be maintained with fixes for bugs and security flaws even as other versions may evolve. Also, production environments such as Google App Engine will support it for an extended time.
Go version 1 will be a stable language with stable libraries. Other than critical fixes, changes made to the library and packages for versions 1.1, 1.2 and so on may add functionality but will not break existing Go version 1 programs.
Our goal is for Go 1 to be a stable version of today’s Go, not a wholesale rethinking of the language. In particular, we are explicitly resisting any efforts to design new language features “by committee.”
However, there are various changes to the Go language and packages that we have intended for some time and prototyped but have not deployed yet, primarily because they are significant and backwards-incompatible. If Go 1 is to be long-lasting, it is important that we plan, announce, implement, and test these changes as part of the preparation of Go 1, rather than delay them until after it is released and thereby introduce divergence that contradicts our goals.
Today, we are publishing our preliminary plan for Go 1 for feedback from the Go community. If you have feedback, please reply to the thread on the golang-nuts mailing list.
We propose to issue a Go release early next year that will be called “Go version 1”, Go 1 for short, that will be the first Go release to be stable in this way. Code that compiles in Go version 1 should, with few exceptions, continue to compile throughout the lifetime of that version, as we issue updates and bug fixes such as Go version 1.1, 1.2, and so on. It will also be maintained with fixes for bugs and security flaws even as other versions may evolve. Also, production environments such as Google App Engine will support it for an extended time.
Go version 1 will be a stable language with stable libraries. Other than critical fixes, changes made to the library and packages for versions 1.1, 1.2 and so on may add functionality but will not break existing Go version 1 programs.
Our goal is for Go 1 to be a stable version of today’s Go, not a wholesale rethinking of the language. In particular, we are explicitly resisting any efforts to design new language features “by committee.”
However, there are various changes to the Go language and packages that we have intended for some time and prototyped but have not deployed yet, primarily because they are significant and backwards-incompatible. If Go 1 is to be long-lasting, it is important that we plan, announce, implement, and test these changes as part of the preparation of Go 1, rather than delay them until after it is released and thereby introduce divergence that contradicts our goals.
Today, we are publishing our preliminary plan for Go 1 for feedback from the Go community. If you have feedback, please reply to the thread on the golang-nuts mailing list.
Tuesday, October 4, 2011
Learn Go from your browser
We are excited to announce A Tour of Go, a guided tour of the Go programming language you can run from your browser.
The tour is hands-on, demonstrating the language through code samples that you can modify, compile, and run from the tour itself. (The technology behind the Go Playground does the work.)
The tour has three sections. The first section covers basic syntax and data structures; the second discusses methods and interfaces; and the third introduces Go's concurrency primitives. Each section concludes with a few exercises so you can practice what you've learned.
So, what are you waiting for? Get started now!
The tour is hands-on, demonstrating the language through code samples that you can modify, compile, and run from the tour itself. (The technology behind the Go Playground does the work.)
The tour has three sections. The first section covers basic syntax and data structures; the second discusses methods and interfaces; and the third introduces Go's concurrency primitives. Each section concludes with a few exercises so you can practice what you've learned.
So, what are you waiting for? Get started now!
Subscribe to:
Posts (Atom)
