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

81–90 of 131 posts

Re: Go 1.3 beta 1 released

#81

Post by thescrewdriver »

lazyjones wrote: post #80
thescrewdriver wrote: post #77

Earlier quoted context omitted.

I find that there are some disturbing similarities between the Java community and the Go community when it comes to features and culture. There seems to be an unwritten assumption that the language is perfect in its current form and any additional features are a source of evil (up until the day when they are added, in which case they are suddenly evidence of the language's superiority).

> the language is perfect in its current form It works really well in its current form, that is probably the general consensous. > additional features are a source of evil Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness). > up until the day when they are added, in which case they are suddenly evidence of the language's superiority That sounded…

The first two apply to Go and Java, the last only to Java since Go hasn't added major features recently.

>> additional features are a source of evil

> Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

We've walked down that path and have been very happy and productive with Scala. Each to his own I guess.

Re: Go 1.3 beta 1 released

#82

Post by LanceH »

DrJokepu wrote: post #59
thescrewdriver wrote: post #57

Earlier quoted context omitted.

> It's the kind of feature that is useful when you write an application but not that useful when you're trying to debug it. It's largely used in log messages and the like where it's used for debugging issues after the fact. I've yet to encounter a case where anyone was ever confused by the behaviour.

Right, if this gets in then I officially demand that the much more innocent ternary operator and prefix/postfix increment/decrement operators get in as well.

If I had to choose, I'd pick string interpolation.

i += 1 means an extra line, but that extra line is very clear.

Ternary vs an if-else arguably loses on clarity except for the simplest of cases.

"Today's date is #{date}. Your balance on account #{account.Number} is #{account.Balance}"

"Today's date is " + date + " Your balance on account " + account.Number + " is " + account.Balance

The second is a mess of +'s and "'s to me, not to mention the awkwardness of formatting spaces before and after each quote. The first, you write a sentence and plug in the variables where they belong.

Not saying you're wrong, just what I would choose.

Re: Go 1.3 beta 1 released

#84

Post by dilap »

thescrewdriver wrote: post #47

I really wish they'd add string interpolation to Go. After being able to use s"My name is $name and surname is $surname" in Scala and "My name is #{name} and surname is #{surname}" in Ruby I find working with printf a giant step backwards.

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

Re: Go 1.3 beta 1 released

#85

Post by dragonwriter »

jerf wrote: post #75
dragonwriter wrote: post #73

Earlier quoted context omitted.

I don't understand your claim that strong interpolation is wrong and the source of injection attacks, which are well known where building strings is much harder than interpolation. They come from not validating input data before use; requiring lots of work to build strings doesn't make it any more likely that people will do it safely.

"They come from not validating input data before use;" I say they come from building APIs that don't require a statement of the correct way to escape output. Of course if your API doesn't require it, it doesn't happen. Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things . I've implied this in my phrasing but let me spell it out, validation ha…

> Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things.

Yes, they are, but preventing injection attacks is the domain of the former more than the latter, and your suggestion that it is the other way is dangerously wrong. There are security risks addressed by the latter, but if you are relying on it to prevent injection attacks in the usual case [1], it means you are allowing untrusted unvalidated external data into your system and doing general processing on it and just trying to avoid a problem on output.

You prevent injection attacks by preventing malformed data from being injected into the system (at least, from such data making it past a validation component), not by allowing it freely into the system and trying to mitigate certain of its harms by escaping output.

Its true that proper escaping may help to limit injection attacks where imperfect validation has failed to prevent bad data from being accepted and processed, but even there more complicated APIs for string building don't make it more likely that people will do it right.

[1] the one place where it may be a proper mechanism for addressing injection attacks is when you are reporting the rejection of malformed input data, in which case you may have a legitimate need to use (some part of) the malformed data in the error report.

Re: Go 1.3 beta 1 released

#86

Post by afarrell »

jerf wrote: post #75
dragonwriter wrote: post #73

Earlier quoted context omitted.

I don't understand your claim that strong interpolation is wrong and the source of injection attacks, which are well known where building strings is much harder than interpolation. They come from not validating input data before use; requiring lots of work to build strings doesn't make it any more likely that people will do it safely.

"They come from not validating input data before use;" I say they come from building APIs that don't require a statement of the correct way to escape output. Of course if your API doesn't require it, it doesn't happen. Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things . I've implied this in my phrasing but let me spell it out, validation ha…

You are looking at a whole class of bugs as symptoms of a problem with the user interface rather than the user. Except here, the user is a programmer.

Re: Go 1.3 beta 1 released

#87

Post by thescrewdriver »

dilap wrote: post #84
thescrewdriver wrote: post #47

I really wish they'd add string interpolation to Go. After being able to use s"My name is $name and surname is $surname" in Scala and "My name is #{name} and surname is #{surname}" in Ruby I find working with printf a giant step backwards.

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

fmt.RichPrint("....")

Re: Go 1.3 beta 1 released

#88

Post by NateDad »

coldtea wrote: post #62
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'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 included in the output string. At most, a user could put a %s in their string, and get the username to appear somewhere else in the output... but they wouldn't be revealing data that wasn't already intended to be printed out.

In comparison, interpolation is opening a door to let anyone extract whatever variables happen to be in scope at the time by putting #{password} or #{secret_key} in their string. By moving the definition of what variables get printed out into the data, you're opening a really big hole in your code... it also makes it a lot harder for the compiler to check for correctness.

Re: Go 1.3 beta 1 released

#89

Post by supersillyus »

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

There is a GSOC to add escape analysis (https://www.google-melange.com/gsoc/project/details/google/g...). It'll be interesting to see how that affects things.

Re: Go 1.3 beta 1 released

#90

Post by NateDad »

ahuth wrote: post #76
lazyjones wrote: post #64

Earlier quoted context omitted.

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

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).

Post reply on HN