5 ms·

> But most likely - you simply do not need a language without a GC. Absolutely. That doesn't mean I can't want predictable performance or deterministic destruc

> But most likely - you simply do not need a language without a GC. Absolutely. That doesn't mean I can't want predictable performance or deterministic destruction. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up (i.e. on the overhead of managed runtimes and GCs). Before, I'd have argued that it was just necessary. Having spent a bunch of time with Rust, I don't think so any more, and I'm really excited to see non-GC languages build on Rust's ideas in the future. > Hadoop stack with especially Cassandra, Elasticsearch? Java. Prometheus and InfluxDB? Go. Cassandra has a drop-in-ish C++ replacement (Scylla, IIRC?) which supposedly blows the Java implementation away in performance. A magic JIT (and HotSpot is really magic) doesn't make everything better all of a sudden. In a somewhat recent panel (https://www.infoq.com/presentations/c-rust-go https://www.infoq.com/presentations/c-rust-go), the CEO of InfluxDB basically admitted that if Rust had been more stable when they started they would have been able to use it instead of Go and would have had to do far fewer shenanigans to avoid the GC penalty. > Just face it: there is an need for something intermediate to fill the gap of a script-like, native compiled, low-overhead, modern language, and a GC is part of this. Indeed. I'm not in denial of this. I made an offhand remark about my personal preferences and what I'd like to see from future languages. I still write a ton of Python for things where speed really doesn't matter. > "oh no, a GC!" knee-jerk reaction I don't think having a refreshing experience without a GC counts as a "knee-jerk reaction." I've thoroughly enjoyed not having to tune that aspect of performance, and I remarked on it. I think Crystal shows great promise, and certainly has the potential to offer easier ergonomics than Rust.

pjmlp 10y ago
The C++ advantage will not be so much after Java 10 comes out and finally have the value types and reified generics the language should have had since beginning. Also I am yet to see any large scale production deployment of those Hadoop alternatives. But it might still be like 5 years from now, so who knows how it will evolve.
- dikaiosune 10y ago
  Re: deployments, I expect that would take some time for a transition to occur. The first post date on the ScyllaDB blog is from February 2015 (http://www.scylladb.com/2015/02/20/seastar/ http://www.scylladb.com/2015/02/20/seastar/), and it looks like it wasn't until September 2015 that they specifically started publishing benchmarks of the database itself as opposed to the network I/O library they built for it (http://www.scylladb.com/2015/09/22/watching_scylla_serve_1m/ http://www.scylladb.com/2015/09/22/watching_scylla_serve_1m/). I look forward to those changes coming to Java, and I think that stack-based value types could do a lot for the language. That said, the Scylla folks seem to have gotten a lot of their performance gains from CPU/thread affinity and async I/O (http://www.scylladb.com/2016/03/18/generalist-engineer-cassandra-performance/ http://www.scylladb.com/2016/03/18/generalist-engineer-cassa...). NIO is pretty great in Java-land, IIRC, but CPU/thread affinity is, I imagine, hard to pull off with a garbage collector. Another thing I'm curious about w.r.t. value types in Java -- hasn't C# had those for a while? If so, and if your claim that value types will provide large performance benefits is true, why isn't C# always blowing Java away in benchmarks? Perhaps it is and I'm just not seeing them. Perhaps Java's escape analysis is already pretty good and solve the 60/70/80% case? Perhaps I'm not well versed enough in the subject to understand the interactions here.
  - pjmlp 10y ago
    Regarding C#, Microsoft hasn't invested too much on their JIT/AOT compilers optimization algorithms. NGEN was just good enough for allowing quick application startup. Also they didn't invest too much in optimizations in the old JIT. Specially since .NET always had good interop to native code via C++/CLI, P/Invoke and RCW. There were some improvements like multicore JIT in .NET 4.0 and PGO support in .NET 4.5, but not much in terms of optimization algorithms. Hence why .NET 4.6 got a new revamped JIT called RyuJIT with SIMD support and lots of nice optimizations. But this is only for the desktop. .NET for the Windows Store is AOT compiled with the same backend that Visual C++ uses. In the Windows 8 and 8.1 they came up with MDIL from Singularity/Midori but with 10 they improved the workflow to what is nowadays known as .NET Native. With the ongoing refactorings they plan to make C2 (Visual C++ backend) a kind of LLVM for their languages, similar to the Phoenix MSR project they did a few years ago. If you watch the Build 2015 and 2016 talks, most of them are making use of C# with the new WinRT (COM based) APIs, leaving C++ just for the DX related ones. So they are quite serious about taking their learnings from project Midori and improve the overall .NET performance.
- bluejekyll 10y ago
  Java 10? I'm still waiting for Jigsaw (originally slated for 1.8, is it coming in 1.9???)
  - pjmlp 10y ago
    No need to wait. https://jdk9.java.net/download/ https://jdk9.java.net/download/
    - jerven 10y ago
      And Jigsaw has landed, build 116 if I recall (too lazy to look it up)
- whateveracct 10y ago
  > value types and reified generics I think you mean specialized generics (i.e. no autoboxing of primitives when used in generics)? Reified generics implies carrying around all generic type information at runtime, which will not be the case and also has nothing to do with performance. Non-value generics will still be erased I thought.
  - pjmlp 10y ago
    Have you seen the status update? https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_&index=3 https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3Ar... They will change the constant pool to have some kind of template information that gets specialized (what they call type species) into a specific set of types. The plan is even if Java cannot fully take advantage of all possibilities due to backwards compatibility with existing libraries in binary format, the JVM will support it for other languages not tied to Java semantics and backwards compatibility.
bluejekyll 10y ago
> That doesn't mean I can't want predictable performance or deterministic destruction. Exactly. To just add to your point, there is no longer a reason to settle for GC pauses with Rust. It does require more thought while writing the code, but what you gain is a firmly consistent runtime. If your memory allocation is slow, you can create your own allocator/slab, and then use that for hot memory space and optimize it out. As a longtime Java geek who never understood the argument against GC, this has been a mind altering experience. I was a big C++ person before, but after one too many memory leaks and segfaults, I could never imagine not wanting a GC. Then Rust came along and taught me better.
- mike_hearn 10y ago
  Two reasons: 1) Rust appears to be significantly less productive than a true GCd language. I see a lot of people talking about "fighting the borrow checker" with Rust and I see a lot of articles describing basic patterns that would be simple in any other language, but are complex in Rust. 2) If you want to invoke code that assumes a GC you need to have one. You can do manual memory allocation in Java by the way and a few high performance libraries do. It's just not common. It's interesting to note that the Chrome guys have gone in the direction of deploying a GC into C++ whereas the Mozilla guys have gone in the direction of moving manual memory management into the type system. I've got nothing against Rust but I'm a Chrome user, personally.
  - dbaupp 10y ago
    Mozilla has also put significant effort into improving their C++ GC in Firefox, e.g. switching from a non-generational one to a generation GC[0] and then to a compacting one[1]. Just like Google can both improve Chrome and work on Go, Mozilla both improves Firefox and works on Rust. [0]: https://hacks.mozilla.org/2014/09/generational-garbage-collection-in-firefox/ https://hacks.mozilla.org/2014/09/generational-garbage-colle... [1]: https://hacks.mozilla.org/2015/07/compacting-garbage-collection-in-spidermonkey/ https://hacks.mozilla.org/2015/07/compacting-garbage-collect...
    - mike_hearn 10y ago
