4 ms·

"productivity of GC" is often offset by much harder management of resources other than memory due to lack of deterministic destruction. Also benchmarks show Sw

"productivity of GC" is often offset by much harder management of resources other than memory due to lack of deterministic destruction. Also benchmarks show Swift and C# are still about 2x-5x slower than Rust and C++, and that only if you're very careful and you write non-idiomatic code (e.g by avoiding heap allocations). When you're not, and you use OOP abstractions heavily, 10x worse is a much more likely outcome.

pjmlp 7y ago
That is only true if using a language that doesn't not offer mechanisms to have deterministic destruction, when required to do so. Winning the benchmarks game is meaningless, other than "I fell good" kind of thing. What matters is having the language features that allow to optimize the 1% of the code base, when it actually impact the acceptance criteria of project delivery. I have been replacing C++ systems with Java and .NET based solutions since 2006, it hardly matters that C++ wins in the micro-benchmarks. And if really needed, only that 1% gets packed into a C++ library with managed language bindings, turning C++ into our "unsafe" module.
- pkolaczk 7y ago
  My point is these languages you mentioned don't offer good tools to optimize that 1% and they make the other 99% an order of magnitude slower and more resource hungry to the point where it actually matters and annoys users. Also neither C# nor Java offers deterministic destruction. Try with resources is a joke, because it is limited to a lexical scope. Java and C# are not true alternatives to Rust or C++. They are inferior both on performance side and abstraction/productivity side, and severely inferior if you want both in the same fragment of code. In many applications there is also no single bottleneck and the split is not 1/99, nor even 20/80. After you optimize the most obvious bottlenecks you end up with a flat profile, where majority of time is taken by cache misses scattered across almost the whole codebase. It might not matter for some apps where performance is less critical, but in this case you probably don't want to use Java or C# when there exist languages offering much better abstractions (and surprisingly - Rust and C++ can be higher-level than Java or C#, leading to better abstractions, shorter code and higher productivity). Don't conflate EASY with PRODUCTIVE. Easy languages are not always more productive (if it was true everybody would be coding in Scratch).
  - pjmlp 7y ago
    C++ can be indeed higher level than Java, except that you are forgetting about the money spent fixing C related bugs, developer salaries, lack of tooling to plugin into a cluster and just monitor it like JFR, VisualVM, ETW, lack of interoperability between libraries due to conflicting requirements (RTTI, Exceptions, STL avoidance, ...) As for Rust, it remains to have something that matches Orleans, Akka, Kafka, .... Then there is the whole IDE tooling experience, libraries like the one here that require nightly toolchains, and lack of support for stagging binary libraries, which cargo might eventually get one day, but isn't here today. Java and C# might be inferior products from your point of view, but as mentioned, what I get are rewrites from C++ into Java and .NET languages, not the other way around. And I never sensed lack of productivity, quite the contrary, specially when I usually don't have to think about which C++ flavor of the month I am allowed to use, or having political discussions about enforcing the use of static analyzers on the CI/CD pipeline (assuming there is even one to start with).
    - pkolaczk 7y ago
      But now you're taking about tooling and not languages. Rust will eventually get there. IDE support is already very good and better than for many popular languages (e.g. dynamic ones). Performance profiling is also better than in Java. I'd take perf over visualvm any time. Java had much worse tooling when it was at the age of Rust today.
      - pjmlp 7y ago
        Languages are not used in isolation, the days that grammar and semantics were enough to warrant a language change. IDE support can be considered very good if the baseline is the 90's Borland and Microsoft IDE experience, not what modern Java and .NET are capable of, which starts to finally approach the Smalltalk and Common Lisp development experience of yore. Rust IDEs can't still offer completion that works all the time, let alone all the other IDE features. Perf is no match for Visual VM, as it is a Linux only tool, and it's usability is found lacking. It is so good that Google was forced to create their own graphical based tooling after years of Android developers complaints being forced to use it. Yeah, except not every business is willing to wait 25 years for Rust to achieve parity with today's Java ecosystem. Note that C++ is 40 something years old and still there are domains that it is fighting against C, which require a generational change before being open to try out anything else. Rust's has a big selling story for OS low level systems libraries, the niche C++ is heading to, with the caveat that C++ will as secure as Rust, that is where the language should focus. To be honest, had Go supported generics from day one, Nim or D some corporate backing, and I would have never considered Rust for hobby projects beyond the language geek thing of trying out new languages every year.

