crawshaw

27 ms·

301.
by crawshaw 11y ago
There seem to be a few points in your comment, let me try to answer them as best I can: The Go 1.5 compiler is not slower because it is written in Go, it is slower because it was mechanically translated from another language. Human eyes wil
302.
by crawshaw 11y ago
That is a powerful theoretical concern that I shared when I first experimented with Go several years ago. In practice I have not found it to not be a problem. It seems (and this is purely an analysis of my own experience and the large amoun
303.
by crawshaw 11y ago
I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. Go isn't interested in either being slow. Any generics solution has
304.
by crawshaw 11y ago
It can be done, the question is can it be done in a way that fits with everything else in Go? There are technical drawbacks in the implementation of parametric polymorphism that don't suit Go's design goals: http://rese
305.
by crawshaw 11y ago
In the talk Rick described the problem as the data structure responsible for tracking finalizers. The fix is apparently reasonably straightforward, but the cause was not discovered until we were in the Go 1.5 tree freeze, so it has to wait
306.
by crawshaw 11y ago
The gomobile tool is part of the broader project, but that particular CL is about `gomobile build`, a sub-command designed to build all-Go apps. From inside Go, we have only built out access to portable APIs like OpenGL. This app uses a dif
307.
by crawshaw 11y ago
This work is the extension of the Go on mobile experiment for Android, which was originally proposed here: http://golang.org/s/go14android . Over the past several months, several open source contributors (most notably m
308.
by crawshaw 11y ago
Thanks. Screen clearing and state saving are on my todo list. It's just a big list. I'd like to get the source code published first, and that means landing some toolchain cleanups first. (The android app is a bit ahead, it has a c
309.
by crawshaw 11y ago
If you use Go and you can, please try it out and file bugs. http://golang.org/issue
310.
The State of Go(talks.golang.org)
318 points by crawshaw 11y ago|167 comments
311.
Rapidly falling costs of battery packs for electric vehicles(nature.com)
65 points by crawshaw 11y ago|35 comments
312.
by crawshaw 12y ago
Looks like a great project. Maintaining a stable set of libraries for a complex project is incredibly time consuming. I would imagine many organizations would be interested in this, much like they purchase RHEL.
313.
by crawshaw 12y ago
Go has replaced C++ in my life. There are still jobs I have done in the past that would require C today, but they were never suited for C++. Specifically it was work for realtime systems that required a highly trustworthy compiler like Comp
314.
Interview with Go’s Russ Cox and Sameer Ajmani(pl-enthusiast.net)
140 points by crawshaw 12y ago|107 comments
315.
by crawshaw 12y ago
The 10ms number is an upper bound. You will only see pauses that long if you generating large amounts of garbage, which is relatively easy to avoid.
316.
Go 1.5 concurrent garbage collector pacing(docs.google.com)
179 points by crawshaw 12y ago|87 comments
317.
by crawshaw 12y ago
I don't believe it has been tried yet, but it seems entirely possible to use gccgo as the bootstrap compiler.
318.
by crawshaw 12y ago
It would be unreasonable to have designed a generics implementation into Go 1 that did not cover the builtin polymorphic map, slice, and append. A simple set of orthogonal features is an important principle in Go. For these, performance is
319.
by crawshaw 12y ago
I don't think the tools are sub-par. My programs are compile and run quickly on a variety of platforms. My toolchain builds quickly too. And now it is written in Go, the preferred language of the compiler engineers.
320.
by crawshaw 12y ago
I'm not sure what about my comment is worth downvoting, but to try one more time: If you came to me tomorrow and said "I want to build a language just like C but with non-contiguous stacks" I agree, I would use LLVM or GCC. B
321.
by crawshaw 12y ago
Lightweight goroutines depend on small stacks. General API design in Go depends on lightweight goroutines. In particular, Go style is to never write asynchronous APIs. Always write synchronous blocking code, and when you need to work concur
322.
by crawshaw 12y ago
The replacement to segmented stacks is copying stacks, which as far as my knowledge of LLVM takes me, would be very difficult to add. You need a stack map of pointers to successfully move pointed-to objects on the stack from the old region
323.
by crawshaw 12y ago
Several members of the Go team have put a lot of time into studying and prototyping various implementations of generics. If you look through the mailing list archives you will find many emails from Ian Lance Taylor on the topic.
324.
by crawshaw 12y ago
Ford explored fission reactors for cars in the 50s: http://en.wikipedia.org/wiki/Ford_Nucleon
325.
by crawshaw 12y ago
Go gives you data structures with fewer pointers than Java, which helps cut down on GC pressure. type point struct { x int16 y int16 } points := make([]point, 1e6) The value points uses 4 MB of memory and co
326.
by crawshaw 12y ago
That's really nice of you to say. Thank you.
327.
by crawshaw 12y ago
For those who have not been following this discussion, I suggest reading this comment by Ian: https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwG...
328.
by crawshaw 12y ago
Note that when designing servers at Google in Go, we strongly discourage the use of concepts like futures and promises. They exist as abstractions that work around heavyweight threads. In Go, you have lightweight threads which remove the ne
329.
by crawshaw 12y ago
Happily, Pu-238 is being manufactured again: http://news.discovery.com/space/nasa-plutonium-production-sp... Another source I read at the time of the announcement said it will take a while to spin up, so there are some
330.
by crawshaw 12y ago
It's a map[uintptr]unsafe.Pointer. The key is invisible to the collector, but the value is an unsafe.Pointer, which is will be managed for you by the precise collector.

More ›