4 ms·

We've been discussing the "10% slowdown" for two decades now, since at least the time of Java's first release. Microsoft even tried to rewrite Windows in C# on

• bitwize 6y ago
  Yes, because GC is a woefully inefficient memory management strategy. Rust is not just the future of systems programming -- it's the future of all programming. You may not program directly in Rust the language, but borrow-checked static memory management is coming to an application language near you.
  • pjmlp 6y ago
    What is inefficient are programmers that don't learn to use the features for value types and deterministic memory management that many GC languages offer them.
  • pulse7 6y ago
    It is faster to write an app with GC than to fight the borrow checker. For OS kernel development Rust may be worth the fight, but for userland a language with GC is better in most cases (much easier to learn, use and maintain for relatively small speed and memory penalty).
• ogogmad 6y ago
  > Meanwhile in 2020 Java programs still suck ass to use Isn't that due to memory usage, rather than speed?
  • otabdeveloper4 6y ago
    I agree with the poster below. GC's problem isn't speed, per se; the problem is that GC only works effectively if you assume infinite memory and cache. Once you start approaching memory limits you start feeling pain.
    • pjmlp 6y ago
      Another problem is that most developers using GC languages seem to keep failing at learning that there are other means to manage memory in GC languages, but writing new is so easy...
      • creata 6y ago
        What other means are you referring to here? Arenas are all that comes to mind.
        • pjmlp 6y ago
          Many GC enabled languages offer: - value types - some form of RAII - untraced reference (aka raw pointers) - stack and global memory segment allocation Examples of such languages: Mesa/Cedar, Active Oberon, Mesa/Cedar, Component Pascal, D, Modula-3, Nim, Swift, C# (depends on the version, C# 9 is already quite sweet)
          • otabdeveloper4 6y ago
            All those are just ways to avoid actually using the GC. Which proves the point: GC is ineffective and works best when not used at all. The future is not garbage collected.
            • ogogmad 6y ago
              pjmlp's point is that GC can be the default, and manual memory management can be used where necessary. It's essentially the Pareto principle. Most of your garbage is generated by a minority of your program. So only small bits of your program need to be optimised to not use the GC.
            • deleted 6y ago
              [deleted]
            • pjmlp 6y ago
              Yes that is what anti-GC crowd tends to sell, except that it the same set of capabilities that languages like C also offer, with the difference that use after free and leaks abound. The future is pretty much GC with affine types, even Rust has to deal with crude RC<RefCell<>>, without the corresponding tracing GC performance, when doing GUI applications.
  • deleted 6y ago
    [deleted]
• pjmlp 6y ago
  Yet another one that doesn't understand GCs. And you are mistaken with "Going Native fever from MS", it was a flop that produced UWP, now being fixed with Project Reunion. Most of the System C# features from Midori ended up in C# 7.x, 8.0 and 9.0 brings even more goodies like naked function pointers and C ABI to call into .NET code.
• higerordermap 6y ago
  Yeah java is the gold standard of GC language design. It sucks so all GC languages must be horrible.
  • rurban 6y ago
    Excuse me, Java is a horrible design. The gold standard is Common Lisp, and this is wonderful. Also Go's GC still is terribly naive. They recently fixed the latency problem, but it still needs to be redesigned to match a good Common Lisp GC.
    • AnimalMuppet 6y ago
      I suspect that higherordermap's comment was sarcasm...