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

121–130 of 131 posts

Re: Go 1.3 beta 1 released

#121

Post by SiVal »

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…

Thescrewdriver is absolutely correct about Java. Many years ago, I participated in several Java user groups here in Silicon Valley. We frequently had members of the Java team from Sun as guest speakers. It always went roughly the same: we professional Java devs would ask them for a few language features that most of us wanted, and they would explain to us that they knew better than we did what a programming language should have and suggest that we should get over it.

Then a representative from Microsoft started attending a couple of the biggest Java SIGs, and he would ask us how we would change Java if we could. We were happy to answer. A few of the suggestions were broadly desired by the groups.

He took lots of notes, and a year or so later C# was announced. It included several of those features. My impression is that most of us considered it a better Java, as a language design. (The Achilles Heel of its relationship to Microsoft was a huge, but separate, issue from the design of the language itself.)

The Java Team suddenly had a whole new attitude about their fossilized masterpiece, and features we had been told for years were bad ideas were touted as evidence of Java's ongoing spirit of innovation with each new version of Java.

Re: Go 1.3 beta 1 released

#122

Post by ajanuary »

NateDad wrote: post #117
ajanuary wrote: post #95

Earlier quoted context omitted.

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.

You can kind of think of it as syntactic sugar over adding strings that desugars at the compilation stage.

"abc #{x} def" would desugar to "abc"+x+"def"

Because it's happening at the compilation stage, it can only be done on string literals (which as we've seen is actually an advantage security wise).

The reality is actually a tad more complicated, because you can make efficiency improvements and only create one string instead of all the intermediate strings etc. but the effect is the same.

Re: Go 1.3 beta 1 released

#123

Post by ajanuary »

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.

What do you mean by being easier to internationalize? Do you mean you can lookup the string at runtime and it will then interpolate on that? That's not a safe way for interpolation to work, because then random strings from unsafe sources can start including any variables from your environment. String interpolation should only apply to string literals. What you actually want (no idea if it's available in Go) is something akin to Sprintf but with named instead of positional arguments, and then explicitly provide a map of those arguments rather than letting it get them from the lexical environment as interpolation does.

Re: Go 1.3 beta 1 released

#124

Post by ajanuary »

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…

One difference is that the first one, with a good implementation, will be more efficient because it doesn't need to allocate intermediate strings.

I don't think such a micro-optimisation is enough to sway the argument though.

Re: Go 1.3 beta 1 released

#125

Post by bulte-rs »

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

Earlier quoted context omitted.

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.

I fully agree in this case. But am hestitant to call for the same treatment of e.g. A web framework.

Question to answer then is: Where does the plumbing stop and the kitchen begin?

Re: Go 1.3 beta 1 released

#126

Post by rogerbinns »

ajanuary wrote: post #123
rogerbinns wrote: post #114

Earlier quoted context omitted.

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.

What do you mean by being easier to internationalize? Do you mean you can lookup the string at runtime and it will then interpolate on that? That's not a safe way for interpolation to work, because then random strings from unsafe sources can start including any variables from your environment. String interpolation should only apply to string literals. What you actually want (no idea if it's available in Go) is someth…

You have made the assumption that the values provided just come from the enclosing scopes. The various packages I found all require an explicit map/dictionary passed in - ie there is nothing unsafe - only named values intended for formatting can be used. (The OP likely didn't show the map/dict because that wasn't relevant to their point.)

Re: Go 1.3 beta 1 released

#127

Post by laumars »

NateDad wrote: post #119
laumars wrote: post #101

Earlier quoted context omitted.

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.

I suspected that might have been the case but I haven't played around with reflection enough personally.

Shame :(

Re: Go 1.3 beta 1 released

#128

Post by teyc »

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…

String interpolation is wrong in a world where there are so many variants of escaping strings. It is not useful for templating HTML, SQL, CSV, JSON, XML.

This only leaves us console programs and backdoors. I'm happy to give these two up for a stronger language.

Re: Go 1.3 beta 1 released

#129

Post by voidlogic »

bsg75 wrote: post #110
obilgic wrote: post #3

generics please? contains no language changes

If you need generics, Go is not the language you need.

In reality of people just don't know how to program without generics. Go provides interfaces which can be used to write generic code. Think of everything that has been written in C without generics or Java pre 1.4.

I'm all of the day generics is finely added (and yes I missed it a lot when I was new to Go a couple years ago), but it is much less of a issue then some people make it out to be.

Re: Go 1.3 beta 1 released

#130

Post by binarycrusader »

bulte-rs wrote: post #125
binarycrusader wrote: post #99

Earlier quoted context omitted.

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.

I fully agree in this case. But am hestitant to call for the same treatment of e.g. A web framework. Question to answer then is: Where does the plumbing stop and the kitchen begin?

In my opinion, we're talking about data types / data structures, which neatly avoids that discussion :-)
Post reply on HN