joelgwebber

6 ms·

1.
by joelgwebber 12y ago
To be precise, Blink is moving to a GC for stability (including avoiding leaks), but I don't believe it's for security -- the renderer remains sandboxed because it's effectively impossible to secure such a huge pile of C++ co
2.
by joelgwebber 12y ago
C++ management can of course be workable with enough care. I worked on Chrome for a bit while at Google, and saw that it more or less holds together with enough reference counting and smart pointers. At the same time, it still requires a lo
3.
by joelgwebber 12y ago
Thanks for taking the time to comment, Jonathan. This is why the approach I'm experimenting with is build something very much like a custom allocator in Go, for all values that are allocated in significant numbers. I'm hoping that
4.
by joelgwebber 12y ago
This was a fairly obscure bug lurking in the DOM/API bindings. They have to do a bunch of wacky stuff to deal with the interactions between the V8 GC and the ref-counted native API objects. In this case, the TypedArray wrapper objects
5.
by joelgwebber 12y ago
Indeed. I'm hopeful that the concurrent GC will get it to the point where it can do a lot better than that "10ms out of every 50" promise in 1.4. If not, then well, I guess we will have learned that Go isn't great for
6.
by joelgwebber 12y ago
Nice work. Assuming my experiments convince me that writing games in Go is worthwhile, I'd love for the ecosystem to evolve to a point that it's trivially easy to get up and running. The fast iteration time is very nice for these
7.
by joelgwebber 12y ago
Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtoot
8.
by joelgwebber 12y ago
See my comment elsewhere on this thread, about techniques for limiting garbage in Go. I'm far from proving that this is sufficient for avoiding significant GC pauses, but I'm tentatively hopeful. I'll post more as I get more
9.
by joelgwebber 12y ago
See my earlier comment (and some bits of the original post). Go does indeed support arrays-of-structs, as well as taking pointers to the middle of arrays, and directly to struct fields. This gives you a lot more control over memory layout
10.
by joelgwebber 12y ago
Here's my take on GC in games, FWIW. I'd be very leery of using a VM with a garbage collector for the entirety of a game. They can be fine (and are extremely common) in embedded scripting languages, but it can be far too difficu
11.
by joelgwebber 12y ago
Yes, this. I've often advocated for the importance of having a good debugger when developing any kind of UI, game, or simulation code. It can be really damned hard to make sense out of subtle bugs that are the result of accumulated sta
12.
by joelgwebber 12y ago
I'll be honest -- I hate working without a debugger. Go's gdb support was never great, and the team appears to have decided it's a fool's errand. On the other hand, the Delve project looks like it's serious about
13.
by joelgwebber 12y ago
Damn, that was fast. Thought billing was enabled for that site, but I guess not. Fixed! Edit: Or at least it should be. Might take a couple of minutes to clear up.
14.
by joelgwebber 12y ago
> I think that the original poster (the one you responded to originally) was talking about errors in the first two senses; things that you should/want to handle yourself. I guess the last thing should be handled with a panic? Right
15.
by joelgwebber 12y ago
I don't want to pick nits too much here, but "[...] leading to the whole non-nil value being nil idiocy; it's mindblowing that they got this so wrong." So I paraphrased a bit :) I understand that some may find the error
16.
by joelgwebber 12y ago
Sorry, I wasn't entirely clear -- I was referring to the original basis for the complaint about verbose error handling. I'm intentionally separating the handling of runtime errors (e.g., memcache request fail) from validation erro
17.
by joelgwebber 12y ago
See my comment above for why I don't find this to be that great for server code. If each of those getOrElse() is an actual potential runtime failure (as opposed to just something that could in theory be nil, but you know won't be,
18.
by joelgwebber 12y ago
My personal experience at a startup with a large amount of Go code running its frontend and backend servers. YMMV. First off, I also find the interface-nil thing to be a frustrating edge-case. I also know that this design was the result of
19.
A Palatable Javascript Pattern(blog.j15r.com)
7 points by joelgwebber 13y ago|1 comments
20.
by joelgwebber 13y ago
I might be able to do that more effectively if you'd point out what browser you're running.
21.
by joelgwebber 13y ago
Good point. Apple helpfully reports the rather confusing version string "Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)" :P
22.
by joelgwebber 13y ago
Ditto for gcc-4.8. Roughly the same (ever so slightly worse) performance.
23.
by joelgwebber 13y ago
FWIW, I just ran it through Clang 4.1 (the standard on XCode these days), and got roughly identical performance. I'm still compiling gcc 4.8 just to be sure, but it seems unlikely to make much of a difference.
24.
by joelgwebber 13y ago
What phone browser are you using? It seems ok on my Nexus 4 and mobile Safari, but I may need to fix the viewport or some such thing.
25.
by joelgwebber 13y ago
It looks like Farseer is based on Box2D, but extended, so it makes a kind of sense. I suspect the .NET VM performance will be somewhere around what the JVM gets, so it shouldn't be too much of a surprise.
26.
by joelgwebber 13y ago
I must admit to being unfamiliar with Farseer, but if you feel like submitting a pull request, I'll figure out a way to run it on my Mac (I presume the "platform" you're referring to is .NET, or perhaps WinMo).
27.
by joelgwebber 14y ago
For the record, the size of Postgres is at least an order-of-magnitude off from what counts as a "large" C++ program, at least as far as Google is (and many others are) concerned. Try compiling Chrome (or just WebKit) sometime. It can take
28.
by joelgwebber 14y ago
Not really. V8 was simply a drop-in replacement for existing Javascript VM's, so there was no "adoption" curve, per se. It ran something like 40x faster than the one in WebKit when it was released, so everyone just said "Awesome, thumbs up!
29.
by joelgwebber 14y ago
I think you're fundamentally misunderstanding the way these kinds of things happen at Google. Most projects of this nature have to work to get internal adoption just like any external toolchain. There's almost never an "edict from on high"
30.
by joelgwebber 15y ago
Try thinking of it in terms of Android intents/activities. The vast majority of the time, it's handled automatically for you (where "it" is whatever you were trying to do), but when you want the option to choose, it's there. In some cases

More ›