Gaffer (Glenn Fiedler, mentioned in the article) would also say, and I quote, "if you use Euler, then you're a bloody idiot" :) This simulation is using Euler integration.
My suggestion to the OP talking about compression.
First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG.
But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this
[offset byte, color byte, offset byte, color byte].
It will fail in cases where each pixel has a color and will excel when there is a run of black pixels (which there will be a lot of those). It's a dead simple format to implement and read as well.
You can even keep the frame around for writing. You'd just be counting black pixels left to right top to bottom, emitting that number or 255 then 0 resetting and then counting some more.
In regards to number crunching Go indeed made little effort to optimise this use case (especially since many good alternatives already existed at the time). Having said, I'm really hopeful that the SIMD proposals do eventually make it into the language, e.g. this one: https://github.com/golang/go/issues/73787#issuecomment-32081...
I guess the key questions are: what are the tradeoffs Go makes, and what kind of work is it well suited for?
I think Go's key strengths are syntax simplicity, niceties for large scale codebase (good monorepo support, quick builds, quick startup, easy CLIs, testing and language server built in), and good concurrency constructs.
There are controversial aspects too, like an aversion to annotations and exceptions and anything that hides a plain control flow - as well as a reluctance to evolve the syntax and basic aspects of the language. I like those things personally but that is because I find myself well aligned to Go's philosophy.
I would say that the worst parts of the language would actually be performance, I would not use Go if single threaded performance is critical (and the author Notes this). The GC is not the most efficient either. But I think given that hardware evolution is leaning towards more cores, and scaling up is leaning more towards scaling up containers, Go's choices put it in good stead here.
Go is my favourite language at the moment, has been for a while.
9 comments
[ 6.5 ms ] story [ 26.8 ms ] threadAlthough experimental as of now, but use of arena package is a natual fit here.
First up, consider just PNG compressing the image for simplicity. It's a mostly black image with color dots. That would generally compress really well with PNG.
But also, knowing the nature of the image, you could pretty easily compress the image by doing offsets to the next pixel. The format could look roughly something like this
[offset byte, color byte, offset byte, color byte].
It will fail in cases where each pixel has a color and will excel when there is a run of black pixels (which there will be a lot of those). It's a dead simple format to implement and read as well.
You can even keep the frame around for writing. You'd just be counting black pixels left to right top to bottom, emitting that number or 255 then 0 resetting and then counting some more.
I think Go's key strengths are syntax simplicity, niceties for large scale codebase (good monorepo support, quick builds, quick startup, easy CLIs, testing and language server built in), and good concurrency constructs.
There are controversial aspects too, like an aversion to annotations and exceptions and anything that hides a plain control flow - as well as a reluctance to evolve the syntax and basic aspects of the language. I like those things personally but that is because I find myself well aligned to Go's philosophy.
I would say that the worst parts of the language would actually be performance, I would not use Go if single threaded performance is critical (and the author Notes this). The GC is not the most efficient either. But I think given that hardware evolution is leaning towards more cores, and scaling up is leaning more towards scaling up containers, Go's choices put it in good stead here.
Go is my favourite language at the moment, has been for a while.