"Go 1.5 provides support for Android and experimental support for iOS."
I thought this day would never come.
The State of Go
41–50 of 172 posts
Re: The State of Go
#42Slide 10 shows the benchmark differences, and I found them a little suspect. The "binary tree" benchmark is the only one that is 25% worse than the old version, but in my opinion it is an important benchmark, because I suppose that this benchmark actually creates a lot of objects that need to be garbage collected. At least that is what I suppose, based on the fact that this holds for binary tree algorithms. The other benchmarks are mostly about formatting and regexping, which require much less objects to be created on the heap, and these are making the benchmarks look better.
Re: The State of Go
#43"Go 1.5 provides support for Android and experimental support for iOS." I thought this day would never come.
I seriously was wondering if Go would ever replace Java on Android because of legal troubles. I'm still wondering.
Re: The State of Go
#44Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.
There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications. Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compi…
> ...a relic of the past when memory and disk space were expensive ... a few megs here and there might actually matter...
The nature of the modern computer is that cpu speed has increased more than memory speed, so if your data doesn't fit into cache your cpu will be do nothing quickly.
Even with shared libraries, this phenomena has such an impact that the Linux kernel now has a memory de-duplication feature (mostly for VMs):
Re: The State of Go
#45Slide 10 shows the benchmark differences, and I found them a little suspect. The "binary tree" benchmark is the only one that is 25% worse than the old version, but in my opinion it is an important benchmark, because I suppose that this benchmark actually creates a lot of objects that need to be garbage collected. At least that is what I suppose, based on the fact that this holds for binary tree algorithms. The other…
Yes, if it's referring to Boehm's binary-trees benchmark (as seen on the benchmarks game, for example), it is explicitly designed to be a benchmark of garbage collection. I believe the Boehm GC was tuned using it.
Re: The State of Go
#46Shared libraries? I thought "no DLLs" was one of the major design philosophies of Go.
There was a big push from the linux distros as the maintainers had anneurisms thinking they'll need to rebuild hundreds of Go applications when/if a big bug is found in the Go standard library. They also don't like the idea of having N copies of the code for the standard library in N Go applications. Personally, I find that kind of thinking to be a relic of the past when memory and disk space were expensive and compi…
The debian snapshot archive is over 30TB. Some single packages take up to 10 hours to build (although all other packages can be built in parallel if you have enough EC2 credit).
Re: The State of Go
#47Pretty neat, go is now written in go "Go 1.5 has no C code in the tool chain or runtime.", go shared libraries interoperable with c. I'm really a go tinkerer, but I like the langauge. I didn't realize Garbage Collection was so expensive that the goal is to only have it run 20% of the time. But its a good goal. "Run Go application code for at least 40ms out of every 50ms."
go shared libraries interoperable with c.
How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may become wild pointers when garbage collection is performed.
On go-nuts, Go's developers have been warning that passing arrays to C by getting the address of the first element of the slice will be unsafe for this reason.
Re: The State of Go
#48Slide 10 shows the benchmark differences, and I found them a little suspect. The "binary tree" benchmark is the only one that is 25% worse than the old version, but in my opinion it is an important benchmark, because I suppose that this benchmark actually creates a lot of objects that need to be garbage collected. At least that is what I suppose, based on the fact that this holds for binary tree algorithms. The other…
> Slide 10 shows the benchmark differences, and I found them a little suspect.
To be fair, they follow a slide about general performance, 4 slides after the GC slides.
And from the concurrent GC slide it looks (as one would expect) that the GC burns significantly more resources overall (it's not just longer wallclock), though it rarely completely stops the world anymore: on the right-hand side, where the old GC would burn 1 unit of CPU for 240ms (3 * 80ms), the new one burns half a unit of CPU for 900ms (plus a unit for 2ms), which mean it's using 452ms of CPU, close to twice as much as the old one. Though the application pauses significantly less (which is good for responsivity), that's CPU time it doesn't get to use anymore. The concurrent GC also "leaves off" more work for later, the left-hand side graphs show relatively low CGC use for the first 7s, followed by a spike and then much, much longer GC runs (though at progressively lower CPU%).
I don't know about others, but it was my expectation that overall performance would take quite a hit for GC-heavy applications in 1.5.
Re: The State of Go
#49"Go 1.5 provides support for Android and experimental support for iOS." I thought this day would never come.
I wonder how Go can be better than Swift for iOS development.
Re: The State of Go
#50Earlier quoted context omitted.
Doesn't it? Why do people seem to compare them all the time...
Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attractin…
Yeah, additionally it would be unwise to use Go in embedded systems because it is so reliant on heap memory for dynamic allocation. In certain situations where things could fail if an operation takes too long - rocketry and robots - it would be difficult to tell how long something would take in Go with any degree of certainty because allocating and freeing memory on the heap is highly non-deterministic.