4 ms·

Most importantly can go lang really take the place of C++

wglb 13y ago
Yes, please.
jerf 13y ago
In this situation, Rust seems more likely. Go may have sacrificed the absolute top end of performance by making GC an unavoidable memory management mechanism. You have a variety of tools to manage garbage generation with careful programming which aren't necessarily obvious on a casual reading of the spec, but AFAIK you can't actually fully escape the stop-the-world GC. It is not clear to me that Go will ever escape stop-the-world, either. There's still some room for it to get better, but the Erlang-esque "per process heap" will probably never be available, or at least, not for a long time and only when writing your code in a way the optimizer can understand. Still, you will be able to do "pretty darned well" in Go. And there's a lot of use cases for which that will be indistinguishable from the "absolute top end".
jandrewrogers 13y ago
No, a garbage-collected language cannot replace C++. Explicit control of memory and deterministic operation is an important tool for some types of software e.g. high-performance server software.
- masklinn 13y ago
  And no2, a language which can not be consumed by others can not replace C++. Because of the runtime requirements (both GC and goroutines), it is not possible to use a Go library through an FFI, you have to embed a go program instead as you do Python or Lua.
- 6d0debc071 13y ago
  I'm not sure there's any reason that garbage collecting and manual memory management can't exist in the same programming language. I can't think of any where they do, but it seems like you should be able to assign memory manually and have that as an exception. :/
  - 0x1997 13y ago
    Rust supports both manual memory management and GC.
  - plorkyeran 13y ago
    C# supports manual memory management (in "unsafe" blocks). They don't coexist very well because a standard library written for manual memory management looks rather different than one written for GC.
- trimbo 13y ago
  Azul has made a JVM with predictable GC. http://www.azulsystems.com/technology/java-garbage-collection http://www.azulsystems.com/technology/java-garbage-collectio... So yes, it is possible to have pauseless GC. That won't fit all problems that C++ is used for (like embedded), but it certainly hits on the server software side of things.
  - cwzwarich 13y ago
    To run it on x86, you need a heavily modified Linux kernel. You also sacrifice about 30% or so of your throughput on the extra operations that allow for the dramatically reduced latency, which may not be acceptable for some people.
  - jandrewrogers 13y ago
    I do not see how this solves the server software side of things. Most high performance server software (1) has precisely one process/thread per core and (2) takes complete control of its memory management. These behaviors have substantial performance benefits. A GC thread of any type will bleed performance, and that is ignoring the loss of performance from poor memory and cache efficiency that is inherent with GCs. High performance server code is one of those areas that highlights where GCs are inappropriate. I've written quite a few server engines in GC languages; you expect to see about half the performance of C/C++ as a rule of thumb. Most modern server software performance is significantly bound by memory bandwidth and latency. Introducing inefficiencies in this area tends to result in material degradation of software throughput. In fact, this is the only substantial advantage of C/C++; it can be efficient with memory access, caching, and utilization in a way that no GC language can be, and these are major contributing factors to performance.
    - cbsmith 13y ago
      The notion that poor memory cache efficiency is inherent with GC's is not terribly well founded. Copying collectors (like the one the HotSpot VM uses for Eden Space) tend to have great cache efficiency as compared to typical use of the C heap, where you can't relocate chunks of correlated memory together. Even mark-and-sweep collectors can do quite well for themselves. I'd actually say quite the opposite of what you are saying: in a server environment, you often care more about throughput and mean latency (as opposed to 99th %-ile latency), and GC can really do great there. What's nice is that GC allows you to have near zero cost heap allocations and amortizes the cost of cleanup. What tends to be the problem is a lot of languages with GC make it difficult to efficiently work with the systems's buffer cache, so you typically see problems with systems that do disk I/O with large amounts of data. I've written a LOT of C/C++ & JVM based servers. Particularly for large projects with a lot of independent moving parts and object lifecycles that are not tightly tied to sessions, the JVM based servers are remarkably competitive if they aren't disk IO bound. There's a reason why a lot of HFT firms use Java... C/C++ still kicks butt for tightly written servers with fairly fixed functions, and generally for anything that does tons of disk IO (though the Cassandra guys have, as an example, demonstrated one can do quite well if you take the time to get it right), and of course anything with unsigned arithmetic (seriously, when are we going to acknowledge that this was a bad idea?).
- fsck--off 13y ago
  Nonsense. Most languages that include garbage collection allow you to turn it off; the same languages also allow you to explicitly control memory.
  - shadowfox 13y ago
    > Most languages that include garbage collection allow you to turn it off Hmm. Clearly I don't know much about this. How do you turn off garbage collection in Java and (say) Python?
    - kasey_junk 13y ago
      Can't say for python but in Java off heap steuctures are pretty standard for performance critical components.
      - shadowfox 13y ago
        Interesting. Are there APIs to do this?
    - tedivm 13y ago
      Python call gc.disable(). I'm not aware of any way to do it in Java other than raising the memory to available to such a high level that it doesn't become an issue (which would probably only work with processes that died, as opposed to long running programs).
      - gcr 13y ago
        gc.disable() introduces an unavoidable memory leak in my program. I also can't control the memory usage of the libraries I link against.
  - coldtea 13y ago
    >Nonsense. Most languages that include garbage collection allow you to turn it off; the same languages also allow you to explicitly control memory. BS. Most languages don't allow you to turn off their GC, except if by it you mean doing silly tricks and jumping through hoops, using tons of memory to avoid having to GC, using pools of pre-allocated objects, not using any standard libs, etc. Even then, they are not callable from outside code (like C is and Rust tried to be) and memory use is huge.
deleted 13y ago
[deleted]
cdavid 13y ago
Not likely because things like gc makes interoperability with other languages difficult. Pretty much every language can interoperate with C.

