20 ms·
Introduction to Go 1.1
- phasevar 14y agoSweet performance improvements! Definitely looking forward to seeing Go 1.1 on the benchmark game.
- trailfox 14y agoDefinitely looking forward to seeing if Go has made any progress in catching up to Java and Scala in algorithm execution times.
- mseepgood 14y agoIt's not released yet, this is just a preliminary document. There are still open issues for Go 1.1: http://swtch.com/~rsc/go11.html http://swtch.com/~rsc/go11.html And I guess there will be a RC first.
- laumars 14y agoIs there any ETA on the release or is it just a case of "when it's finished"? I'm about to start a largish project in Go and I'm thinking I'd rather start in Go 1.1 rather than worry about upgrading and testing the project mid-development.
- dsymonds 14y agoIt's "when it's finished", but you can expect it in the near future. Go 1.1 is strongly backward compatible. You can start working on a large project right now with Go 1.0.3 and it'll work just as correctly under Go 1.1.
- laumars 14y agoIt's the term "strongly" that concerns me as that's not really a guarantee. However I think I will take your advice and start development on it regardless (if I've written it correctly, then any breaking changes will be confined to their respective module so fixing them shouldn't be much of an ordeal). Thanks for the feedback :)
- dchest 14y agoSee http://golang.org/doc/go1compat.html http://golang.org/doc/go1compat.html for details on compatibility.
- enneff 14y agoIt is a guarantee. I promise, you won't have to change any of your code when updating from 1.0 to 1.1.
- ithkuil 14y agoTrue. Except if you used ListenUnixgram returned and couldn't use type inference for storing it's return value. Go1.0 returns UDPConn, which will be renamed as UnixConn. This is a clear API bug, and it's the only exception to the backward compatibility rule.
- jesstaa 14y agohg tip is very stable. If you want to start your project on Go 1.1 then just checkout the tip and use it. You can upgrade to Go1.1 when it's released with very minor changes when it's released.
- georgemcbay 14y agoJust wanted to chime in confirming that in my experience for development work you might as well just use Go tip. It is quite stable and in many situations (eg. you're deploying to ARM, or 32-bit targets) is far more stable/usable than 1.0.3 despite not being an official release.
- enneff 14y agoIf you do run from tip, please check the build dashboard: http://build.golang.org/ http://build.golang.org/ We make no guarantees about the stability of tip, which should be obvious but I feel compelled to point it out anyway.
- jgrahamc 14y agoWorth also knowing that the Go team has made significant improvements in crypto speed: https://code.google.com/p/go/source/detail?r=eb2c99e6ec17db272ef3a20fa416f3fe86ba9f29 https://code.google.com/p/go/source/detail?r=eb2c99e6ec17db2... https://code.google.com/p/go/source/detail?r=e7304334527349c395f150e109296dfc0f81d271 https://code.google.com/p/go/source/detail?r=e7304334527349c... https://code.google.com/p/go/source/detail?r=e5620fd3ba5fb1d5fb083dbba864ca66d84fa859 https://code.google.com/p/go/source/detail?r=e5620fd3ba5fb1d... Fast approaching OpenSSL speeds. Also, the integration of the network poller into the main scheduler is likely to make a big difference to Go programs that make heavy use of the network.
- drewcoo 14y agoSo I can't tell easily (mea culpa, I'm new to Go) but were the crypto speedups also timing-attack-safe?
- laurent123456 14y agoShouldn't that be a property of the algorithm rather than the implementation? I mean as long as they implement the algorithm correctly, do they need to care about being timing-attack-safe?
- pbsd 14y agoYes and no. Certain algorithms make it harder to do timing-resistant implementations, but by no means impossible. Probably the easiest mistake to make is on DH/RSA exponentiation. Using the simple square-and-multiply algorithm gives away plenty of timing data; you usually need to explicitly protect against it by either using blinding or always performing both the square and multiply at each iteration.
- arnehormann 14y agoYes, they do. Read http://www.imperialviolet.org/2013/02/04/luckythirteen.html http://www.imperialviolet.org/2013/02/04/luckythirteen.html - even a division in the cpu may introduce timing differences depending on the input (bottom of the blog post). https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/HF5O5vAKRcQ https://groups.google.com/forum/?fromgroups=#!topic/golang-n... indicates golangs implentation may not be timing attack safe, but that's another version and I don't know for sure.
- djhworld 14y agoI'm excited for this release. I'm not sure if I understand what "method values" are though
- karma_fountain 14y agoYes, I wondered about that. Is it just that the function func (w *Writer, int n) { } is actually a method, like: func (w *Writer) Anon(int n) { }
- mseepgood 14y agoNo, it means that it is now possible to use methods as first-class values as well, just like functions: http://tip.golang.org/ref/spec#Method_values http://tip.golang.org/ref/spec#Method_values
- karma_fountain 14y agoI see. Seems like a nice addition.
- ubershmekel 14y ago> In Go 1.1, an integer division by constant zero is not a legal program, so it is a compile-time error How often do be people accidentally divide by a constant 0? I personally use that to simulate runtime errors all the time in python. It's shorter than writing "raise Exception()".
- duaneb 14y agoIt's possibly easier to specifically handle that corner case.
- laumars 14y ago> How often do be people accidentally divide by a constant 0? As much as I do love the level of checking that Go's compiler does, I must admit I asked myself that same question when I read the article.
- dsymonds 14y agoGo has a builtin function called panic, which is much more useful and well-defined. panic("simulated runtime error")
- verytrivial 14y agoWhat about programs that write programs that divide by zero?
- yebyen 14y agoIf those programs (the second level of programs) are compiled with the go compiler too, then they will also be caught (and sacked.)
- IanCal 14y ago> How often do be people accidentally divide by a constant 0? Depends how far the compiler goes to simplify constant expressions. It could be quite useful if it detects something like: f(x,y) : x / (x - (2*y)) f(6,3)
- jsmeaton 14y ago
- davidw 14y agoI'm interested in tracking Go as a replacement for Erlang. Some things that should probably happen: * GC works on 32 bit systems. * Scheduler improvements so that things are a bit more robust ( http://code.google.com/p/go/issues/detail?id=543 http://code.google.com/p/go/issues/detail?id=543 ) * A fairly solid library implementing supervision trees or something like it. * Probably some other things, but those strike me as the big ones. The important thing is for the system to be able to run for months at a time. I think they'll get there eventually. Maybe not 100%, but 'good enough' sooner or later.
- lmfao 14y agoThe first thing is one of the major issues I have with go at the moment. Lots of my servers are forced to run on 32 bit, due to certain software requirements and it bothers me to not be able to write go daemons for it.
- davidw 14y agoThe system I'm working on is an embedded-ish platform that should probably be 32bit in order to save on memory.
- trailfox 14y agoAkka is also a viable Erlang alternative.
- davidw 14y agoGood point; I wonder what kind of memory usage you could squeeze that in to.
- trailfox 14y agoIt should run comfortably on any modern server, might be tricky if you have severe memory constraints though.
- JulianMorrison 14y ago
- deleted 14y ago[deleted]
- mortdeus 14y agoCan you please delete this article until go1.1 is officially released. Just in case the go developers make any last minute changes. Otherwise this article may lead to confusion for those who choose to skip out on reading it on golang.org when go1.1 is released because they read it here.
- mseepgood 14y agoIt's not an article. It's the HTML page in the Go source code repository that will be put online on golang.org once Go 1.1 is released.
- laumars 14y agoHe knows this and arguing the semantics of 'article' is completely missing the point he was raising. Personally, I think it's silly to delete this thread, but I appreciated his warning that this [article / document / HTML page in a source code repository / whatever the hell you want to refer to this as] is only a draft document for a version of Go that's not yet been finalised.
- thepumpkin1979 14y agoStill missing custom generic types and methods :(
- _ak 14y agoExperience with Go in the last few years has shown that you don't really need them. If you think you do, then you're doing it wrong. Also: http://research.swtch.com/generic http://research.swtch.com/generic
- AndrewDucker 14y agoAnd as the various comments there show, .Net does it right, and better than any of the methods they list. If I want to create a new wrapper class, the last thing I want to do is either make it hold an Object, or have to write a new version of it for every type it can hold.
- grey-area 14y agoIf I want to create a new wrapper class, the last thing I want to do is either make it hold an Object, or have to write a new version of it for every type it can hold. Can't you solve this problem with an interface defining the behaviours your wrapper expects? The interface can then be passed in or held as a ptr without requiring a specific type, allowing a generic implementation. You can create a generic iterate or sort function for example which operates on slices of a given interface. Sorry if I've misunderstood, if so a code example might help clarify what you mean.
- AndrewDucker 14y agoLet's say we have a Reply<T> which packages up the actual reply from a service, along with the status of the service call, and any additional warnings, etc. In C# I can define this once, and then any service can just return a Reply<string>, Reply<int>, Reply<Address>, etc. The calling method can check the associated reply status, and then unwrap the data if the call was successful, displaying any associated messages as needed. Or, for a different example: If I want to store a long list of Customers in a dictionary, keyed on String, then in C# I'd create a Dictionary<string,Customer>, and know that it would always contain the types I'd expect. How would I do either of those in Go?
- acqq 14y agoTwo most interesting news for me are: > The garbage collector is also more precise, which costs a small amount of CPU time but can reduce the size of the heap significantly, especially on 32-bit architectures. Previously, 32-bit version was almost unusable is some cases when garbage collector kept the allocations for which he falsely believed to be used even if they were not. I'd like to know if this means that the problem is finally solved. > Previous Go implementations made int and uint 32 bits on all systems. Both the gc and gccgo implementations now make int and uint 64 bits on 64-bit platforms such as AMD64/x86-64. This is a C-like can of worms, forcing you to test on more platforms just to be sure that you have portable code. I believed there's no reason to do such things with primitive data types in the new languages of 21st century (compare with http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html http://docs.oracle.com/javase/tutorial/java/nutsandbolts/dat...). I'd like to see any discussion about such in my opinion quite strange decision.
- fulafel 14y agoOn the go-nuts list people have been reporting large slowdowns with the new precise GC, and someone even backported the old GC to Go 1.1.
- Raphael_Amiard 14y ago> with the new precise GC The new GC is still not a precise GC, it's still conservative and non-tracing, just "more precise" (probably means they refined their heuristics) so you should probably not call it a precise GC.
- deleted 14y ago[deleted]
- asb 14y agoI thought Go 1.1 featured precise GC on the heap and conservative on the stack. Is that incorrect?
- coldtea 14y ago
- przemoc 14y agoWe have integer madness here and no one is commenting on it. Why making this int change and why now? I don't like Java, but well-defined integer types sizes is a good thing. Most of the world uses intXX_t typedefs in C and C++ too.
- dchest 14y agoIt doesn't matter much in Go: integer types with defined sizes are intXX/uintXX, which are not convertible to int/uint implicitly. http://golang.org/ref/spec#Numeric_types http://golang.org/ref/spec#Numeric_types
- mseepgood 14y agoGo has (u)int8, (u)int16, (u)int32, (u)int64 types if you must make assumptions about the size.
- laumars 14y agoNobody is commenting because there isn't any integer madness. If the size of an integer is critical to the execution of your program, then you should be using int16 or one of the many other types that specify the number of (un)signed bits. The int type is designed to be platform specific to optimize on execution speed when the maximum size of the integer isn't an issue. http://golang.org/ref/spec#Numeric_types http://golang.org/ref/spec#Numeric_types
- przemoc 14y agoSee my response to grey-area. And regarding optimization. Language-defined integer type size is one thing and CPU register sizes used in calculations is different thing. It's not like having 32-bit int forces you (or compiler) to use 32-bit registers. For every int we (i.e. programmers) should be aware of possible min and max values that can be stored in it. Thus we can easily use fixed-size ints everywhere, paying attention to signedness too of course. The problem is that there is high temptation of using int most of the time, because it's easier to write (it's shorter). For the same reason many C programs use int instead of unsigned short or uint16_t for instance. Well-defined int size is part of self-documenting code, as it shows mindfully applied constraints.
- etfb 14y agoI grew up with Pascal and its derivatives, so I have a strong sense of the aesthetic of programming languages. I can't take Go seriously, or bring myself to use it, because it appears to have no aesthetic sense at all. It's ugly! Strings of keywords and punctuation, no rhythm to it, just a lot of mess. Like a cross between C and Prolog, perhaps, with a smattering of Python but only the ugly bits. I really don't like it. Now, if you want to see a recent language with a bit of style to it -- and bear in mind I know nothing of how it is to use in practice, so I'm basing my opinions entirely on the look of it -- I think Rust is one of the best of the pack. So much smoother. TL;DR (for any Redditors who may have stumbled in on their way to the Ron Paul fansite): languages have a flavour, and Go's flavour is "mess".
- stefantalpalaru 14y ago> I can't take Go seriously, or bring myself to use it But you can criticize its aesthetic nevertheless? Maybe if you could bring yourself to use it you might appreciate the elegance of the Communicating Sequential Processes implementation. Or maybe the clean OOP practices derived from using interfaces. Or the beauty of coroutines mapped unto multiple OS threads. tl;dr: learn it properly before complaining it's not like mom's cooking
- etfb 14y agoSorry, but I don't feel like I need to be an expert in something before I can express an opinion about it. You're welcome to send a quick message to pg to get a refund on what you've paid to read my comment, if you disagree.
- stefantalpalaru 14y agoYour informed opinions are more valuable to those "spending" the time to read them, so please make an effort and study the problem domain a little more before speaking on the subject.
- laumars 14y agoWhen choosing a language for a job, I'm often concerned about whether the source code is apathetically pleasing. After all, execution speed, portability, compile time, development time, usable toolkits and maintainability are all irrelevant if the source code isn't pretty enough to frame and hang on your living room wall. </sarcasm>
- melvinmt 14y agoFor those of us who are wondering if 1.1 is stable enough to upgrade: Google is already using Go 1.1 in production. And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. Source: core dev on the golang team.
- GhotiFish 14y ago>And the company is betting big time on Go, more than 50% of their codebase will be (re)written in Go in a couple of years. !!! wow !!!
- netcraft 14y agoim interested in the rewritten aspect - are these things that would have otherwise needed to be rewritten, or are you gaining benefits from the rewrite? Or is it an "eat your own dogfood" sort of deal? 50% of google's codebase must be significant, I can't imagine doing that "just because". And rewritten from what? C/C++ or python or something else?
- melvinmt 14y agoI'm not sure why, I also thought it was a bold statement coming from a Google employee and we'll have to see if they actually are able (and willing) to do that. But I can imagine, seeing how obsessive Google with performance usually is, that it mostly will be rewritten to save "millions of years" in optimizations. I believe Google is mostly using Java and Python.
- GhotiFish 14y agoWhenever I look through golangs specs, I always get stuck on the same question. Why are the methods we define restricted to the types we define? I'm SURE there is a good reason. Others have said that it's because if you did allow that kind of thing to happen, you might get naming collisions in packages. I don't buy this argument, you could get naming collisions anyway from packages, Go resolves those issues by aliasing. Go also allows for polymorphic behavior by packaging the actual type of the method caller with its actual value, so resolving which method to use isn't any more complicated. I don't get it, I'm sure there's a good reason! I just hope it's a good enough reason to throw out the kind of freedom that would allow you.
- Jabbles 14y agoYou can't add methods to a type in a different package as you might break that package. By locking the method set of types when a package is compiled you provide some guarantee of what it does, and it doesn't need to get recompiled again! This is central to Go's ideals of compiling fast. Besides, embedding a type is very easy http://golang.org/ref/spec#Struct_types http://golang.org/ref/spec#Struct_types
- GhotiFish 14y agoHmmm. I can see how adding methods to a type in a different package would require that package to be recompiled, but I don't see how I could break that package. Unless there's some reflection magic I'm not considering. I'm reading through the embedded types now. I am new to golang so this one is lost on me. I thought if you wanted your own methods on a type from another package, you just aliased it with your own type def. though it looks like there's some kinda prototyping behavior being described here? If S contains an anonymous field T, the method sets of S and *S both include promoted methods with receiver T. The method set of *S also includes promoted methods with receiver *T. If S contains an anonymous field *T, the method sets of S and *S both include promoted methods with receiver T or *T.
- Jabbles 14y ago
- Titanous 14y agoHere's the same document with a stylesheet: http://tip.golang.org/doc/go1.1 http://tip.golang.org/doc/go1.1
- thrownaway2424 14y agoThe post's URL should be replaced with this one ... most of the links in the posted page are broken.
- joeshaw 14y ago"We trust that many of our users' programs will also see improvements just by updating their Go installation and recompiling." Does anyone know if it is possible to determine what version of Go a given binary was compiled with? Perhaps extracting some metadata from an ELF section?
- dmit 14y agoThere's no guaranteed way unfortunately. If you expect to need this in the future, you can add a flag in your program to print runtime.Version(). But for existing binaries that don't use that function the version will not be included in the binary. http://golang.org/pkg/runtime/#Version http://golang.org/pkg/runtime/#Version
- VeejayRampay 14y agoI'd more than welcome any instructions and pointers on how to install Golang 1.1 on my computer which has 1.03 installed already. Either to replace my current version or maybe to install it aside 1.03 for testing. Thanks a lot.
- eridius 14y agoI would guess that right now you need to install from source. https://code.google.com/p/go/source/checkout https://code.google.com/p/go/source/checkout
- VeejayRampay 14y agoI see, thanks a lot. And congratulations and thanks to the dozens of developers who made that release happen.