pjmlp 7y ago

That is only true if using a language that doesn't not offer mechanisms to have deterministic destruction, when required to do so. Winning the benchmarks game is meaningless, other than "I fell good" kind of thing. What matters is having the language features that allow to optimize the 1% of the code base, when it actually impact the acceptance criteria of project delivery. I have been replacing C++ systems with Java and .NET based solutions since 2006, it hardly matters that C++ wins in the micro-benchmarks. And if really needed, only that 1% gets packed into a C++ library with managed language bindings, turning C++ into our "unsafe" module.

pkolaczk 7y ago
My point is these languages you mentioned don't offer good tools to optimize that 1% and they make the other 99% an order of magnitude slower and more resource hungry to the point where it actually matters and annoys users. Also neither C# nor Java offers deterministic destruction. Try with resources is a joke, because it is limited to a lexical scope. Java and C# are not true alternatives to Rust or C++. They are inferior both on performance side and abstraction/productivity side, and severely inferior if you want both in the same fragment of code. In many applications there is also no single bottleneck and the split is not 1/99, nor even 20/80. After you optimize the most obvious bottlenecks you end up with a flat profile, where majority of time is taken by cache misses scattered across almost the whole codebase. It might not matter for some apps where performance is less critical, but in this case you probably don't want to use Java or C# when there exist languages offering much better abstractions (and surprisingly - Rust and C++ can be higher-level than Java or C#, leading to better abstractions, shorter code and higher productivity). Don't conflate EASY with PRODUCTIVE. Easy languages are not always more productive (if it was true everybody would be coding in Scratch).
- pjmlp 7y ago
  C++ can be indeed higher level than Java, except that you are forgetting about the money spent fixing C related bugs, developer salaries, lack of tooling to plugin into a cluster and just monitor it like JFR, VisualVM, ETW, lack of interoperability between libraries due to conflicting requirements (RTTI, Exceptions, STL avoidance, ...) As for Rust, it remains to have something that matches Orleans, Akka, Kafka, .... Then there is the whole IDE tooling experience, libraries like the one here that require nightly toolchains, and lack of support for stagging binary libraries, which cargo might eventually get one day, but isn't here today. Java and C# might be inferior products from your point of view, but as mentioned, what I get are rewrites from C++ into Java and .NET languages, not the other way around. And I never sensed lack of productivity, quite the contrary, specially when I usually don't have to think about which C++ flavor of the month I am allowed to use, or having political discussions about enforcing the use of static analyzers on the CI/CD pipeline (assuming there is even one to start with).
  - pkolaczk 7y ago
    But now you're taking about tooling and not languages. Rust will eventually get there. IDE support is already very good and better than for many popular languages (e.g. dynamic ones). Performance profiling is also better than in Java. I'd take perf over visualvm any time. Java had much worse tooling when it was at the age of Rust today.
    - pjmlp 7y ago
      Languages are not used in isolation, the days that grammar and semantics were enough to warrant a language change. IDE support can be considered very good if the baseline is the 90's Borland and Microsoft IDE experience, not what modern Java and .NET are capable of, which starts to finally approach the Smalltalk and Common Lisp development experience of yore. Rust IDEs can't still offer completion that works all the time, let alone all the other IDE features. Perf is no match for Visual VM, as it is a Linux only tool, and it's usability is found lacking. It is so good that Google was forced to create their own graphical based tooling after years of Android developers complaints being forced to use it. Yeah, except not every business is willing to wait 25 years for Rust to achieve parity with today's Java ecosystem. Note that C++ is 40 something years old and still there are domains that it is fighting against C, which require a generational change before being open to try out anything else. Rust's has a big selling story for OS low level systems libraries, the niche C++ is heading to, with the caveat that C++ will as secure as Rust, that is where the language should focus. To be honest, had Go supported generics from day one, Nim or D some corporate backing, and I would have never considered Rust for hobby projects beyond the language geek thing of trying out new languages every year.