Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.3 beta 1 released

tip.golang.org

Post reply on HN
Print view View original

111–120 of 131 posts

Re: Go 1.3 beta 1 released

#111

Post by whyrusleeping »

4ad wrote: post #51
whyrusleeping wrote: post #23

Earlier quoted context omitted.

with gccgo you get to take advantage of a lot of gcc's optimizations (-O3) and it can generate faster code because of it.

There is extremely little code in the world that is faster with gccgo. Yes, gccgo can do better with floating point, but the lack of escape analysis slows it down tremendously in every real world situation out there. http://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs-...

Wow. I guess the last time i look at the differences was around 1.1 Thanks for the correction

Re: Go 1.3 beta 1 released

#112

Post by jksmith »

leaveyou wrote: post #34
neals wrote: post #31

How are we on IDE's? Last time I tried go (over a year ago) I couldn't really find a nice IDE.

I use https://code.google.com/p/liteide/ on ubuntu and it works well for my needs (and it gets better with each version). It has all the basic features of an editor and the code completion is quite good in the last versions. It's very easy to use (no complicate setup needed) and I never felt the need to try GoSublime or other alternatives.

+1 Gets the job done.

Re: Go 1.3 beta 1 released

#113

Post by dilap »

greiskul wrote: post #102
thescrewdriver wrote: post #87

Earlier quoted context omitted.

fmt.RichPrint("....")

And how would this function capture variables from the local scope? The only way this could be added would be with new syntax.

That's what I was thinking, but now that you mention it, all that is needed is to have introspection gain the ability to examine local variables up the stack, so I guess it's do-able w/ back compat after all.

I wouldn't hold my breath, though.

Re: Go 1.3 beta 1 released

#114

Post by rogerbinns »

ahuth wrote: post #58
DrJokepu wrote: post #50

Earlier quoted context omitted.

I wish they didn't! Magic features like this belong to magic languages like Ruby. Go is not meant to be a magic language.

There isn't much difference between this: "My name is #{name} and surname is #{surname}" and this: "My name is " + name + " and surname is " + surname or this: fmt.Println("My name is %s and surname is %s", name, surname) Except the first one is much more readable. String interpolation seems like a small thing, but I find myself wanting to use it all the time. It's definitely not a "magic" feature. Javascript really…

There is one huge difference - it is far easier to internationalize the first one. The second one is impossible, and the third has ordering issues.

What is the Go best practise for i18n? A google search seems to provide various solutions but not one best practise.

Re: Go 1.3 beta 1 released

#115

Post by sisalcat »

rogerbinns wrote: post #114
ahuth wrote: post #58

Earlier quoted context omitted.

There isn't much difference between this: "My name is #{name} and surname is #{surname}" and this: "My name is " + name + " and surname is " + surname or this: fmt.Println("My name is %s and surname is %s", name, surname) Except the first one is much more readable. String interpolation seems like a small thing, but I find myself wanting to use it all the time. It's definitely not a "magic" feature. Javascript really…

There is one huge difference - it is far easier to internationalize the first one. The second one is impossible, and the third has ordering issues. What is the Go best practise for i18n? A google search seems to provide various solutions but not one best practise.

The first one (string with variable interpolation) is not internationalizable, only the third one is.

> the third has ordering issues

In Go you can specify the order in format strings: fmt.Sprintf("%[2]d %[1]d\n", 11, 22)

http://golang.org/pkg/fmt/

Re: Go 1.3 beta 1 released

#116

Post by mediocregopher »

Someone wrote: post #107
kisielk wrote: post #46

Earlier quoted context omitted.

It only removes values that have been put back in to the pool. The assumption is that anything you've put back in to the pool has already been cleaned up to a state where it's ready to be used again when it's taken out.

That's exactly the complaint. You don't use a connection pool to get rid of allocs and frees, but to get rid of lengthy calls that initialise the connection. Because of that, you don't want to close your connection before returning it to the pool. So, the pool will have to close those connections whenever it disposes of an object in the pool. I don't know enough go to interpret what 'might be deallocated' means in th…

There's not a destructor method like there is in C++. I'm not sure why they defined Pool to only interact with interface{}, it seems like it would have been much easier to define an interface which looks like:

  type PoolObject interface {
      Destroy()
  }
And have it interact with that. The NewPool func would look like:

  func NewPool(func() PoolObject) Pool
EDIT: Changed my code a bit

Re: Go 1.3 beta 1 released

#117

Post by NateDad »

ajanuary wrote: post #95
NateDad wrote: post #88

Earlier quoted context omitted.

Uh, grabbing variables out of the current scope to format your string is most certainly magical. It's also way less explicit than actually passing variables into a formatting function. It might be a little harder to read, but that's a lot different than explicit. fmt.Sprintf("Hello %s!", username) is very explicitly using the username variable from the local scope, and nothing but the username variable can ever get i…

Can you give an example of your last point? A language like Ruby will only perform interpolation on string literals, so there isn't a way (that I know of) for data to inject interpolated strings. Interpolation isn't the same thing as eval.

I guess that's my lack of knowledge of how Ruby's string interpolation works. I assumed it worked like any old string format, which in other languages can use whatever string is passed into the formatting function. It sounds like that's not the case for Ruby's string interpolation. My apologies for jumping to conclusions. I guess it's my statically compiled mindset that assumes a string is a string.

Re: Go 1.3 beta 1 released

#118

Post by NateDad »

jongraehl wrote: post #103
NateDad wrote: post #90

Earlier quoted context omitted.

For what it's worth, I do think it's more readable, but it's just not a good idea. It's too easy for people to inject variables into their strings and get your code to print out data that's in memory. map, reduce, filter, etc will be easy to code up once there are generics. There will almost certainly be generics in Go at some point, that point is just not right now (and almost certainly not before 2.0).

What? There's absolutely no way for a user string to get scanned for format instructions unless you 'eval' or something like that. The proposed syntax is only for string literals in source code.

Ahh, oops, that was pointed out below as well. Sorry, I assumed a string was a string, not that this only works in string literals. That's certainly better than letter user-supplied strings work this way.

Re: Go 1.3 beta 1 released

#119

Post by NateDad »

laumars wrote: post #101
thescrewdriver wrote: post #74

Earlier quoted context omitted.

> I understand your pain, but this is nowhere near a real issue for systems that Go is designed to help build. I spend most of my day designing and coding the sorts of systems which Go was designed to help build. I'll agree that this isn't a major issue, but it is affecting whether or not I actually enjoy using Go.

I appreciate something like this is best served in the compiler, but would it not be possible to build your own function that provides this functionality?

Sorta impossible. You can't suck values out of the current context, even with reflection. You always would need to pass values into a function, in which case you might as well use fmt.

Re: Go 1.3 beta 1 released

#120

Post by thescrewdriver »

greiskul wrote: post #102
thescrewdriver wrote: post #87

Earlier quoted context omitted.

fmt.RichPrint("....")

And how would this function capture variables from the local scope? The only way this could be added would be with new syntax.

I haven't dug into the details, but here's how Scala went about adding string interpolation: https://docs.google.com/document/d/1NdxNxZYodPA-c4MLr33KzwzK...
Post reply on HN