34 ms·

I have been saying this for a more than a decade, but the number one thing that killed C++ as an attractive modern language is (the lack of) modules - the abili

I have been saying this for a more than a decade, but the number one thing that killed C++ as an attractive modern language is (the lack of) modules - the ability to include C++ code and libraries from others (perhaps with transitive dependencies), would allow an actual community of devs and companies spring up around the language. Instead we have greybeards and lone warriors, and million-line legacy codebases, half of which have their own idea on what a string or a thread is.

shortrounddev2 2y ago
Vcpkg has really improved the experience of linking 3rd party dependencies for me
fsloth 2y ago
” killed C++ as an attractive modern language” I’m not sure were you got this perception that it’s dead. C++ remains the only game in town in many domains. That said, _unless you work in those domains_ there is no good reason to use C++ IMHO. Apart from the legacy codebases, there’s lots of C++ greenfield development. ” the ability to include C++ code and libraries from others ” Libraries in vcpkg - a large number - are compatible enough to be used in this sense. It’s possible your specific domain is lacking contributions or you’ve been looking from the wrong places?
- ghosty141 2y ago
  > I’m not sure were you got this perception that it’s dead. > C++ remains the only game in town in many domains. Yeah but not because people like the language but because there is no alternative. At work almost every one of us devs doesn't enjoy working with C++ but since many dependencies in the embedded space are written in C++ you don't have much of a saying which language you choose. For example, Qt supports basically only C++. Rust is the only mature contender in that space currently.
- MichaelZuo 2y ago
  Yeah, a ‘module’ based system of various language is so much less efficient that it seems absurd to compare them for anything that actually requires that performance.
  - torginus 2y ago
    Honestly not sure what you mean by that - in C#, for example it doesn't matter to the compiler where the code comes from, it can be JITed/inlined just the same even if its coming from a different dll. I haven't seen any perf impact of splitting stuff between files/js modules in typescript either. What I'm guessing is that you mean that static compilers, like that of C++, need to be able to 'see' large amounts of code to make clever inlining optimizations. Which shouldn't be the case if the code is well designed, and/or the compiler can prove invariants necessary for optimization without having to look at the body of the code.
pjmlp 2y ago
Modules could be better, the problem are some greybeards and lone warriors (thankfully not all), that insist using C++ as it was plain old C. Basically, it is no different than renaming .js to .ts to take advantage of some stuff in Visual Studio Code, while keep writing plain old JavaScript.
- eej71 2y ago
  I think the struggle with modules has much more to do with the complexity of the problem at hand. I think the solution looks very easy should one be willing to dispense with large parts of the ecosystem. But if your goal is to keep the ecosystem together and not break the world (ala python 2/3 or perl5/6) and solve the problem at hand (waves vaguely at modules) - then its a really hard problem. I wish I could say modules don't work, but I have yet to understand them. Which is probably a big part of its problem.
  - imtringued 2y ago
    Stop using python 3 as an example. It is really tiring to hear about an extreme case of gross incompetence over and over again, while over in say the Grails/Spring ecosystem I don't even bother upgrading Grails 3 or 4 Plugins to Grails 6, because they still work as intended. When you upgrade a plugin from one version to the next, you're just swapping out build.gradle, gradle wrapper and a bunch of ancillary properties files. The build system changes, but everything else stays the same with only a tiny tiny minority of plugins being affected and even then the things that broke are absolute nonissues that can be fixed relatively quickly. It is kind of interesting how the python community hasn't learned a thing from python 2/3. The problem isn't breaking backwards compatiblity. Probably the biggest mistake you can do is act like breaking backwards compatiblity is a big deal, therefore you should pile up as many breaking changes as possible and release them all at once so as to maximize pushback and upgrade friction. It is in fact the exact opposite. If you break 10 libraries out of a million, you as the language developer can step in and upgrade them on behalf of the original maintainer. The users increment a library version when they increment the language version and done.
    - 2y ago

shortrounddev2 2y ago

Vcpkg has really improved the experience of linking 3rd party dependencies for me

fsloth 2y ago

” killed C++ as an attractive modern language” I’m not sure were you got this perception that it’s dead. C++ remains the only game in town in many domains. That said, _unless you work in those domains_ there is no good reason to use C++ IMHO. Apart from the legacy codebases, there’s lots of C++ greenfield development. ” the ability to include C++ code and libraries from others ” Libraries in vcpkg - a large number - are compatible enough to be used in this sense. It’s possible your specific domain is lacking contributions or you’ve been looking from the wrong places?

ghosty141 2y ago
> I’m not sure were you got this perception that it’s dead. > C++ remains the only game in town in many domains. Yeah but not because people like the language but because there is no alternative. At work almost every one of us devs doesn't enjoy working with C++ but since many dependencies in the embedded space are written in C++ you don't have much of a saying which language you choose. For example, Qt supports basically only C++. Rust is the only mature contender in that space currently.
MichaelZuo 2y ago
Yeah, a ‘module’ based system of various language is so much less efficient that it seems absurd to compare them for anything that actually requires that performance.
- torginus 2y ago
  Honestly not sure what you mean by that - in C#, for example it doesn't matter to the compiler where the code comes from, it can be JITed/inlined just the same even if its coming from a different dll. I haven't seen any perf impact of splitting stuff between files/js modules in typescript either. What I'm guessing is that you mean that static compilers, like that of C++, need to be able to 'see' large amounts of code to make clever inlining optimizations. Which shouldn't be the case if the code is well designed, and/or the compiler can prove invariants necessary for optimization without having to look at the body of the code.

pjmlp 2y ago

Modules could be better, the problem are some greybeards and lone warriors (thankfully not all), that insist using C++ as it was plain old C. Basically, it is no different than renaming .js to .ts to take advantage of some stuff in Visual Studio Code, while keep writing plain old JavaScript.

eej71 2y ago
I think the struggle with modules has much more to do with the complexity of the problem at hand. I think the solution looks very easy should one be willing to dispense with large parts of the ecosystem. But if your goal is to keep the ecosystem together and not break the world (ala python 2/3 or perl5/6) and solve the problem at hand (waves vaguely at modules) - then its a really hard problem. I wish I could say modules don't work, but I have yet to understand them. Which is probably a big part of its problem.
- imtringued 2y ago
  Stop using python 3 as an example. It is really tiring to hear about an extreme case of gross incompetence over and over again, while over in say the Grails/Spring ecosystem I don't even bother upgrading Grails 3 or 4 Plugins to Grails 6, because they still work as intended. When you upgrade a plugin from one version to the next, you're just swapping out build.gradle, gradle wrapper and a bunch of ancillary properties files. The build system changes, but everything else stays the same with only a tiny tiny minority of plugins being affected and even then the things that broke are absolute nonissues that can be fixed relatively quickly. It is kind of interesting how the python community hasn't learned a thing from python 2/3. The problem isn't breaking backwards compatiblity. Probably the biggest mistake you can do is act like breaking backwards compatiblity is a big deal, therefore you should pile up as many breaking changes as possible and release them all at once so as to maximize pushback and upgrade friction. It is in fact the exact opposite. If you break 10 libraries out of a million, you as the language developer can step in and upgrade them on behalf of the original maintainer. The users increment a library version when they increment the language version and done.
  - 2y ago