5 ms·

Go 1.2 Release Candidate 1 released

76 points by babawere 13y ago

babawere 13y ago
It would be nice to see performance benchmark between 1.1 and 1.2
- igouy 13y ago
  So run your Go programs with 1.1 and with 1.2 and tell us if there's a difference.
drsintoma 13y ago
Has anyone tried the new scheduler? Does this still block forever? package main import "time" func main() { go func(){ for {} }() time.Sleep(time.Millisecond) }
- drsintoma 13y ago
  Ok, I just tried it. It still does.
- Skinney 13y ago
  That will still block forever. If you include a function call in the loop though, it won't.
- ominous_prime 13y ago
  while they have added some preemption to the scheduler, go is still generally cooperative multitasking. I believe function calls are also schedule points now. If you have a cpu-intensive loop you want to yield from at certain points, stick a runtime.GoSched in there. Having a busy-loop in your code is going to mess things up, and is usually a bug anyway.
  - masklinn 13y ago
    > Having a busy-loop in your code is going to mess things up, and is usually a bug anyway. A busy loop is a sufficient way to emulate a heavy computation (e.g. applying effects to image files or compressing data) when it's not optimized out.
knocte 13y ago
Whenever they fix the tremendous issue of errors being ignored by default, give me a call.
- MindTwister 13y ago
  Could you expand on this? I'm not sure I follow.
  - howeyc 13y ago
    I think what GP is getting at that if you call a function with one return value, you can ignore it by not assigning anything to the result of the function. http://play.golang.org/p/9J46QRHul1 http://play.golang.org/p/9J46QRHul1 They presumably would like to force you to use the return value if it is of type error.
    - MindTwister 13y ago
      Ah, got it. I thought it was way more sinister than that. On a side note, does any programming languages force you to use the return value of every function call?
      - Shish2k 13y ago
        Go forces you to either assign the return value to a variable and then use that variable, or pretend it doesn't exist at all. I think they were trying to get rid of the middle "assign it to a variable, deal with it later" case, to encourage people to write error-handling code there and then, but I've found that instead it pushes me towards completely ignoring error codes, then because there's no "unused variable 'errorCode'" warning, I forget to go back and robustify the code :( I probably /should/ get into the habit of writing error-handling code at the same time as writing the main-path code, but for someone who's just started learning the language and just wants to see what works, I find it really frustrating >_<
        sambeau 13y ago
Laremere 13y ago
> go/build: support including C++ code with cgo (CL 8248043). As someone who spent all of yesterday trying to figure out the best workaround for the lack of this functionality, I'm very happy to see this change.
srollyson 13y ago
I am so happy they decided to include comparison operators in text/template and html/template [1]. It drove me nuts to have to write comparison functions and call them from within the template. Yes, it kept some logic out of the template but in my opinion it added an unnecessary layer of indirection. [1]: http://tip.golang.org/doc/go1.2#text_template http://tip.golang.org/doc/go1.2#text_template
CoffeeDregs 13y ago
I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? Not being able to write a generic "map" function in a modern language seems very strange to me. edit: there's something "map"-ish here: https://code.google.com/p/go/source/browse/src/pkg/exp/iterable/iterable.go?r=1d1670229de33959691a343d716cfb32594bddbd https://code.google.com/p/go/source/browse/src/pkg/exp/itera...
- masklinn 13y ago
  > I really want to like Go Why? 4 years on seems a long enough time to come to term with what Go is.
- dragonwriter 13y ago
  > I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? As a language feature: not likely any sooner than Go 2.0, given everything that's been said on the issue, though I suppose if a way could be found to do generics that doesn't explode compilation time and doesn't involve syntax changes that would break any existing Go 1.x code, it might happen in a later 1.x release. Wouldn't hold my breath. Via a preprocessor? Its already a thing: https://github.com/droundy/gotgo https://github.com/droundy/gotgo
- bsg75 13y ago
  http://golang.org/doc/faq http://golang.org/doc/faq : "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." One of Go's goals is a certain level of simplicity. The above point seems to state that generics don't fit that goal, but they are not precluded from a future version. I take this to mean that since no language has every feature that anyone could possibly want, if generics are a requirement for your work, then Go does not fit the requirements. Some potentially relevant material here - http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.de/2012/06/less-is-exponential... : "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark."
patrickxb 13y ago
This is great: "Finally, an HTTP server will now serve HEAD requests transparently, without the need for special casing in handler code. While serving a HEAD request, writes to a Handler's ResponseWriter are absorbed by the Server and the client receives an empty body as required by the HTTP specification." Been waiting for this forever...

76 points by babawere 13y ago

