3 ms·

> we need to move on from it Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people ch

> we need to move on from it Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people choose to use them), not from the demand side (shame people into adopting Rust). I think there is a significant portion of developers that want to leave C++ for a better language, but for different reasons may not be satisfied with Rust or Go, so they just stay on C++.

guitarbill 3y ago
What's wrong with Python, Java, C#, etc? Conversely, while better at avoiding footguns than C, Zig doesn't provide quite the same memory safety - although to be fair, better is still worth it.
- jandrewrogers 3y ago
  Security is not the only dimension that matters, resource efficiency and scalability matter too. A big driver in the use of C++ is that it is more efficient than Python, Java, etc by an integer factor in real workloads. No one wants to increase data center sizes by 4x (or more) to run the same workload. Being that wasteful isn't environmentally friendly.
  - musicale 3y ago
    > No one wants to increase data center sizes by 4x (or more) to run the same workload 1000 C++ servers vs. 100,000 Python servers is a big reason to avoid Python.
- BaculumMeumEst 3y ago
  Some performance critical software cannot afford garbage collection.
  - pasc1878 3y ago
    Which is why Apple put GC in Objective C and then removed to and Swift does reference counting. To keep iPhone apps responsive, they saw problems with apps using GC.
    - pjmlp 3y ago
      Not at all. They removed tracing GC from Objective-C, because it was a failure when dealing with C semantics. Automating retain/release calls was a much easier and safer approach, hence plan B. In any case, reference counting is a GC algorithm.
      - musicale 3y ago
        I am certain that one of the reasons Swift uses reference counting is to achieve more predictable performance and to avoid the GC pauses that plague Java etc. Another may be that it simplifies the runtime for system code such as kernels and device drivers.
        astrange 3y ago
        It's not just that, reference counting is friendlier to non-uniform memory access, which is what you have on a system with swap and/or memory compression. In compacting GC, the compacting part can help here, but the GC part doesn't. But people do use GC on their phones, insofar as they like to use web browsers.
        pjmlp 3y ago
        Swift uses reference counting, because it interoperates with the Objective-C runtime, duh. .NET interop with COM is a good example of how mixing a tracing GC with a reference counted runtime requires an higher engineering budget that Swift team most likely wasn't willing to spend resources on. It has been proven multiple times that reference counting is slower and has performance issues when dealing with large graphs, and also stop-the-world issues when cascade deletions occur. If only pro-RC folks would bother to read CS papers and benchmarks.
    - frou_dh 3y ago
dureuill 3y ago
I really don't see what issues there are with rust that could be addressed by another language without compromise on the performance and memory safety axes. I can think of two reasons for people not moving: 1. inertia, aka "not going out of comfort zone to learn new things" ("learning" includes understanding why things are different, not merely knowing they are). This won't be addressed by another new language that people will also need to learn. 2. Existing codebases won't magically turn from C++ to Rust. Legacy is actually a good reason to still be using C++ today, but another language also won't address this, as the fundamental issue is you can't change the existing code to be safer without effort. In both cases, time and effort on the language best positioned to replace C++ (Rust) will alleviate these issues. In particular this effort could be spent to fully close the feature gap with C++ (specialization, more expressive consts, ...) and improving Rust/C++ interoperability. No need to "shame" people, but finding a way to replace C++ use by Rust use is how we will solve the problem.
- IshKebab 3y ago
  There are definitely other ways to solve memory safety than the Rust approach. Check out Koka, Project Verona, Hylo and Vale. All of those are currently at the research project stage, so Rust is really the only game in town to replace C++ at the moment.

guitarbill 3y ago

What's wrong with Python, Java, C#, etc? Conversely, while better at avoiding footguns than C, Zig doesn't provide quite the same memory safety - although to be fair, better is still worth it.

jandrewrogers 3y ago
Security is not the only dimension that matters, resource efficiency and scalability matter too. A big driver in the use of C++ is that it is more efficient than Python, Java, etc by an integer factor in real workloads. No one wants to increase data center sizes by 4x (or more) to run the same workload. Being that wasteful isn't environmentally friendly.
- musicale 3y ago
  > No one wants to increase data center sizes by 4x (or more) to run the same workload 1000 C++ servers vs. 100,000 Python servers is a big reason to avoid Python.
BaculumMeumEst 3y ago
Some performance critical software cannot afford garbage collection.
- pasc1878 3y ago
  Which is why Apple put GC in Objective C and then removed to and Swift does reference counting. To keep iPhone apps responsive, they saw problems with apps using GC.
  - pjmlp 3y ago
    Not at all. They removed tracing GC from Objective-C, because it was a failure when dealing with C semantics. Automating retain/release calls was a much easier and safer approach, hence plan B. In any case, reference counting is a GC algorithm.
    - musicale 3y ago
      I am certain that one of the reasons Swift uses reference counting is to achieve more predictable performance and to avoid the GC pauses that plague Java etc. Another may be that it simplifies the runtime for system code such as kernels and device drivers.
      - astrange 3y ago
        It's not just that, reference counting is friendlier to non-uniform memory access, which is what you have on a system with swap and/or memory compression. In compacting GC, the compacting part can help here, but the GC part doesn't. But people do use GC on their phones, insofar as they like to use web browsers.
      - pjmlp 3y ago
        Swift uses reference counting, because it interoperates with the Objective-C runtime, duh. .NET interop with COM is a good example of how mixing a tracing GC with a reference counted runtime requires an higher engineering budget that Swift team most likely wasn't willing to spend resources on. It has been proven multiple times that reference counting is slower and has performance issues when dealing with large graphs, and also stop-the-world issues when cascade deletions occur. If only pro-RC folks would bother to read CS papers and benchmarks.
  - frou_dh 3y ago

dureuill 3y ago

I really don't see what issues there are with rust that could be addressed by another language without compromise on the performance and memory safety axes. I can think of two reasons for people not moving: 1. inertia, aka "not going out of comfort zone to learn new things" ("learning" includes understanding why things are different, not merely knowing they are). This won't be addressed by another new language that people will also need to learn. 2. Existing codebases won't magically turn from C++ to Rust. Legacy is actually a good reason to still be using C++ today, but another language also won't address this, as the fundamental issue is you can't change the existing code to be safer without effort. In both cases, time and effort on the language best positioned to replace C++ (Rust) will alleviate these issues. In particular this effort could be spent to fully close the feature gap with C++ (specialization, more expressive consts, ...) and improving Rust/C++ interoperability. No need to "shame" people, but finding a way to replace C++ use by Rust use is how we will solve the problem.

IshKebab 3y ago
There are definitely other ways to solve memory safety than the Rust approach. Check out Koka, Project Verona, Hylo and Vale. All of those are currently at the research project stage, so Rust is really the only game in town to replace C++ at the moment.