5 ms·

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard t

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard to hire good C++ devs, and they are typically not cheap. I manage a c++ team btw. Our app has to be fast.

pdimitar 7y ago
As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).
- amiga_500 7y ago
  The bespoke libraries etc have god knows how many man hours invested, it would be possible but gargantuan.
- otabdeveloper2 7y ago
  > C++ has a standard that's too long and hard to understand, so let's use a language without any standard whatsoever instead! Good lord, if that's the kind of human capital that's involved in making next-generation languages, then I have no doubt what will still be used to write serious software in 2080. (Hint: not Rust.)
  - pdimitar 7y ago
    You'd be more helpful if you specified what else would you deem appropriate -- as opposed to resorting to snarky sarcasm that brings nothing interesting to the discussion except supposedly degrade people whose tech choices you disagree with.
    - otabdeveloper2 7y ago
      The phrase 'undefined behavior' only makes sense in the context of an ISO standard. For any particular combination of compiler, OS and computer architecture there are no 'undefined behaviors'; you only care about the concept if you want portability to a different compiler/OS/architecture. So the idea that C++ sucks because of 'undefined behavior', so let's use some random language without an ISO standard or any portability guarantees at all is completely and utterly insane.
- pjmlp 7y ago
  Our alternatives are Java and .NET languages, with native bindings to C++ libraries. C++ alternatives still need to grow up to this kind of mixed language development, where I can have .NET code with C++ libraries and easily debug across them on the same Visual Studio session. Same applies to Java and C++ development experience.
  - pdimitar 7y ago
    Not sure how fair to newcomers (as in languages) this requirement is. F.ex. when coding in Erlang/Elixir I can use an excellent bridging library between their VM and Rust. There's also an excellent support for working with C libraries. Not sure what else can be expected. Maybe I am not reading you correctly and I apologise if so. It just kind of sounded like "the newer languages must be compatible with 20+ different ABI standards if they want us the older programmers working in C/C++ to adopt them"? Back on the original topic, I completely understand if a project has too much baggage and sunk cost so as to make even a partial migration (and hardening via using memory-safe languages and/or professional paid code analysis tools) unrealistic.
    - pjmlp 7y ago
      Naturally it isn't fair, but one cannot expect teams to drop velocity and diminish their productivity only on basis of adopting a new language that doesn't support existing workflows, IDE tooling and libraries. It is like telling someone to delivering games in Unity and Unreal that they should use Amethyst instead, without understanding what it means to actually having a team working in those ecosystems. Naturally Rust will get there, however it took C++ 30 years to be where it is today, and that is what any replacement attempt should take into consideration.
      - pdimitar 7y ago
        This is probably a much larger and not very relevant to the topic here discussion but I feel a lot of the newer breed of languages don't emphasise IDE tooling very much (not in the sense of Visual Studio / Eclipse and the like at least; VS Code gets a lot of attention though). So I fear if that's an expectation from a certain group of devs that this might already be a generational difference that's impossible to overcome. That being said, I agree -- existing teams can't be expected to just run away to the new thing, that much is true.
saagarjha 7y ago
What are you comparing it to? I think C++ tooling is fairly decent. (By the way, what do you work on?)
- amiga_500 7y ago
  I think java has very good tooling. Java's main issue is the barrier to entry is lower because it has good tooling, which means really bad, inexperienced programmers can write bad code, and have more tooling to bail them out, allowing them to continue down that path until they have a huge ball of mud. There ought to be some kind of phrase for this "the tooling curse". GDB isn't bad, IMHO, but the inability of IDEs to deterministically parse templates / index code without huge problems is problematic.
  - saagarjha 7y ago
    > the inability of IDEs to deterministically parse templates / index code without huge problems is problematic. More like the inability of text editors to parse templates; most IDEs rely on a full compiler backend that can usually figure things out.
    - amiga_500 7y ago
      But it shouldn't require a full compilation. The ultimate result, given the slow compile times of c++, is that you cannot know in your editor if your code is correct.
      - saagarjha 7y ago
        The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.
        still_grokking 7y ago
        Maybe you want to share which IDEs you've been using? It sounds like a wonder if there is one that can handle C++ in a way comparable to, say, IntelliJ for Java, or VSCode for TypeScript. My experience is frankly more that the usual IDEs I know of can't even handle syntax coloring 100% correct when it comes to C++…
edwintorok 7y ago
Wouldn't something like Rust meet your performance concerns?
- amiga_500 7y ago
  The sunk cost is huge. My main point was: if you don't have to do it in c++, for the love of god do it in something like java. Yes java is not heaven on earth, but still...

