4 ms·

That and, while "backwards compatability" has been quoted as important things in these languages. I can attest to rust having issues with what is "idiomatic" r

That and, while "backwards compatability" has been quoted as important things in these languages. I can attest to rust having issues with what is "idiomatic" rust: https://timidger.github.io/posts/i-cant-keep-up-with-idiomatic-rust/ https://timidger.github.io/posts/i-cant-keep-up-with-idiomat... there are other similar complaints around the net. While the C and C++ code I wrote over 2 decades ago is now finally "out of date" as of 5 years ago. It took a while. Not 2-3 years. Which is absolutely attributed to the language being new, not a design fault. C is already "settled"

im3w1l 6y ago
It seems idiomatic C++ is recently changing much faster than before, as C++ feels the need to keep pace with competing languages. But you don't have to keep up with what's idiomatic.
- guenthert 6y ago
  It can cause friction though, if new programmers work on old code or new and seasoned programmers work on the same project. Of those who do like Common Lisp, many like it because the standard hasn't changed in nearly thirty years (while simultaneously offering features added to the C++ standard just very recently, e.g. a filesystem path abstraction).
jki275 6y ago
I'm learning Rust now, I don't have anything particularly against it other than the obvious, big static binaries and such, and maybe those will be fixed eventually. I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old. Will Rust and Go age that way? Maybe. Too soon to tell.
- rational_indian 6y ago
  >I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old. Not if you have used any third party libraries. Dependency management is a nightmare in these languages.
  - jki275 6y ago
    Not if the project is written well. Yes, dependency hell is a thing, but there are ways to deal with it and make good code. Autotools will straight up tell you version x.x.x of library y is required, and as long as that's available, the problem is solved. Dependency hell is a thing in other languages too -- try to compile a really old Java project sometime. I spend most of my time working deep in the internals of some things that are 10+ years old running even older versions of some highly (and often badly) modified linux kernels. The well written C/C++ projects definitely stand out.
  - pjmlp 6y ago
    Conan and vcpkg have pretty much settled that problem.

im3w1l 6y ago

It seems idiomatic C++ is recently changing much faster than before, as C++ feels the need to keep pace with competing languages. But you don't have to keep up with what's idiomatic.

guenthert 6y ago
It can cause friction though, if new programmers work on old code or new and seasoned programmers work on the same project. Of those who do like Common Lisp, many like it because the standard hasn't changed in nearly thirty years (while simultaneously offering features added to the C++ standard just very recently, e.g. a filesystem path abstraction).

jki275 6y ago

I'm learning Rust now, I don't have anything particularly against it other than the obvious, big static binaries and such, and maybe those will be fixed eventually. I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old. Will Rust and Go age that way? Maybe. Too soon to tell.

rational_indian 6y ago
>I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old. Not if you have used any third party libraries. Dependency management is a nightmare in these languages.
- jki275 6y ago
  Not if the project is written well. Yes, dependency hell is a thing, but there are ways to deal with it and make good code. Autotools will straight up tell you version x.x.x of library y is required, and as long as that's available, the problem is solved. Dependency hell is a thing in other languages too -- try to compile a really old Java project sometime. I spend most of my time working deep in the internals of some things that are 10+ years old running even older versions of some highly (and often badly) modified linux kernels. The well written C/C++ projects definitely stand out.
- pjmlp 6y ago
  Conan and vcpkg have pretty much settled that problem.