Are most Androids 32-bit? Doesn't this issue impact the GO Android SDK adoption?
...if there was the Go Android SDK.
Go: Severe memory problems on 32bit Linux
71–80 of 159 posts
Re: Go: Severe memory problems on 32bit Linux
#72The problem itself seems quite serious and I would seriously reconsider using Go if I was interested in it in the first place, but after seeing the way this is treated by the Go "community", I am pretty sure I will never ever even think about using Go for anything.
the way this is treated by the Go "community" What do you mean?
Well, since the people behind Go did not up front say anything about the language/compiler being specifically targeted at 64-bit platforms, I would expect someone more mature from the Go team to step up and say something like "We are sorry, we didn't foresee the consequences of some design decisions and hence screwed it up." and either "We will fix it ASAP" or "We cannot fix it because XYZ". They might not take money for their work directly from the users, but there is still some moral obligation if you create something, release it to the world, praise its virtues and persuade people to use it. As it can be seen in the thread, lots of people already invested lots of time into building things with Go and now they're in serious trouble. Instead, many people in this thread try to somehow downplay the problem, advocate changing hardware (that's something quite new in the programming language world) or following some pretty absurd guidelines. This might or might not be representative of the whole community around Go, but it surely leaves a bad taste, hence the slight irony.
Re: Go: Severe memory problems on 32bit Linux
#73Earlier quoted context omitted.
Go 1 defines and the backwards-compatibility guarantees one can expect as the language matures. It's more a statement about the language specification than it is about the implementations. I know from experience that the gc 64-bit version is production ready. It's unfortunate that the limitations of the 32-bit version are not called out clearly on the website.
>I know from experience that the gc 64-bit version is production ready. Is it really production ready though, or is it the same half-arsed implementation as the 32-bit one, just taking advantage of the larger availability of virtual memory on a 64 bit system?
If Google is, and has been for quite some time, using it for large-scale systems in production, I would call it production ready.
Re: Go: Severe memory problems on 32bit Linux
#74Earlier quoted context omitted.
There was some back-and-forth between Zed Shaw and DHH that I remember being interested by at the time. Zed deleted all his posts - but here are some places to get started: - Shaw's opening volley: http://web.archive.org/web/20080103072111/http://www.zedshaw... [lots of stupid personal flames - but his technical points are consistent with what I remember from the time] - DHH's response: http://david.heinemeierhansson…
I certainly wasn't anywhere in the loop, but at least on my site, FastCGI didn't work, and Mongrel did. Zed's rant/flame goes into so much personal detail that he doesn't really articulate the point. Rails was receiving this enormous amount of hype, but there wasn't even a working application server yet.
No one cares how the sausage is made. They care that they have sausage. I write code to make money, not for uptime competitions. If something that makes money needs to be restarted every 4 minutes and customers are willing to pay for it why should I give a shit?
Re: Go: Severe memory problems on 32bit Linux
#75Earlier quoted context omitted.
the way this is treated by the Go "community" What do you mean?
Well, since the people behind Go did not up front say anything about the language/compiler being specifically targeted at 64-bit platforms, I would expect someone more mature from the Go team to step up and say something like "We are sorry, we didn't foresee the consequences of some design decisions and hence screwed it up." and either "We will fix it ASAP" or "We cannot fix it because XYZ". They might not take money…
There is an "official" response: the post references a bug # where Russ Cox said "the rest of the issue will have to wait until after Go 1".
Note that Go 1 is a "language freeze", not the implementation freeze.
Now that it's known there's a bug that will be worked on later, people proposed possible workarounds, the easiest of which is to switch to 64-bit platform. I agree that downplaying the issue is wrong, but only one person did that.
There is occasional rudeness, mostly caused by strong opinions, but overall I think Go community is pretty good.
Re: Go: Severe memory problems on 32bit Linux
#76Are most Androids 32-bit? Doesn't this issue impact the GO Android SDK adoption?
> Are most Androids 32-bit?
By virtue of there being no AArch64 implementation announced so far, all androids are 32-bit because there is no 64b ARM core.
> Doesn't this issue impact the GO Android SDK adoption?
Any Go application should be able to run into this issue if it has a similar usage pattern.
Re: Go: Severe memory problems on 32bit Linux
#77It's amazing how nonchalant they are about this 'oh sure we'll fix it in a year or so' when the garbage collector is basically all there needs to be in a Google Go runtime Some comments were asking why early Java's GC wasn't this bad even though it was conservative. The reason is that Java can't take references to fields of an object, so the data mistaken as a pointer has to actually point to an object header. In Goo…
I think the reasons they don't care more are
1) it mainly affects long time running applications on 32 bits machines. Fact is most production servers are (or should be) on 64 bits
2) most people (me for example) never observed such a phenomenon (and all my dev computers are 32 bits)
So, that's an important problem but far from a game stopper.
Re: Go: Severe memory problems on 32bit Linux
#78Earlier quoted context omitted.
D is pretty strong at concurrency today. See for instance http://www.informit.com/articles/article.aspx?p=1609144 and http://ddili.org/ders/d.en/parallelism.html
It's strange that with all those threading examples, they didn't notice the need for a WaitGroup primitive. I know that you could implement it yourself. You could simulate the goroutines, implement channels and SCGI/FCGI and so on, but why bother when there is Go ?
Probably because there is no need for it ? If WaitGroup waits for the end of all tasks to continue, there is map/reduce which should do the trick.
Re: Go: Severe memory problems on 32bit Linux
#79Interesting piece of information below in the thread: in reply to "Go being advertised as a systems PL", David Symonds replies with: "It's not. It used to be, but it's not any more."
Re: Go: Severe memory problems on 32bit Linux
#80Interesting piece of information below in the thread: in reply to "Go being advertised as a systems PL", David Symonds replies with: "It's not. It used to be, but it's not any more."
What is the definition of a system PL ?