There are a lot of cases where people write their own version of this (myself included, but also the connections in database/sql for example). It will be great to have an implementation in the standard library. This technique has been very, very useful in StatHat's production code as we have grown.
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.
"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?
There's not a destructor method like there is in C++. I'm not sure why they defined Pool to only interact with interface{}, it seems like it would have been much easier to define an interface which looks like:
type PoolObject interface {
Destroy()
}
And have it interact with that. The NewPool func would look like:
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.
I'm looking forward to it too. I think it'll be a good way to have one-per-type free-lists inside my toy language implementation. At the moment, garbage is created like crazy in there for all the short-lived immutable values.
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]
> 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?
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'm actually hugely not a fan of magically rendering code variables in strings. It's super error prone, and way too magical.
If you really want named variables in format strings you can make a template like "My name is {{.Name}} and surname is {{.Surname}}", and render the template with either a map of strings to strings, or a struct with the right named values.
"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 needs it as well.
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).
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?
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.
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.
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.
Ahh, oops, that was pointed out below as well. Sorry, I assumed a string was a string, not that this only works in string literals. That's certainly better than letter user-supplied strings work this way.
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.
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.)
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.
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 kind of feature that is useful when you write an application but not that useful when you're trying to debug it.
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 ;)]
> 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.
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.
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.
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.
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.
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.
> 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.
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.
That's what I was thinking, but now that you mention it, all that is needed is to have introspection gain the ability to examine local variables up the stack, so I guess it's do-able w/ back compat after all.
The support for Native Client sounds interesting, but the distinction that it's not portable native client makes me wonder what you might use this for. What would one use the native client support for?
Could I use it to allow developers to make plugins for a product in Go and C++ in a secure way, instead of using say Lua?
On a related note, do you know if anyone is using Go with Lua plugins (or any other plugin system for that matter) in production. If so, does it work well?
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.
s := make(map[string]struct{})
s["foo"] = struct{}{}
if _, ok := s["foo"]; ok {
// exists
}
There are varying amounts of fluff you can put on top of this, but that's the basic approach. Wrap it up in a type with methods if you're using it a lot in a program.
Perhaps you also want built-in union, intersection, difference, etc. I personally find I need a set with simple membership testing about 10x as often as I need more advanced set operations, so from my perspective it's fine to leave those to third-party libraries.
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.
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.
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.
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.
Most people I know use vim or SublimeText to write their Go code.
I personally prefer vim, and use the vim support delivered with Go plus gocode for code completion, that's really all I need for development. Unlike with Java, I never felt the need for an IDE with Go.
Intellij IDEA with http://go-ide.com/ works for me. Some useful features:
1. Quickly run/restart your application
2. Run specific unit test (all in package, all in file or specific one)
3. Parameter and func signatures are more detailed via CTRL+P (parameter info) than what you would get with GoSublime and GoCode.
There's only one thing so far I found a bit quirky:
Say you got a function with the signature func() (err error) and pass it as a parameter to another function that has the signature func F(f func() error), it will complain that the signatures don't match, but it will still compile.
I use https://code.google.com/p/liteide/ on ubuntu and it works well for my needs (and it gets better with each version). It has all the basic features of an editor and the code completion is quite good in the last versions. It's very easy to use (no complicate setup needed) and I never felt the need to try GoSublime or other alternatives.
I've been using Light Table with the LightTable-Go plugin (I'm one of the contributors). Support is still fairly basic, but for my needs it works pretty well. If you want to try it, grab the plugin from github and not the ide's plugin manager - that one hasn't been updated in some time.
I haven't found one I like yet. However after a few years of hand holding by visual studio I'm less inclined to deal with one as they are complicated and require a lot more maintenance than a basic text editor. So vim it is for me and that's good enough as it highlights and indents well. The compiler takes so little time and the language is so normalised that I'm not sure there is a great advantage in an IDE either.
An ARM target has been exiting for years, it works just fine on Android. Unfortunately (?) this doesn't allow creating GUI apps or using the Android APIs. Camlistore[1] is written in Go and uses a Go backend on Android, it just has a Java shim for the GUI.
One reason is that gccgo supports many architectures that gc does not (SPARC, MIPS, PowerPC, Alpha). It also was the only way to get Go on Solaris until the more recent port of gc to that platform.
gccgo is also supposed to produce better code for certain computationally heavy workloads.
> gccgo is also supposed to produce better code for certain computationally heavy workloads.
Unfortunately, this is very seldom true. Gccgo could potentially generate faster floating point code, but its lack of escape analysis grinds it to a halt.
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.
Nothing complex about generics that the average modern day programmer can't grasp. We're not talking about some '00s enterprise drones that were never exposed to those concepts.
People used to talk like this about closures in Java too -- "too complex, who needs them", etc. Didn't turn out very well for the language's mindshare about the new generation of programmers...
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.
What's the casual definition of complexity? Stuff in here I don't like?
Honestly, in the medal positions for sloppily expressed programming sentiments, complex/simple occupy the bronze/silver positions just behind the ultimate... "elegant".
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.
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.
I don't doubt that generics are very useful, but its a problem when every thread that mentions Go gets polluted by bitching from people who can't code without them.
I work with SQL mostly, and in find common table expressions very useful to simplify and (in some cases) enhance performance. When faced with a choice between MySQL and PostgreSQL, I could either 1) choose to gripe about the lack of CTEs in MySQL, or 2) use PostgreSQL.
Something about generics make so many people on HN choose the equivalent of (1).
http://tip.golang.org/pkg/sync/#Pool
There are a lot of cases where people write their own version of this (myself included, but also the connections in database/sql for example). It will be great to have an implementation in the standard library. This technique has been very, very useful in StatHat's production code as we have grown.