current_call 10y ago
That doesn't mean I can't want predictable performance or deterministic destruction. You're assuming your compiler or operating system won't cause memory to be freed at different times. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up. Wasting man hours on manufactured problems is far worse than wasting coal.
- dikaiosune 10y ago
  Memory isn't the only resource managed by deterministic destruction. Manufactured problems? When what's now coastline is underwater, I'll be glad to see if you remain as smug.

pjmlp 10y ago

The C++ advantage will not be so much after Java 10 comes out and finally have the value types and reified generics the language should have had since beginning. Also I am yet to see any large scale production deployment of those Hadoop alternatives. But it might still be like 5 years from now, so who knows how it will evolve.

dikaiosune 10y ago
Re: deployments, I expect that would take some time for a transition to occur. The first post date on the ScyllaDB blog is from February 2015 (http://www.scylladb.com/2015/02/20/seastar/ http://www.scylladb.com/2015/02/20/seastar/), and it looks like it wasn't until September 2015 that they specifically started publishing benchmarks of the database itself as opposed to the network I/O library they built for it (http://www.scylladb.com/2015/09/22/watching_scylla_serve_1m/ http://www.scylladb.com/2015/09/22/watching_scylla_serve_1m/). I look forward to those changes coming to Java, and I think that stack-based value types could do a lot for the language. That said, the Scylla folks seem to have gotten a lot of their performance gains from CPU/thread affinity and async I/O (http://www.scylladb.com/2016/03/18/generalist-engineer-cassandra-performance/ http://www.scylladb.com/2016/03/18/generalist-engineer-cassa...). NIO is pretty great in Java-land, IIRC, but CPU/thread affinity is, I imagine, hard to pull off with a garbage collector. Another thing I'm curious about w.r.t. value types in Java -- hasn't C# had those for a while? If so, and if your claim that value types will provide large performance benefits is true, why isn't C# always blowing Java away in benchmarks? Perhaps it is and I'm just not seeing them. Perhaps Java's escape analysis is already pretty good and solve the 60/70/80% case? Perhaps I'm not well versed enough in the subject to understand the interactions here.
- pjmlp 10y ago
  Regarding C#, Microsoft hasn't invested too much on their JIT/AOT compilers optimization algorithms. NGEN was just good enough for allowing quick application startup. Also they didn't invest too much in optimizations in the old JIT. Specially since .NET always had good interop to native code via C++/CLI, P/Invoke and RCW. There were some improvements like multicore JIT in .NET 4.0 and PGO support in .NET 4.5, but not much in terms of optimization algorithms. Hence why .NET 4.6 got a new revamped JIT called RyuJIT with SIMD support and lots of nice optimizations. But this is only for the desktop. .NET for the Windows Store is AOT compiled with the same backend that Visual C++ uses. In the Windows 8 and 8.1 they came up with MDIL from Singularity/Midori but with 10 they improved the workflow to what is nowadays known as .NET Native. With the ongoing refactorings they plan to make C2 (Visual C++ backend) a kind of LLVM for their languages, similar to the Phoenix MSR project they did a few years ago. If you watch the Build 2015 and 2016 talks, most of them are making use of C# with the new WinRT (COM based) APIs, leaving C++ just for the DX related ones. So they are quite serious about taking their learnings from project Midori and improve the overall .NET performance.
bluejekyll 10y ago
Java 10? I'm still waiting for Jigsaw (originally slated for 1.8, is it coming in 1.9???)
- pjmlp 10y ago
  No need to wait. https://jdk9.java.net/download/ https://jdk9.java.net/download/
  - jerven 10y ago
    And Jigsaw has landed, build 116 if I recall (too lazy to look it up)
whateveracct 10y ago
> value types and reified generics I think you mean specialized generics (i.e. no autoboxing of primitives when used in generics)? Reified generics implies carrying around all generic type information at runtime, which will not be the case and also has nothing to do with performance. Non-value generics will still be erased I thought.
- pjmlp 10y ago
  Have you seen the status update? https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3ArzUY6rQAQTwI_jKvqJxrRrP_&index=3 https://www.youtube.com/watch?v=Tc9vs_HFHVo&list=PLX8CzqL3Ar... They will change the constant pool to have some kind of template information that gets specialized (what they call type species) into a specific set of types. The plan is even if Java cannot fully take advantage of all possibilities due to backwards compatibility with existing libraries in binary format, the JVM will support it for other languages not tied to Java semantics and backwards compatibility.

bluejekyll 10y ago

> That doesn't mean I can't want predictable performance or deterministic destruction. Exactly. To just add to your point, there is no longer a reason to settle for GC pauses with Rust. It does require more thought while writing the code, but what you gain is a firmly consistent runtime. If your memory allocation is slow, you can create your own allocator/slab, and then use that for hot memory space and optimize it out. As a longtime Java geek who never understood the argument against GC, this has been a mind altering experience. I was a big C++ person before, but after one too many memory leaks and segfaults, I could never imagine not wanting a GC. Then Rust came along and taught me better.

mike_hearn 10y ago
Two reasons: 1) Rust appears to be significantly less productive than a true GCd language. I see a lot of people talking about "fighting the borrow checker" with Rust and I see a lot of articles describing basic patterns that would be simple in any other language, but are complex in Rust. 2) If you want to invoke code that assumes a GC you need to have one. You can do manual memory allocation in Java by the way and a few high performance libraries do. It's just not common. It's interesting to note that the Chrome guys have gone in the direction of deploying a GC into C++ whereas the Mozilla guys have gone in the direction of moving manual memory management into the type system. I've got nothing against Rust but I'm a Chrome user, personally.
- dbaupp 10y ago
  Mozilla has also put significant effort into improving their C++ GC in Firefox, e.g. switching from a non-generational one to a generation GC[0] and then to a compacting one[1]. Just like Google can both improve Chrome and work on Go, Mozilla both improves Firefox and works on Rust. [0]: https://hacks.mozilla.org/2014/09/generational-garbage-collection-in-firefox/ https://hacks.mozilla.org/2014/09/generational-garbage-colle... [1]: https://hacks.mozilla.org/2015/07/compacting-garbage-collection-in-spidermonkey/ https://hacks.mozilla.org/2015/07/compacting-garbage-collect...
  - mike_hearn 10y ago

current_call 10y ago

That doesn't mean I can't want predictable performance or deterministic destruction. You're assuming your compiler or operating system won't cause memory to be freed at different times. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up. Wasting man hours on manufactured problems is far worse than wasting coal.

dikaiosune 10y ago
Memory isn't the only resource managed by deterministic destruction. Manufactured problems? When what's now coastline is underwater, I'll be glad to see if you remain as smug.