5 ms·

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 i

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.

nakkiel 15y ago
Clearly, there was a need for "Hey, things won't change as much from now on". Now, I'm still afraid little work will appear on the GC, which is IMO Go's biggest weakness to date.
- dchest 15y ago
  Now, I'm still afraid little work will appear on the GC No need to guess, look at golang-dev https://groups.google.com/forum/?fromgroups#!forum/golang-dev https://groups.google.com/forum/?fromgroups#!forum/golang-de...
  - nakkiel 15y ago
    Oh yeah thanks. I guess I'm doing it wrong :) Glad to see some work on that front.
batista 15y ago
>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?
- oskarth 15y ago
  If Google is, and has been for quite some time, using it for large-scale systems in production, I would call it production ready.
  - thrownaway2424 15y ago
    Is there any reason to believe that Google uses Go for large-scale production systems?
    - deleted 15y ago
      [deleted]
    - 4ad 15y ago
      Yes, it's used by YouTube, in a very critical path, large scale enough :)? https://groups.google.com/forum/#!msg/golang-nuts/U5ilNZpXzNU/kfOS2iFdpAsJ https://groups.google.com/forum/#!msg/golang-nuts/U5ilNZpXzN... http://code.google.com/p/vitess/ http://code.google.com/p/vitess/
- ghusbands 15y ago
  On 32-bit systems, the problem is that there's a very high chance of non-pointer data looking like pointers to existing data, which, in turn might have its own pointer-like data. This means that you can end up keeping an excessive amount of unreferenced data. However, a 64-bit address space is so much larger that you can't really suffer the same issue. Unlike on 32-bit systems, neither high entropy data nor text will look like valid pointers. Therefore, the technique can be validly described as production-ready for 64-bit systems.
  - jerf 15y ago
    Hmmmmm... I'm smelling memory-based DoS if I, say, upload carefully crafted files to a webserver. What accidentally happens in 32-bit may be deliberately triggered in 64-bit.
    - agentS 15y ago
      This is impossible. I don't like to make absolute statements, but I'll stand by this one. In order to pull of an attack, you'd need to know what address range the program in question has been allocated, then figure out the smaller range that the runtime is actively using, then give it data with integers in that range. This is impractical. If you think you can pull it off play.golang.org lets you upload text to a Go program on Appengine, then it compiles that program and runs it. This gives you 2 programs to attack, the playground binary, and the one compiled from your source. If you can do it, you'll have a way to kill machines inside Google. Good luck.
  - ArbitraryLimits 15y ago
    Can someone help me out here with a TL;DR? This is my first exposure ever to any technical aspect of Go, and this discussion makes it sound from this discussion like it doesn't use any tag bits in its pointers, but has its garbage collector run heuristics on the data it examines to see whether it "looks like text" to decide whether to collect it? I know that can't possibly be correct.
    - Arelius 15y ago

nakkiel 15y ago

Clearly, there was a need for "Hey, things won't change as much from now on". Now, I'm still afraid little work will appear on the GC, which is IMO Go's biggest weakness to date.

dchest 15y ago
Now, I'm still afraid little work will appear on the GC No need to guess, look at golang-dev https://groups.google.com/forum/?fromgroups#!forum/golang-dev https://groups.google.com/forum/?fromgroups#!forum/golang-de...
- nakkiel 15y ago
  Oh yeah thanks. I guess I'm doing it wrong :) Glad to see some work on that front.

batista 15y ago

>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?

oskarth 15y ago
If Google is, and has been for quite some time, using it for large-scale systems in production, I would call it production ready.
- thrownaway2424 15y ago
  Is there any reason to believe that Google uses Go for large-scale production systems?
  - deleted 15y ago
    [deleted]
  - 4ad 15y ago
    Yes, it's used by YouTube, in a very critical path, large scale enough :)? https://groups.google.com/forum/#!msg/golang-nuts/U5ilNZpXzNU/kfOS2iFdpAsJ https://groups.google.com/forum/#!msg/golang-nuts/U5ilNZpXzN... http://code.google.com/p/vitess/ http://code.google.com/p/vitess/
ghusbands 15y ago
On 32-bit systems, the problem is that there's a very high chance of non-pointer data looking like pointers to existing data, which, in turn might have its own pointer-like data. This means that you can end up keeping an excessive amount of unreferenced data. However, a 64-bit address space is so much larger that you can't really suffer the same issue. Unlike on 32-bit systems, neither high entropy data nor text will look like valid pointers. Therefore, the technique can be validly described as production-ready for 64-bit systems.
- jerf 15y ago
  Hmmmmm... I'm smelling memory-based DoS if I, say, upload carefully crafted files to a webserver. What accidentally happens in 32-bit may be deliberately triggered in 64-bit.
  - agentS 15y ago
    This is impossible. I don't like to make absolute statements, but I'll stand by this one. In order to pull of an attack, you'd need to know what address range the program in question has been allocated, then figure out the smaller range that the runtime is actively using, then give it data with integers in that range. This is impractical. If you think you can pull it off play.golang.org lets you upload text to a Go program on Appengine, then it compiles that program and runs it. This gives you 2 programs to attack, the playground binary, and the one compiled from your source. If you can do it, you'll have a way to kill machines inside Google. Good luck.
- ArbitraryLimits 15y ago
  Can someone help me out here with a TL;DR? This is my first exposure ever to any technical aspect of Go, and this discussion makes it sound from this discussion like it doesn't use any tag bits in its pointers, but has its garbage collector run heuristics on the data it examines to see whether it "looks like text" to decide whether to collect it? I know that can't possibly be correct.
  - Arelius 15y ago