wglb 13y ago

Yes, please.

jerf 13y ago

In this situation, Rust seems more likely. Go may have sacrificed the absolute top end of performance by making GC an unavoidable memory management mechanism. You have a variety of tools to manage garbage generation with careful programming which aren't necessarily obvious on a casual reading of the spec, but AFAIK you can't actually fully escape the stop-the-world GC. It is not clear to me that Go will ever escape stop-the-world, either. There's still some room for it to get better, but the Erlang-esque "per process heap" will probably never be available, or at least, not for a long time and only when writing your code in a way the optimizer can understand. Still, you will be able to do "pretty darned well" in Go. And there's a lot of use cases for which that will be indistinguishable from the "absolute top end".

jandrewrogers 13y ago

No, a garbage-collected language cannot replace C++. Explicit control of memory and deterministic operation is an important tool for some types of software e.g. high-performance server software.

masklinn 13y ago
And no2, a language which can not be consumed by others can not replace C++. Because of the runtime requirements (both GC and goroutines), it is not possible to use a Go library through an FFI, you have to embed a go program instead as you do Python or Lua.
6d0debc071 13y ago
I'm not sure there's any reason that garbage collecting and manual memory management can't exist in the same programming language. I can't think of any where they do, but it seems like you should be able to assign memory manually and have that as an exception. :/
- 0x1997 13y ago
  Rust supports both manual memory management and GC.
- plorkyeran 13y ago
  C# supports manual memory management (in "unsafe" blocks). They don't coexist very well because a standard library written for manual memory management looks rather different than one written for GC.
trimbo 13y ago
Azul has made a JVM with predictable GC. http://www.azulsystems.com/technology/java-garbage-collection http://www.azulsystems.com/technology/java-garbage-collectio... So yes, it is possible to have pauseless GC. That won't fit all problems that C++ is used for (like embedded), but it certainly hits on the server software side of things.
- cwzwarich 13y ago
  To run it on x86, you need a heavily modified Linux kernel. You also sacrifice about 30% or so of your throughput on the extra operations that allow for the dramatically reduced latency, which may not be acceptable for some people.
- jandrewrogers 13y ago
  I do not see how this solves the server software side of things. Most high performance server software (1) has precisely one process/thread per core and (2) takes complete control of its memory management. These behaviors have substantial performance benefits. A GC thread of any type will bleed performance, and that is ignoring the loss of performance from poor memory and cache efficiency that is inherent with GCs. High performance server code is one of those areas that highlights where GCs are inappropriate. I've written quite a few server engines in GC languages; you expect to see about half the performance of C/C++ as a rule of thumb. Most modern server software performance is significantly bound by memory bandwidth and latency. Introducing inefficiencies in this area tends to result in material degradation of software throughput. In fact, this is the only substantial advantage of C/C++; it can be efficient with memory access, caching, and utilization in a way that no GC language can be, and these are major contributing factors to performance.
  - cbsmith 13y ago
    The notion that poor memory cache efficiency is inherent with GC's is not terribly well founded. Copying collectors (like the one the HotSpot VM uses for Eden Space) tend to have great cache efficiency as compared to typical use of the C heap, where you can't relocate chunks of correlated memory together. Even mark-and-sweep collectors can do quite well for themselves. I'd actually say quite the opposite of what you are saying: in a server environment, you often care more about throughput and mean latency (as opposed to 99th %-ile latency), and GC can really do great there. What's nice is that GC allows you to have near zero cost heap allocations and amortizes the cost of cleanup. What tends to be the problem is a lot of languages with GC make it difficult to efficiently work with the systems's buffer cache, so you typically see problems with systems that do disk I/O with large amounts of data. I've written a LOT of C/C++ & JVM based servers. Particularly for large projects with a lot of independent moving parts and object lifecycles that are not tightly tied to sessions, the JVM based servers are remarkably competitive if they aren't disk IO bound. There's a reason why a lot of HFT firms use Java... C/C++ still kicks butt for tightly written servers with fairly fixed functions, and generally for anything that does tons of disk IO (though the Cassandra guys have, as an example, demonstrated one can do quite well if you take the time to get it right), and of course anything with unsigned arithmetic (seriously, when are we going to acknowledge that this was a bad idea?).
fsck--off 13y ago
Nonsense. Most languages that include garbage collection allow you to turn it off; the same languages also allow you to explicitly control memory.
- shadowfox 13y ago
  > Most languages that include garbage collection allow you to turn it off Hmm. Clearly I don't know much about this. How do you turn off garbage collection in Java and (say) Python?
  - kasey_junk 13y ago
    Can't say for python but in Java off heap steuctures are pretty standard for performance critical components.
    - shadowfox 13y ago
      Interesting. Are there APIs to do this?
  - tedivm 13y ago
    Python call gc.disable(). I'm not aware of any way to do it in Java other than raising the memory to available to such a high level that it doesn't become an issue (which would probably only work with processes that died, as opposed to long running programs).
    - gcr 13y ago
      gc.disable() introduces an unavoidable memory leak in my program. I also can't control the memory usage of the libraries I link against.
- coldtea 13y ago
  >Nonsense. Most languages that include garbage collection allow you to turn it off; the same languages also allow you to explicitly control memory. BS. Most languages don't allow you to turn off their GC, except if by it you mean doing silly tricks and jumping through hoops, using tons of memory to avoid having to GC, using pools of pre-allocated objects, not using any standard libs, etc. Even then, they are not callable from outside code (like C is and Rust tried to be) and memory use is huge.

deleted 13y ago

[deleted]

cdavid 13y ago

Not likely because things like gc makes interoperability with other languages difficult. Pretty much every language can interoperate with C.