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

101–110 of 131 posts

Re: Go 1.3 beta 1 released

#101

Post by laumars »

thescrewdriver wrote: post #74
why-el wrote: post #72

Earlier quoted context omitted.

Ah, I think there should be a formula that spills out how many minutes will pass before language discussion descends to syntax assassination. I understand your pain, but this is nowhere near a real issue for systems that Go is designed to help build. I mean, in the thread that announces a new version of a language whose designers made it abundantly clear that it is intended to solve Google's problems, the top comment…

> 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?

Re: Go 1.3 beta 1 released

#102

Post by greiskul »

thescrewdriver wrote: post #87
dilap wrote: post #84

Earlier quoted context omitted.

Pretty much impossible to add at this point w/o breaking back-compat, though, right?

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.

Re: Go 1.3 beta 1 released

#103

Post by jongraehl »

NateDad wrote: post #90
ahuth wrote: post #76

Earlier quoted context omitted.

You're probably right. Also, I obviously should've said, "Except the first one is much more readable to me ." I definitely don't have a problem with the Go developers keeping out random syntax additions unless they think its a really good idea. Along the same lines, I really miss not having `map`, `reduce`, and `filter` in Go. However, it doesn't seem like those would be efficient in Go, or that they fit in with as w…

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.

Re: Go 1.3 beta 1 released

#104

Post by jongraehl »

DrJokepu wrote: post #56
thescrewdriver wrote: post #52

Earlier quoted context omitted.

Go is designed to be a very practical and productive language. It's not quite clear how you're defining "magic" ... String interpolation is both practical and useful.

String interpolation is magic because it's not entirely obvious when it happens, what scope rules are followed, if there are any side effects, if the original string is overwritten or whether a new instance is created, what happens when they are used within bodies of loops, what happens when they are used within closures etc., it just works. Sure these can be specified explicitly but they aren't obvious. It's the kin…

It would be defined as sugar for the regular syntax "blah" + var. Not sure what specifically you find confusing.

Re: Go 1.3 beta 1 released

#105

Post by [deleted] »

coldtea wrote: post #63
rockybox wrote: post #6

Earlier quoted context omitted.

It took Java 5 versions over 8 years to get generics. It's not going to happen in a minor release.

Yes, but Java was left behind and ate C#'s dust (and now Scala's) because of lack of progress like that. Not the best example to justify adding generics late.

[deleted]

Re: Go 1.3 beta 1 released

#106

Post by laumars »

DrJokepu wrote: post #56
thescrewdriver wrote: post #52

Earlier quoted context omitted.

Go is designed to be a very practical and productive language. It's not quite clear how you're defining "magic" ... String interpolation is both practical and useful.

String interpolation is magic because it's not entirely obvious when it happens, what scope rules are followed, if there are any side effects, if the original string is overwritten or whether a new instance is created, what happens when they are used within bodies of loops, what happens when they are used within closures etc., it just works. Sure these can be specified explicitly but they aren't obvious. It's the kin…

I can understand if you don't like the syntax of string interpolation, but that argument is a cop-out.

If you're genuinely confused by it's behaviour then I'd suggest steering clear of the Printf (and even the vanilla Print/Println functions which does concatenation and automatic type conversion).

Or perhaps, a better suggestion would be to read the language specs and learn interpolation's behaviour since this "magic" is almost always well documented [hint: it's actually less complicated than Printf ;)]

Re: Go 1.3 beta 1 released

#107

Post by Someone »

kisielk wrote: post #46
mediocregopher wrote: post #24

Earlier quoted context omitted.

Reading the documentation, it seems that sync.Pool will automatically shrink the pool size when it's not being used? If so, unless in the future it provides some way to specify a cleanup function for those values, using it for connections and the like would result in hanging connections (I think, not 100% sure).

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 this part of http://tip.golang.org/pkg/sync/#Pool:

"Any item stored in the Pool may be removed automatically at any time without notification. If the Pool holds the only reference when this happens, the item might be deallocated."

Is there some interface{} similar to C++ destructors, or is that a reference to the fact that the garbage collector need not deallocate unreachable objects?

Re: Go 1.3 beta 1 released

#108

Post by bsg75 »

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.

https://github.com/Komodo/komodo-go

Not so much an IDE, dependent on your definition. More of a set of editor extensions, but useful so far.

Of course IDE availability should be low on the list of selection criteria for any language...

Re: Go 1.3 beta 1 released

#109

Post by noselasd »

kisielk wrote: post #46
mediocregopher wrote: post #24

Earlier quoted context omitted.

Reading the documentation, it seems that sync.Pool will automatically shrink the pool size when it's not being used? If so, unless in the future it provides some way to specify a cleanup function for those values, using it for connections and the like would result in hanging connections (I think, not 100% sure).

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.

Which would mean if you use it as a connection pool, you'd be at the mercy of the garbage collector as to when the connection gets closed if it's pruned from the pool.
Post reply on HN