16 ms·
Toward Go 1.3
- syaramak 13y agoSlightly off topic, but is there a mobile friendly version of this site?
- valarauca1 13y agoI was gonna ask if there is a desktop friendly version. All I get is 1 slide and its off center half off my screen. Using FF26
- kzrdude 13y agoIt looks like the page is hardcoded to 900 x 700 px slides right? That's weird.
- nfoz 13y agoRemember when Microsoft's websites only worked in IE?
- RamiK 13y agoNoScript.
- deleted 13y ago[deleted]
- Zenst 13y agoFrom way in the slides I saw this and got excited: "darwin/arm, android/arm: a contributor is working on these, some way to go."
- leoc 13y ago"Go 1.3 targets that command-line tool for 32-bit and 64-bit x86 architectures. (NaCl supports 32-bit ARM, but we have no plans to support it.)" epic facepalm
- coldtea 13y agoWhy, is anyone using Go on 32-bit ARM and will miss this?
- patrickaljord 13y agoChromebooks and Android maybe although they're moving to 64-bit ARM.
- georgemcbay 13y agoI use Go on 32-bit ARM (Beaglebone Black, Raspberry Pi, Samsung ARM Chromebook, and a few old chumby imx233 devices), and having this would actually be useful to me. In any case, I'm sure ARM support will be added in time (just not for 1.3 release) if not from the core team than by outside contributors. There are quite a lot of people using Go on ARM devices.
- enneff 13y agoCan you explain how the NaCl port would be useful to you on ARM platforms?
- georgemcbay 13y agoOne long-term project I've been working on (very off and on) is something like the chumby dashboard app system but for apps written in Go that can run on actual old chumby devices (or really any similar ARM device such as RaspPi, etc). Basically you'd end up with a bunch of mini apps that you rotate through with each app doing random things, like providing a clock display, or a short photo slideshow, or whatever. Ideally the running apps would be sandboxed so they could be served from potentially untrusted sources and not do damage to the underlying OS or cause problems or privacy issues with other little apps that would rotate through running, so a framework like the one used as the basis for the Go playground would be ideal. This is admittedly a very niche need and can be tackled by other OS-level sandboxing techniques (though at that level the support offered by different combinations of embedded Linux ARM ports and/or ARM CPUs makes things more complicated), but NaCL support in Go/ARM would be very convenient here. This project aside, though, there were lots of listed plans for Go 1.3 in the presentation that I would prioritize way over ARM/NaCl.
- sdegutis 13y ago> Support for linking against Objective C code This is the most exciting part for me! Although I wish they didn't skim so much on the technical detail here.
- Laremere 13y agoIf it's anything like 1.2's c++ support, you have to write a wrapper in pure c, because that's what Go supports. So Go includes the C header files using Cgo, and you separately compile (and tell cgo to link) your c code which calls your objective c code.
- melling 13y agoYes, but it's x86 code so it won't work on iOS. It would be cool if Go could become an option for Android and iOS development.
- enneff 13y agoGo does compile to ARM and does run on phones. It works on Android phones (linux/arm) out of the box, and it has been made to work on iOS (darwin/arm) but it hasn't been merged with the core: https://bitbucket.org/minux/goios/wiki/Home https://bitbucket.org/minux/goios/wiki/Home
- skj 13y agoThat seems strange to me...for go.wde I made a cocoa backend that linked against an ObjC framework. I don't understand what special things need to happen that require any extra 'support'.
- deleted 13y ago[deleted]
- sdegutis 13y ago> Compiler overhaul: the plan. Not a rewrite. Translate the C compilers to Go. Write and use an automatic translator to do this. Start the process with Go 1.3 and continue in future releases. Aww. Transliterated C code does not sound like it will take full advantage of Go idioms. Plus, an automatic translator? Unless it is extremely disciplined C code, that sounds harder than just translating it by hand.
- durin42 13y agoIt's already pretty paranoid C, so the transliteration should actually be pretty plausible.
- tdees40 13y agoI do feel like they may be underestimating the difficulty of putting together automatic translator code...
- DougMerritt 13y agoYes, because Rob Pike is so inexperienced. You should explain to him what he's getting in to.
- dsymonds 13y agoRuss Cox is the one who is doing the compiler translator. He is not going to be out of his depth.
- DougMerritt 13y agoThat's interesting, I didn't know that. Doesn't really change the point, of course. :)
- 0xdeadbeefbabe 13y agoThey'd take advantage of go idioms after they've got a working compiler, a transliterated from C working compiler. Not only is translating manually boring, it's also less effective. The bugs from an automatic translator would all be from a similar class.
- japaget 13y agoI had to use the Page Up and Page Down keys to navigate this; apparently either the mouse is not supported, or I couldn't figure out how to navigate this site with the mouse.
- ominous_prime 13y agoyeah, it's using the present tool, so it's only really mean to be navigated by keyboard for presentations. No one seems really to eager to polish this beyond whats needed for giving live demonstrations.
- darkgray 13y agoThe far left and right sides are clickable to "turn the page", so to speak. It's an invisible area, though, so it's not very easy to deduce from just looking at the webpage.
- kenshiro_o 13y agoForgive my ignorance but what does 100% Precise GC means?
- voidlogic 13y agohttp://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers http://en.wikipedia.org/wiki/Garbage_collection_%28computer_... :)
- deleted 13y ago[deleted]
- tomp 13y agoLanguages that support pointer arithmetic have to support "raw" pointers, i.e. pointers that point to any location in memory. This creates some problems for the GC, as it can't be sure what objects are live and which aren't. For example, a pointer might point to unallocated memory (in which case the GC must not even dereference it), to a `malloc`-allocated memory, to a GC-allocated memory, or even in the middle of a (GC-allocated or `malloc`-allocated) heap object! In addition, some pointers look like integers and some integers look like pointers, and the GC has no idea how to distinguish them at runtime. In order to still support some kind of GC in such languages, you can write your GC to be imprecise or conservative, which means that it treats every integer that could potentially be a pointer as a pointer and assumes it is pointing to a live object. Potentially, this means that the GC thinks objects are live which are actually not, just because the programmer is using an integer which, if interpreted as a pointer, points to said object. I'm not intimately familiar with Go implementation, but I assume that they haven't bothered implementing precise stack- and register-scanning, which means that the runtime cannot distinguish pointers from integers on the stack/in the registers. That's a really hard problem in general and solving it requires quite some compiler support and runtime overhead. It looks like that is finally planned for Go 1.3, though.
- kenshiro_o 13y agoI see. This indeed adds a lot more complexity to the GC as it will have to check every integer or type that "looks" like a reference. Does this also mean that GC times will likely be longer in Go 1.3? There is not much detailed info about the Go runtime (like we do have for Java for instance) so it would great for the Go maintainers to publish a more in-depth reference of the internals of the language in version 1.3 /
- justinsb 13y agoSo "liblink" means that the compilers now generate native instructions, rather than pseudo-instructions. Seems like that would make it much tougher to implement generic methods. Anyone know if that's true?
- pcwalton 13y agoYes, in general you will need to have some other mechanism other than emitting raw machine code to handle generics (unless you have a uniform value representation like MLs or Java do, but Go doesn't).
- CoffeeDregs 13y agoFirst, I apologize for bringing up something that has been brought up since the birth of Go... I'm surprised at the lack of progress in generics for Go. But more than progress, I'm surprised at the lack of a story about generics in Go. Yes, the FAQ waves its hands at complexity, but the lack of discussion and/or proposals puzzle me. The wiki page about it (https://code.google.com/p/go-wiki/wiki/GoVsGenerics https://code.google.com/p/go-wiki/wiki/GoVsGenerics) is tiny and feeds from this discussion (http://groups.google.com/group/golang-nuts/browse_thread/thread/3d825ac84e742598 http://groups.google.com/group/golang-nuts/browse_thread/thr...). I would be much more interested in Go were there some evidence for the intent to implement generics. A related concern is that adding generics will have a significant affect on libraries and existing code, so adding generics will become harder the longer Go waits. I would be very happy to have the Go team say: we're going to focus on adding generics to Go in 2.0 and will be considering how to get there sooner than later; that said, we don't know when 2.0 will be released, but building in generics will drive 2.0. Note: I understand the workarounds, but they're either hacky or have terrible performance. And I also understand that users of Go say that they don't miss generics, but I'm just not comfortable believing that.
- gtaylor 13y agoMy understanding is/was that they'll get around to it eventually, but they're not in a hurry to rush it and stink it up. I haven't missed them too much in my tinkerings.
- joncooper 13y agoThe sense I've gotten is that the Go team is surprised how little complaint has arisen among actual Go users about the lack of generics, and that that has kept the priority level low for figuring out how to implement them. In other words it seems like the Go team is actually slightly more interested in having them than the user base is. I'd like them in part because it'd enable all kinds of delightful reactive functional idioms that just aren't very possible currently. On the other hand I'm accomplishing an awful lot in Go without them..
- 13y ago
- gtaylor 13y agoThe combination of NaCl support and Objective C linking support make me wonder whether we will see Go creep towards being an officially "blessed" and privileged language (like Java and C+NDK) for Android development in the future. I would assume that the NaCl support means that we'll be able to write things for Chromebooks relatively easily?
- pokstad 13y ago"NaCl supports 32-bit ARM, but we have no plans to support it."
- gtaylor 13y agoThere are upcoming ARMv8 cores that are 64-bit. I doubt we'll see Go as a fully "endorsed" Android language any time soon, but by the time it potentially happens, 64-bit ARM may be ubiquitous.
- enneff 13y agoNo. The NaCl stuff is not about Chrome. It's about sandboxed execution in other contexts. For instance, it powers the Go Playground: http://blog.golang.org/playground http://blog.golang.org/playground
- gtaylor 13y agoSure it's about Chrome. "Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user's operating system." https://developers.google.com/native-client/dev/ https://developers.google.com/native-client/dev/
- enneff 13y agoThe Go NaCl stuff is not about Chrome.
- voidlogic 13y agoUsing sync.Pool for my personal projects has made them so much faster (/ use less heap) and let me retire my custom pools. So much awesome there. This presentation also doesn't mention the concurrent GC sweep work: https://codereview.appspot.com/46430043/ https://codereview.appspot.com/46430043/
- 0xdeadbeefbabe 13y agohttp://talks.golang.org/2014/go1.3.slide#9 http://talks.golang.org/2014/go1.3.slide#9 Ok I see how it's go-routine (or thread) safe, but what is meant by "free list"? It's a pool of objects that you can access and put back, and putting back doesn't block? Free as in freeing memory maybe?
- joncooper 13y agoHere is an example from http.Transport: http://golang.org/src/pkg/net/http/transport.go#L408 http://golang.org/src/pkg/net/http/transport.go#L408 A connection pool is kept in the transport for use with HTTP keep-alive. When an http.Client makes a request using the transport, it tries to get an idle connection, failing that it starts creating a new connection. It then selects the first available connection, either the newly-dialed one, or one that becomes available in the pool. (If the latter case, it continues opening the new connection and then sticks it into the pool.)
- ominous_prime 13y agoA "free list" is a fairly standard programming pattern, though it's not as common to see now with memory management and GC in most languages. At the base level, all it is is a list of currently "free" (i.e. available) resources that have been pre-allocated.
- voidlogic 13y agoSometimes also referred to as an object pool. What makes this implementation special is that its pooling is both thread-local and global, and is plugged into the runtime/garbage collector. The former makes it much much faster than any pool the user could implement, and the later means is plays nice as resources become more scarce.
- namelezz 13y agoWow March 1, 2014. What an exciting month with Go 1.3 and Java 8.
- 0xdeadbeefbabe 13y agoMarch madness
- Jayschwa 13y ago1.3 feature freeze is in March, but there will still be a couple months of bug-fixing and fine-tuning after that.
- clhodapp 13y agoEither these slides mischaracterize what liblink does or it has the wrong name. The fact that it does things that the linker used to do doesn't mean it is doing linking.
- enneff 13y agoIt has a weird name, but it also won't be around for long.
- steeve 13y agoNoting that I'm successfully running Go 1.2 binaries with CGO on android/arm, cross-compiled from darwin/amd64 (my macbook). You can check out the Makefiles in libtorrent-go[1] and torrent2http[2] [1] https://github.com/steeve/libtorrent-go https://github.com/steeve/libtorrent-go [2] https://github.com/steeve/torrent2http https://github.com/steeve/torrent2http
- pjmlp 13y agoInstead of doing my usual comments about Go's design, I would rather congratulate the team in what they have achieved so far.
- leothekim 13y agoOne of the bullet points: - "Clean up and document the code, add unit tests. (Target Go 1.4)" Oh sure, add features now and add the unit tests later. :-D #joking
- NateDad 13y agoThe lack of generics in Go is hugely over-hyped as a problem. There are generic lists (slices & arrays), there are generic maps (dictionaries). You can build a hell of a lot on top of that. To generalize logic, Go's interfaces are amazing. There are some huge projects out there using Go, and not hurt by the lack of generics. Perhaps you've heard of Docker? I work on Juju[1], a Go project that is over 200,000 lines of code. There's only a handful of places where generics would have made things a little easier, and it's never been "OMG this is so awful because we don't have generics". And this is coming from a guy who spent his first 14 years programming in C++ and C#, so it's not like I'm not used to generics. You just write code in a different way. Sometimes you can't get around it when you need a containery class, so you use interface{} and cast the result, but that's the exception rather than the rule. [1] http://juju.ubuntu.com http://juju.ubuntu.com