3 ms·

I was planning to use Go on a new project, but there were two blockers that made me decide against using it: the 32bit memleak issue and lack of support for old

I was planning to use Go on a new project, but there were two blockers that made me decide against using it: the 32bit memleak issue and lack of support for older Linux distros. The go guys seem very dismissive of valid concerns from developers who really want to use Go: e.g. Sarcasm for users who need to run on older linux kernels and distros: http://code.google.com/p/go/issues/detail?id=3211#c14 http://code.google.com/p/go/issues/detail?id=3211#c14 e.g. Solutions for 32bit memory leak is: works for me on 64bit: http://www.youtube.com/watch?v=kKQLhGZVN4A http://www.youtube.com/watch?v=kKQLhGZVN4A I bought a book on Go and was planning to use it for a new project, but decided against it after seeing the disregard for developers with valid concerns who want to use the language.

srik 14y ago
1. The 32 bit memleak is indeed a prioirity and the Go team has made definitive statements about dealing within coming couple weeks. 2. Most of the team is a bit young and cheeky but they do mean business and actually engage the public very patiently about modifications/improvements etc in their mailing list. The dismissive attitude is usually them trying to stick to their core goals of making go an expressive, orthognal and highly readable language. Usually they have good enough reasons for picking a choice. I would seriously recommend you to "not browse through" some source code but rather "play" with it. It really does feel different. Its like the feel of a quick dynamic language but on a more type safe static language. Its kindof fun at the least. Not the mention their CSR inspired concurrency approach. Its really interesting. Give it a shot, what you got to lose?
- thebluesky 14y ago
  Thanks for the info. I would probably take another look at it if they provided official binaries compatible with RHEL/CentOS 5. A fix or mitigation for the 32 bit memleak would be good too.
genwin 14y ago
Do you know if the memory leak still exists on 64-bit? I wasn't able to determine that. I've read that the solution is to use 64-bit, but I don't know if that really just means that a 64-bit system will take the memory leak far longer to crash it. I'm not too concerned about the attitude of some Golang devs (they are volunteers, after all), but I am very concerned about any memory leak or other serious bug that won't be fixed for a year+.
- thebluesky 14y ago
  My understanding is that they are mostly Google employees rather than volunteers. Go uses a conservative GC which means that the probability of a leak is much lower on a 64 bit system rather than that a 64 bit system has more headroom to leak before it crashes.
  - genwin 14y ago
    Thanks for that simple explanation. My use case is fine with 64-bit only, so I'll proceed with Golang. I would probably decline if I needed to support 32-bit, given how nasty memory leaks are.
  - enneff 14y ago
    64-bit systems have so much more address space that the issue will never manifest on 64-bit systems. At least, not in the next 100 years.
    - thebluesky 14y ago
      Please make a plan about official binaries for RHEL/CentOS 5. Yes it's an old kernel, but it's still used heavily by many organizations.
    - deleted 14y ago
      [deleted]
enneff 14y ago
I don't think the examples you've provided here are indicative of a generally dismissive attitude. There's more nuance than you realize. > Sarcasm for users who need to run on older linux kernels and distros The person Russ is sarcastically replying to is someone we know; a contributor to the project. I can see how it might look a bit blunt from the outside. Perhaps more illuminating is Russ' later comment on the issue: "Old operating systems will always be with us. The fact that in 2020 people will be running a Linux distribution that forked the kernel 13 years earlier does not mean we have to support it." Which I feel is entirely reasonable. > Solutions for 32bit memory leak is: works for me on 64bit We've acknowledged the issue and work is in progress to fix it. In the meantime, however, "It works on 64-bit" is a legitimate response because it's true, and there is nothing you could do to help the programs that were affected on 32-bit systems. We never closed the issue was "works for me," we just said that's a reasonable workaround for some people. The Go developers and wider community care a great deal about our users. We have some of the fastest bug fix turnaround of any project I've seen. We do, however, have our goals and priorities and sometimes people don't agree with them. There's not a lot you can do about that.

srik 14y ago

1. The 32 bit memleak is indeed a prioirity and the Go team has made definitive statements about dealing within coming couple weeks. 2. Most of the team is a bit young and cheeky but they do mean business and actually engage the public very patiently about modifications/improvements etc in their mailing list. The dismissive attitude is usually them trying to stick to their core goals of making go an expressive, orthognal and highly readable language. Usually they have good enough reasons for picking a choice. I would seriously recommend you to "not browse through" some source code but rather "play" with it. It really does feel different. Its like the feel of a quick dynamic language but on a more type safe static language. Its kindof fun at the least. Not the mention their CSR inspired concurrency approach. Its really interesting. Give it a shot, what you got to lose?

thebluesky 14y ago
Thanks for the info. I would probably take another look at it if they provided official binaries compatible with RHEL/CentOS 5. A fix or mitigation for the 32 bit memleak would be good too.

genwin 14y ago

Do you know if the memory leak still exists on 64-bit? I wasn't able to determine that. I've read that the solution is to use 64-bit, but I don't know if that really just means that a 64-bit system will take the memory leak far longer to crash it. I'm not too concerned about the attitude of some Golang devs (they are volunteers, after all), but I am very concerned about any memory leak or other serious bug that won't be fixed for a year+.

thebluesky 14y ago
My understanding is that they are mostly Google employees rather than volunteers. Go uses a conservative GC which means that the probability of a leak is much lower on a 64 bit system rather than that a 64 bit system has more headroom to leak before it crashes.
- genwin 14y ago
  Thanks for that simple explanation. My use case is fine with 64-bit only, so I'll proceed with Golang. I would probably decline if I needed to support 32-bit, given how nasty memory leaks are.
- enneff 14y ago
  64-bit systems have so much more address space that the issue will never manifest on 64-bit systems. At least, not in the next 100 years.
  - thebluesky 14y ago
    Please make a plan about official binaries for RHEL/CentOS 5. Yes it's an old kernel, but it's still used heavily by many organizations.
  - deleted 14y ago
    [deleted]

enneff 14y ago

I don't think the examples you've provided here are indicative of a generally dismissive attitude. There's more nuance than you realize. > Sarcasm for users who need to run on older linux kernels and distros The person Russ is sarcastically replying to is someone we know; a contributor to the project. I can see how it might look a bit blunt from the outside. Perhaps more illuminating is Russ' later comment on the issue: "Old operating systems will always be with us. The fact that in 2020 people will be running a Linux distribution that forked the kernel 13 years earlier does not mean we have to support it." Which I feel is entirely reasonable. > Solutions for 32bit memory leak is: works for me on 64bit We've acknowledged the issue and work is in progress to fix it. In the meantime, however, "It works on 64-bit" is a legitimate response because it's true, and there is nothing you could do to help the programs that were affected on 32-bit systems. We never closed the issue was "works for me," we just said that's a reasonable workaround for some people. The Go developers and wider community care a great deal about our users. We have some of the fastest bug fix turnaround of any project I've seen. We do, however, have our goals and priorities and sometimes people don't agree with them. There's not a lot you can do about that.