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

91–100 of 131 posts

Re: Go 1.3 beta 1 released

#91

Post by nathany »

landr0id wrote: post #7
ancarda wrote: post #2

For those wondering, os/fsnotify was pushed back to 1.4

That's unfortunate. I looked around this post details why it was pushed: https://groups.google.com/forum/#!msg/golang-dev/bShm2sqbrTY...

Yah, we didn't want to rush it and end up stuck with a subpar package in the standard library.

If you are at GopherCon, I'll be giving a lightning talk on Saturday 11:40am on things I've learned by contributing to fsnotify and other open source projects. Happy to chat more about fsnotify afterwards.

Re: Go 1.3 beta 1 released

#92

Post by nathany »

whyrusleeping wrote: post #22
ancarda wrote: post #2

For those wondering, os/fsnotify was pushed back to 1.4

Do you know where their current implementation of this is? I want to mess around with it and dont care if i have to change code later.

The code is identical on GitHub and Google Code right now. The difference is that we may make breaking changes under go.exp while leaving the howeyc/fsnotify API as is.

We're still figuring out what os/fsnotify will look like.

Re: Go 1.3 beta 1 released

#93

Post by ajanuary »

lazyjones wrote: post #64
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…

> Except the first one is much more readable. I disagree, especially in the presence of syntax highlighting editors. String interpolation would be a redundant alternative to existing mechanisms (the above plus text/template for longer strings) and just make parsing more complex. I don't think it would fit in well with Go's philosophy of providing pleasant, minimalistic syntax.

> I disagree, especially in the presence of syntax highlighting editors.

Every syntax highlighter in an editor I've seen for Ruby handle highlighting string interpolation just fine.

Re: Go 1.3 beta 1 released

#94

Post by ajanuary »

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'm not really familiar with Go, but surely the answer to almost all of those can be "the same as variables in the same scope as the string"?

Re: Go 1.3 beta 1 released

#95

Post by ajanuary »

NateDad wrote: post #88
coldtea wrote: post #62

Earlier quoted context omitted.

There's nothing "magical" about it. The intention of the programmer and the result is actually even more explicit than passing the values as arguments to some printf function.

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.

Re: Go 1.3 beta 1 released

#96

Post by ajanuary »

jerf wrote: post #71
ImJasonH wrote: post #65

Earlier quoted context omitted.

http://play.golang.org/p/DdwCOZwiCk

One thing Go won't do, is pull the variables out of the local scope into the string interpolation automatically. As I think easy string interpolation is an antipattern, and I'm comfortable having to feed values into the string formatter, I'm not upset, but you're not going to convince people with that. As we slowly, oh so slowly, but surely move into languages where buffer overflows are not possible to write (or at l…

Nothing in Go pushes you towards using a domain specific templating language rather than Sprintf, only education (and culture) can do that.

So programmers _will_ use Sprintf, because it's one of the first things they'll have been taught, and Sprintf doesn't make dealing with encoding any easier or explicit than string interpolation.

Having string interpolation doesn't mean people can't or won't use domain specific templating languages, and not having it won't make it any more likely that they will.

Re: Go 1.3 beta 1 released

#97

Post by pjmlp »

sigzero wrote: post #67
mseepgood wrote: post #37

Earlier quoted context omitted.

And all of them will stay in a niche because of their complexity (Scala, Haskell, D, ...).

> all of them will stay in a niche C# has had generics since 2.0, so ALL is a bad choice of words there.

Actually C# already had generics even before the 1.0 .NET release, but they weren't considered stable enough for a 1.0 release and priority was given to other parts of the .NET.

One of many posts about generics history in .NET:

http://blogs.msdn.com/b/dsyme/archive/2011/03/15/net-c-gener...

Re: Go 1.3 beta 1 released

#98

Post by pjmlp »

mseepgood wrote: post #37
pjmlp wrote: post #32

Earlier quoted context omitted.

Stop using Java and C++ for comparing generics in Go. There are lots of languages that had generics on day one.

And all of them will stay in a niche because of their complexity (Scala, Haskell, D, ...).

The complexity was not the issue, CLU, Ada, Eiffel, Sather, Modula-3, ML, and many others lacked the publicity stunt of having a godfather like Google.

Re: Go 1.3 beta 1 released

#99

Post by binarycrusader »

bulte-rs wrote: post #38
binarycrusader wrote: post #26

Earlier quoted context omitted.

Yes, I was actually looking for the union intersection, etc. functionality. I use that extensively in the project I work on. And it's core enough that I want it in the language, not as a third-party add on because of the performance implications and because of things the language can enforce natively. The Python set data type really is great for a certain class of problems. In particular, graph analysis and traversal…

Lot's of libraries for this on Github; everone (myself included; plug: https://github.com/bulters/readyset ) and his mother probably writes one at some point.

As I said, I really want to see it in the core language. Your point about "everone ... and his mother probably writes one at some point" seems like a strong point for just putting it into the language or primary implementation if it's such a common pattern.

Re: Go 1.3 beta 1 released

#100

Post by binarycrusader »

ImJasonH wrote: post #66
binarycrusader wrote: post #15

I'm not asking for generics, but I really want an equivalent to Python's set data type for strings and numbers at the leas built-in. I'm aware of golang set on GitHub and the gen project as well, but I'm shocked that Go doesn't have an equivalent to the set data type yet. I'm open to suggestions.

https://gist.github.com/ImJasonH/7791518

Thanks, that does seems like a rather elegant, simple implementation. I still want to see it in the core language or primary implementation, but seeing the different ways people implement sets in Go is helpful because I'm certain there are pitfalls in doing so.
Post reply on HN