babawere 13y ago

It would be nice to see performance benchmark between 1.1 and 1.2

igouy 13y ago
So run your Go programs with 1.1 and with 1.2 and tell us if there's a difference.

drsintoma 13y ago

Has anyone tried the new scheduler? Does this still block forever? package main import "time" func main() { go func(){ for {} }() time.Sleep(time.Millisecond) }

drsintoma 13y ago
Ok, I just tried it. It still does.
Skinney 13y ago
That will still block forever. If you include a function call in the loop though, it won't.
ominous_prime 13y ago
while they have added some preemption to the scheduler, go is still generally cooperative multitasking. I believe function calls are also schedule points now. If you have a cpu-intensive loop you want to yield from at certain points, stick a runtime.GoSched in there. Having a busy-loop in your code is going to mess things up, and is usually a bug anyway.
- masklinn 13y ago
  > Having a busy-loop in your code is going to mess things up, and is usually a bug anyway. A busy loop is a sufficient way to emulate a heavy computation (e.g. applying effects to image files or compressing data) when it's not optimized out.

knocte 13y ago

Whenever they fix the tremendous issue of errors being ignored by default, give me a call.

MindTwister 13y ago
Could you expand on this? I'm not sure I follow.
- howeyc 13y ago
  I think what GP is getting at that if you call a function with one return value, you can ignore it by not assigning anything to the result of the function. http://play.golang.org/p/9J46QRHul1 http://play.golang.org/p/9J46QRHul1 They presumably would like to force you to use the return value if it is of type error.
  - MindTwister 13y ago
    Ah, got it. I thought it was way more sinister than that. On a side note, does any programming languages force you to use the return value of every function call?
    - Shish2k 13y ago
      Go forces you to either assign the return value to a variable and then use that variable, or pretend it doesn't exist at all. I think they were trying to get rid of the middle "assign it to a variable, deal with it later" case, to encourage people to write error-handling code there and then, but I've found that instead it pushes me towards completely ignoring error codes, then because there's no "unused variable 'errorCode'" warning, I forget to go back and robustify the code :( I probably /should/ get into the habit of writing error-handling code at the same time as writing the main-path code, but for someone who's just started learning the language and just wants to see what works, I find it really frustrating >_<
      - sambeau 13y ago

Laremere 13y ago

> go/build: support including C++ code with cgo (CL 8248043). As someone who spent all of yesterday trying to figure out the best workaround for the lack of this functionality, I'm very happy to see this change.

srollyson 13y ago

I am so happy they decided to include comparison operators in text/template and html/template [1]. It drove me nuts to have to write comparison functions and call them from within the template. Yes, it kept some logic out of the template but in my opinion it added an unnecessary layer of indirection. [1]: http://tip.golang.org/doc/go1.2#text_template http://tip.golang.org/doc/go1.2#text_template

CoffeeDregs 13y ago

I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? Not being able to write a generic "map" function in a modern language seems very strange to me. edit: there's something "map"-ish here: https://code.google.com/p/go/source/browse/src/pkg/exp/iterable/iterable.go?r=1d1670229de33959691a343d716cfb32594bddbd https://code.google.com/p/go/source/browse/src/pkg/exp/itera...

masklinn 13y ago
> I really want to like Go Why? 4 years on seems a long enough time to come to term with what Go is.
dragonwriter 13y ago
> I really want to like Go, but I'm having a hard time believing that they don't have a plan for generics. I've read the FAQs about go+generics, but do we have any better idea of when generics might make an appearance? As a language feature: not likely any sooner than Go 2.0, given everything that's been said on the issue, though I suppose if a way could be found to do generics that doesn't explode compilation time and doesn't involve syntax changes that would break any existing Go 1.x code, it might happen in a later 1.x release. Wouldn't hold my breath. Via a preprocessor? Its already a thing: https://github.com/droundy/gotgo https://github.com/droundy/gotgo
bsg75 13y ago
http://golang.org/doc/faq http://golang.org/doc/faq : "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." One of Go's goals is a certain level of simplicity. The above point seems to state that generics don't fit that goal, but they are not precluded from a future version. I take this to mean that since no language has every feature that anyone could possibly want, if generics are a requirement for your work, then Go does not fit the requirements. Some potentially relevant material here - http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.de/2012/06/less-is-exponential... : "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark."

patrickxb 13y ago

This is great: "Finally, an HTTP server will now serve HEAD requests transparently, without the need for special casing in handler code. While serving a HEAD request, writes to a Handler's ResponseWriter are absorbed by the Server and the client receives an empty body as required by the HTTP specification." Been waiting for this forever...