If you’re Google, you just replace the machine, and get on with the rest of your day, which consists of replacing 9000 more machines. …
-
-
Replying to @mietek @jlouis666 and
… This explains why Golang doesn’t have per-process heaps, for instance.
1 reply 0 retweets 0 likes -
Replying to @mietek @paul_snively and
Yeah. Google essentially outsourced most of Erlang to their infrastructure teams / code.
1 reply 0 retweets 0 likes -
Replying to @jlouis666 @mietek and
Though, per-process heaps are nice. Throw computation in separate process with large-enough heap => no GC at all when proc terminates.
1 reply 0 retweets 0 likes -
Replying to @jlouis666 @mietek and
Funnily this is what the Go GC guys are researching right now, heh.
2 replies 0 retweets 0 likes -
Replying to @jlouis666 @paul_snively and
Yes. My comments on Golang are not intended as praise.
1 reply 0 retweets 1 like -
Replying to @mietek @paul_snively and
Go's low latency GC (trading throughput) runs a proverbial stake through the GC-can-do-no-realtime-computation vampire. I like that.
1 reply 0 retweets 0 likes -
Replying to @jlouis666 @mietek and
Realtime and low latency are orthogonal concepts. Just sayin'.
1 reply 0 retweets 0 likes -
Replying to @andreasdotorg @mietek and
"soft realtime" is the precise term here.
1 reply 0 retweets 0 likes -
Replying to @jlouis666 @andreasdotorg and
Short variant: you could run a 16.7ms frame render time loop on Go without too much trouble.
1 reply 0 retweets 0 likes
Yep, and nobody dies when you drop a frame. Having said that, hard realtime and GC do mix.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.