Go 1.3 beta 1 released • Hacker News Board

Re: Go 1.3 beta 1 released

#71

Post by jerf » Wed, Apr 23, 2014, 1:23 PM UTC

ImJasonH wrote: post #65

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.

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 least require scary excursions into some sort of "unsafe" package), easy string interpolations that allow the programmer to believe they don't have to think about the correct encoding of the value become the next most pressing security threat. Pretty much every "injection" is due to over-simplified string interpolation.

Unfortunately, if your string interpolation syntax is as easy is "This is an interpolated $string"... it's also wrong. Dead wrong, very wrong, run away screaming wrong wrong wrong! String interpolation is actually a very hard problem, and this must irreducibly manifest itself in the API. ImJasonH's example, while it isn't "string interpolation" in the Ruby/Perl/etc. sense, does involve using a template system with sensible escaping mechanisms... it's HTML-specific, though, but for HTML it's incredibly powerful and easy to use correctly. In fact Go's HTML templating is the most powerful and easy-to-use correct HTML templating system I've ever seen that isn't in Haskell. Presumably there are others out there, but I've seen a lot of the competition and most of them will sit by, twiddling their thumbs and whistling idly, while you put 100 injections of every kind into your HTML page.

My guess is Go will never grow this style of string interpolation, pretty much because it is so very, very frequently wrong. The way Go is already doing it is as easy as it can feasibly be, without encouraging wrongness.

Re: Go 1.3 beta 1 released

#72

Post by why-el » Wed, Apr 23, 2014, 1:28 PM UTC

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.

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 is about how to interpolate strings? I think they made a very good move by ignoring most syntax requests (There are a lot) and move on. Even better is their decision to harmonize formatting and build the formatter right into the language.

Syntax is extremely overrated, and evidence for it has been provided years ago. [1]

[1] http://c2.com/cgi/wiki?ProgrammingLanguagesAnInterpreterBase...

Edit: typos.

Re: Go 1.3 beta 1 released

#73

Post by dragonwriter » Wed, Apr 23, 2014, 1:31 PM UTC

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…

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.

Re: Go 1.3 beta 1 released

#74

Post by thescrewdriver » Wed, Apr 23, 2014, 1:37 PM UTC

why-el wrote: post #72

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.

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.

Re: Go 1.3 beta 1 released

#75

Post by jerf » Wed, Apr 23, 2014, 1:41 PM UTC

dragonwriter wrote: post #73

jerf wrote: post #71

Earlier quoted context omitted.

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…

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 happens on the way in and is related to your local semantic domain (business rules, legal values of "an IP address" or "an email", etc), and escaping happens on the way out and is performed by the string "interpolation" or template system. If you've got them munged in your head into one concept, you're probably not writing correct code.

(For what it's worth, I see this formulation of the "root problem" more often than I see the right one. I really ought to write this up as a blog post.)

I'm looking out on the world and seeing what is there, which is a steaming mass of code that incorrectly manages strings. The fact that it is theoretically possible to correctly manage them is not that interesting of a fact, because observationally, it doesn't happen.

Re: Go 1.3 beta 1 released

#76

Post by ahuth » Wed, Apr 23, 2014, 1:56 PM UTC

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.

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 well with systems programming, which Go was designed for. So I can't hate them for not including these.

Re: Go 1.3 beta 1 released

#77

Post by thescrewdriver » Wed, Apr 23, 2014, 1:56 PM UTC

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

Re: Go 1.3 beta 1 released

#78

Post by ahuth » Wed, Apr 23, 2014, 1:57 PM UTC

axaxs wrote: post #68

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…

The last example is different - remember to use Printf, else you get: My name is %s and my surname is %s John Smith I do this unfortunately way more than I want to admit...

Thanks. I'm definitely not an expert at Go.

Re: Go 1.3 beta 1 released

#79

Post by rjammala » Wed, Apr 23, 2014, 2:10 PM UTC

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 emacs and gocode. The following url's explain how to setup emacs for go:

http://dominik.honnef.co/posts/2013/03/writing_go_in_emacs/

http://dominik.honnef.co/posts/2013/08/writing_go_in_emacs__...

Re: Go 1.3 beta 1 released

#80

Post by lazyjones » Wed, Apr 23, 2014, 2:13 PM UTC

thescrewdriver wrote: post #77

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.

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 very much like flamebait. Could you name an example of a feature added to Go that was previously considered evil and then as evidence of Go's superiority?