Your history is a little mixed up there. The original author of Turbo Pascal, and Chief Architect of Delphi, became the Lead Architect of C#. It’s not like Microsoft came out of nowhere and ate Borland’s lunch.
Depends on the elevation of the horizon.
> I expect discriminating by amount of relevant experience is fair, but that's not the same as age. As someone who started coding at age 9, I agree. :-) It's not about hiring someone in their 40s per se, but rather…
Agreed. I remember being in my early 20s, watching my more experienced colleagues, and realizing this. I had had a different (incorrect) mental model: I had thought intellect was as good as experience, so Ability =…
This. I used to work at IBM, and I can't tell you how many different (mutually inconsistent) narratives about "how IBM is".
Huh? That's funny--I would have said the opposite. It was from watching Obama's speeches that I learned that silent pauses can be much less annoying than "umms". If you want to see someone using a lot of "umms", watch…
Nope. Transactions, in the sense of the article, bear no relation to goroutines. The right answer is that Java's generational collector supports this transaction lifetime reasonably well in many cases.
RAII is using one C++ misfeature (destructors) to work around another misfeature (inability to do cleanup when leaving a lexical scope). Go has a far more elegant solution to the latter; if you're not familiar with the…
I'm not sure you've grasped the write barrier part. That's the really new part.
Did you read the article? It answers your question. Take a look at the section that begins with this: The problem is called a paradox because two analyses that both sound intuitively logical give conflicting answers to…
(Whoops, I've misunderstood you twice. I think my other reply answered the wrong question. Let me try again.) I didn't say synchronization can prevent EA. I said that calling a finalizer on an application thread can…
I must have misunderstood you. You made a statement that I parsed as follows: "If (this stuff isn't escaping) then (the JIT can prove that it isn't using a lock)." That is logically equivalent to: "If not (the JIT can…
Your argument proves that the time taken can be no less than O(n) in the number of object references in live objects. The (potentially billions of) unreachable objects are never touched. I agree that limited RAM…
I seem to have hit a nerve here. Perhaps I haven't been clear about some of the points I'm making, which I don't think are all that contentious. I'm not saying a fast GC can reduce the cost of allocation. I'm saying a…
Well, it's hard to deny that the work done by the program is O(n) (or even Ω(n)) in the number of objects created by the program. That's almost tautological. The thing that is interesting about the asymptotic complexity…
The JVM doesn't release the memory to the OS when garbage is collected; only when the heap shrinks. Any zeroing the OS might do is proportional to the size change in the heap, not to the number of objects freed.
I think you're referring to a mark and sweep collector. Java's garbage collector uses better algorithms. The collector never even looks at objects that are not referenced from the root set, and an allocation operation…
Actually, synchronization is not an escape. Objects can be stack-allocated in methods that do synchronization.
"Go compiles to native code. Java, ultimately, does too, but compilation happens at runtime, which is an overhead that Go doesn’t have, so in principle Go should be faster." Oh boy. It pains me every time I hear this.…
Poof! There goes finite automata, and therefore regular expressions. :-)
It's hard to say. The finalization spec is subtle. To make this work, the JIT would need to perform escape analysis on the finalizer too (since the finalizer can make an object escape). If that analysis succeeds, then I…
Me too. I would fully expect the JIT compiler to remove this call unless it's more complicated than it sounds. I don't think this is a real fix. I work on IBM's JIT compiler. We had to do something similar to fix this…
"I wish that when GC encountered a cycle it would just tell the programmer that they now have a leak..." Wow. Overreact much? :-) Garbage collection works great for one use case: managing heap memory. Please, let's not…
Your history is a little mixed up there. The original author of Turbo Pascal, and Chief Architect of Delphi, became the Lead Architect of C#. It’s not like Microsoft came out of nowhere and ate Borland’s lunch.
Depends on the elevation of the horizon.
> I expect discriminating by amount of relevant experience is fair, but that's not the same as age. As someone who started coding at age 9, I agree. :-) It's not about hiring someone in their 40s per se, but rather…
Agreed. I remember being in my early 20s, watching my more experienced colleagues, and realizing this. I had had a different (incorrect) mental model: I had thought intellect was as good as experience, so Ability =…
This. I used to work at IBM, and I can't tell you how many different (mutually inconsistent) narratives about "how IBM is".
Huh? That's funny--I would have said the opposite. It was from watching Obama's speeches that I learned that silent pauses can be much less annoying than "umms". If you want to see someone using a lot of "umms", watch…
Nope. Transactions, in the sense of the article, bear no relation to goroutines. The right answer is that Java's generational collector supports this transaction lifetime reasonably well in many cases.
RAII is using one C++ misfeature (destructors) to work around another misfeature (inability to do cleanup when leaving a lexical scope). Go has a far more elegant solution to the latter; if you're not familiar with the…
I'm not sure you've grasped the write barrier part. That's the really new part.
Did you read the article? It answers your question. Take a look at the section that begins with this: The problem is called a paradox because two analyses that both sound intuitively logical give conflicting answers to…
(Whoops, I've misunderstood you twice. I think my other reply answered the wrong question. Let me try again.) I didn't say synchronization can prevent EA. I said that calling a finalizer on an application thread can…
I must have misunderstood you. You made a statement that I parsed as follows: "If (this stuff isn't escaping) then (the JIT can prove that it isn't using a lock)." That is logically equivalent to: "If not (the JIT can…
Your argument proves that the time taken can be no less than O(n) in the number of object references in live objects. The (potentially billions of) unreachable objects are never touched. I agree that limited RAM…
I seem to have hit a nerve here. Perhaps I haven't been clear about some of the points I'm making, which I don't think are all that contentious. I'm not saying a fast GC can reduce the cost of allocation. I'm saying a…
Well, it's hard to deny that the work done by the program is O(n) (or even Ω(n)) in the number of objects created by the program. That's almost tautological. The thing that is interesting about the asymptotic complexity…
The JVM doesn't release the memory to the OS when garbage is collected; only when the heap shrinks. Any zeroing the OS might do is proportional to the size change in the heap, not to the number of objects freed.
I think you're referring to a mark and sweep collector. Java's garbage collector uses better algorithms. The collector never even looks at objects that are not referenced from the root set, and an allocation operation…
Actually, synchronization is not an escape. Objects can be stack-allocated in methods that do synchronization.
"Go compiles to native code. Java, ultimately, does too, but compilation happens at runtime, which is an overhead that Go doesn’t have, so in principle Go should be faster." Oh boy. It pains me every time I hear this.…
Poof! There goes finite automata, and therefore regular expressions. :-)
It's hard to say. The finalization spec is subtle. To make this work, the JIT would need to perform escape analysis on the finalizer too (since the finalizer can make an object escape). If that analysis succeeds, then I…
Me too. I would fully expect the JIT compiler to remove this call unless it's more complicated than it sounds. I don't think this is a real fix. I work on IBM's JIT compiler. We had to do something similar to fix this…
"I wish that when GC encountered a cycle it would just tell the programmer that they now have a leak..." Wow. Overreact much? :-) Garbage collection works great for one use case: managing heap memory. Please, let's not…