pdimitar 7y ago

As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

amiga_500 7y ago
The bespoke libraries etc have god knows how many man hours invested, it would be possible but gargantuan.
otabdeveloper2 7y ago
> C++ has a standard that's too long and hard to understand, so let's use a language without any standard whatsoever instead! Good lord, if that's the kind of human capital that's involved in making next-generation languages, then I have no doubt what will still be used to write serious software in 2080. (Hint: not Rust.)
- pdimitar 7y ago
  You'd be more helpful if you specified what else would you deem appropriate -- as opposed to resorting to snarky sarcasm that brings nothing interesting to the discussion except supposedly degrade people whose tech choices you disagree with.
  - otabdeveloper2 7y ago
    The phrase 'undefined behavior' only makes sense in the context of an ISO standard. For any particular combination of compiler, OS and computer architecture there are no 'undefined behaviors'; you only care about the concept if you want portability to a different compiler/OS/architecture. So the idea that C++ sucks because of 'undefined behavior', so let's use some random language without an ISO standard or any portability guarantees at all is completely and utterly insane.
pjmlp 7y ago
Our alternatives are Java and .NET languages, with native bindings to C++ libraries. C++ alternatives still need to grow up to this kind of mixed language development, where I can have .NET code with C++ libraries and easily debug across them on the same Visual Studio session. Same applies to Java and C++ development experience.
- pdimitar 7y ago
  Not sure how fair to newcomers (as in languages) this requirement is. F.ex. when coding in Erlang/Elixir I can use an excellent bridging library between their VM and Rust. There's also an excellent support for working with C libraries. Not sure what else can be expected. Maybe I am not reading you correctly and I apologise if so. It just kind of sounded like "the newer languages must be compatible with 20+ different ABI standards if they want us the older programmers working in C/C++ to adopt them"? Back on the original topic, I completely understand if a project has too much baggage and sunk cost so as to make even a partial migration (and hardening via using memory-safe languages and/or professional paid code analysis tools) unrealistic.
  - pjmlp 7y ago
    Naturally it isn't fair, but one cannot expect teams to drop velocity and diminish their productivity only on basis of adopting a new language that doesn't support existing workflows, IDE tooling and libraries. It is like telling someone to delivering games in Unity and Unreal that they should use Amethyst instead, without understanding what it means to actually having a team working in those ecosystems. Naturally Rust will get there, however it took C++ 30 years to be where it is today, and that is what any replacement attempt should take into consideration.
    - pdimitar 7y ago
      This is probably a much larger and not very relevant to the topic here discussion but I feel a lot of the newer breed of languages don't emphasise IDE tooling very much (not in the sense of Visual Studio / Eclipse and the like at least; VS Code gets a lot of attention though). So I fear if that's an expectation from a certain group of devs that this might already be a generational difference that's impossible to overcome. That being said, I agree -- existing teams can't be expected to just run away to the new thing, that much is true.

saagarjha 7y ago

What are you comparing it to? I think C++ tooling is fairly decent. (By the way, what do you work on?)

amiga_500 7y ago
I think java has very good tooling. Java's main issue is the barrier to entry is lower because it has good tooling, which means really bad, inexperienced programmers can write bad code, and have more tooling to bail them out, allowing them to continue down that path until they have a huge ball of mud. There ought to be some kind of phrase for this "the tooling curse". GDB isn't bad, IMHO, but the inability of IDEs to deterministically parse templates / index code without huge problems is problematic.
- saagarjha 7y ago
  > the inability of IDEs to deterministically parse templates / index code without huge problems is problematic. More like the inability of text editors to parse templates; most IDEs rely on a full compiler backend that can usually figure things out.
  - amiga_500 7y ago
    But it shouldn't require a full compilation. The ultimate result, given the slow compile times of c++, is that you cannot know in your editor if your code is correct.
    - saagarjha 7y ago
      The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.
      - still_grokking 7y ago
        Maybe you want to share which IDEs you've been using? It sounds like a wonder if there is one that can handle C++ in a way comparable to, say, IntelliJ for Java, or VSCode for TypeScript. My experience is frankly more that the usual IDEs I know of can't even handle syntax coloring 100% correct when it comes to C++…

edwintorok 7y ago

Wouldn't something like Rust meet your performance concerns?

amiga_500 7y ago
The sunk cost is huge. My main point was: if you don't have to do it in c++, for the love of god do it in something like java. Yes java is not heaven on earth, but still...