4 ms·

C++ isn't going away but its domain continues to contract. The C++11 standard will slow the erosion but I'm very doubtful that we'll see the "C++ renaissance" t

C++ isn't going away but its domain continues to contract. The C++11 standard will slow the erosion but I'm very doubtful that we'll see the "C++ renaissance" that people like Herb Sutter are predicting. Even now on low-powered devices like phones you can often get away with more wasteful languages like Java or even Javascript. And server-side there are a bunch of much higher-level languages that are close enough in performance and usually with a far richer ecosystem to boot.

pjmlp 15y ago
I used to think like that, but now I am back to languages with native code generation for the projects where I can dictate a language choice. Depending on the project requirements, this means C++, D, Go, Haskell or OCaml. Sadly from all options I listed above, C++ is still the best one supported in the industry. But coupled with a good static analyzer, it is quite nice. What we miss is the possibility to have native code generation support for higher level languages to become more widespread.
- akg 15y ago
  I'd be curious to know why you switched back to languages with native code generation? Is it mostly due to the control you have over code performance? Is so, are such applications fairly specific in scope, e.g., fluid-simulation on the GPU?
  - pjmlp 15y ago
    More control over performance and easiness of distribution. Desktop applications, where a good integration with the operating system is required. System programming and distributed systems as well. I lost a bit faith on VM based systems for deployment, due to too many deployments gone wrong. Now I advocate systems where you can get the best of both worlds. A VM based environment for development, and compile to native code when releasing the product. Something like Eiffel, ML and Lisp language families already offer. Java and .NET also have such options available, but they are not widespread.
  - soup10 15y ago
    Raw pointers, manual memory management, and "what you see is roughly what's executed in assembly" is very helpful for a wide variety of performance sensitive tasks, there is a whole world out there beyond CRUD apps. There are many trivial optimizations you can't do without writing native code. Writing any performance sensitive code in a high level language is like playing the telephone game. What's funny is that high-level languages develop a culture of not caring about performance, which makes what could be a mild problem, much much worse. Java is actually a pretty fast language(for most purposes), you wouldn't know it from 9 out of 10 desktop java applications I've used.
- cageface 15y ago
  I'm fond of native languages too and would like to believe that they're making a comeback but I really just don't see much evidence for this so far. I've dabbled in OCaml and Haskell but my current favorite is Go. I'm still looking for a good excuse to use it.

pjmlp 15y ago

I used to think like that, but now I am back to languages with native code generation for the projects where I can dictate a language choice. Depending on the project requirements, this means C++, D, Go, Haskell or OCaml. Sadly from all options I listed above, C++ is still the best one supported in the industry. But coupled with a good static analyzer, it is quite nice. What we miss is the possibility to have native code generation support for higher level languages to become more widespread.

akg 15y ago
I'd be curious to know why you switched back to languages with native code generation? Is it mostly due to the control you have over code performance? Is so, are such applications fairly specific in scope, e.g., fluid-simulation on the GPU?
- pjmlp 15y ago
  More control over performance and easiness of distribution. Desktop applications, where a good integration with the operating system is required. System programming and distributed systems as well. I lost a bit faith on VM based systems for deployment, due to too many deployments gone wrong. Now I advocate systems where you can get the best of both worlds. A VM based environment for development, and compile to native code when releasing the product. Something like Eiffel, ML and Lisp language families already offer. Java and .NET also have such options available, but they are not widespread.
- soup10 15y ago
  Raw pointers, manual memory management, and "what you see is roughly what's executed in assembly" is very helpful for a wide variety of performance sensitive tasks, there is a whole world out there beyond CRUD apps. There are many trivial optimizations you can't do without writing native code. Writing any performance sensitive code in a high level language is like playing the telephone game. What's funny is that high-level languages develop a culture of not caring about performance, which makes what could be a mild problem, much much worse. Java is actually a pretty fast language(for most purposes), you wouldn't know it from 9 out of 10 desktop java applications I've used.
cageface 15y ago
I'm fond of native languages too and would like to believe that they're making a comeback but I really just don't see much evidence for this so far. I've dabbled in OCaml and Haskell but my current favorite is Go. I'm still looking for a good excuse to use it.