5 ms·

Let the language die, hope it goes quicker than cobol.

by e-dant 1y ago

gosub100 1y ago
COBOL is alive and well. Why would a company rewrite a codebase that has decades of error free functionality? What do they get?
- cheema33 1y ago
  > Why would a company rewrite a codebase that has decades of error free functionality? What do they get? All well and good if it is something you do not have to modify/maintain on a regular basis. But, if you do, then the ROI on replacing it might be high, depending on how much pain it is to keep maintaining it. We have an old web app written in asp.net web forms. It mostly works. But we have to maintain it and add functionality to it. And that is where the pain is. We've been doing it for a few years but the amount of pain it is to work on it is quite high. So we are slowly replacing it. One page at a time.
  - gosub100 1y ago
    the insurance companies running COBOL don't care. it's cheaper to pay a cowboy $X00,000/yr to keep the gravy dispenser running than trying to modify it. by definition, this is code that's been in use for decades. Why change it?
bdangubic 1y ago
“quicker than cobol” means it will die in the next 100 years (maybe) :)
jimbob45 1y ago
I suspect the committee agrees with you. I think they’ve anticipated a competitor coming to kill C++ for two decades now and see themselves as keeping C++ on life support for those who need it. It’s shameful that there’s no good successor to C++ outside of C# and Java (and those really aren’t successors). Carbon was the closest we came and Google seems to have preemptively dropped it.
- compiler-guy 1y ago
  Carbon is still quite active.
  - jimbob45 1y ago
    The addition of a safety design is a shift in our milestones for v0.1, and you can see the difference here. Both of these are fundamental parts of v0.1, and will take long enough that the earliest date for v0.1 is pushed out to the end of 2026 Look, no one is more excited than me for this, but this is reaching Star Citizen levels of delays.
- wffurr 1y ago
  The latest Carbon newsletter is here, from March: https://github.com/carbon-language/carbon-lang/discussions/5117 https://github.com/carbon-language/carbon-lang/discussions/5...
- jhasse 1y ago
  Carbon doesn't have exceptions which makes it DOA for some. I think Cpp2 / cppfront will become the successor language instead.
compiler-guy 1y ago
https://www.phoronix.com/news/GCC-15-Merges-COBOL https://www.phoronix.com/news/GCC-15-Merges-COBOL COBOL Language Frontend Merged For GCC 15 Compiler Written by Michael Larabel in GNU on 11 March 2025 at 06:22 AM EDT. 33 Comments
greesil 1y ago
I don't think it's going anywhere, too much existing code that's still useful. People STILL use Fortran 77 for goodness sake.
- lblume 1y ago
  Fortran may still be used but is considered functionally dead nonetheless. Nobody is hiring Fortran devs anymore (and those who do put themselves in a really hard market position). Yet, learning C++ might still be a more valuable skill than learning Rust.
  - kergonath 1y ago
    Fortran 77 is dead. Fortran is not, and yes, people still get hired to use it. Just maybe not in your field.
  - pjmlp 1y ago
    Yet, Fortran 2023 is the latest standard, and Fortran support is one of the reasons why CUDA won over OpenCL.
trealira 1y ago
C++ is not going anywhere. It's even still used in gamedev to make new games. It's used in HPC and scientific computing. Windows applications often use it. And so on.
jandrewrogers 1y ago
For better or worse, modern C++ is still the most capable and expressive systems language. To replace it, we need (at a minimum) a language with similar capability and expressiveness in the low-level systems domain. The options are really thin; Zig probably comes the closest but it is a bit austere coming from recent C++ versions. I think we can do significantly better than C++ as a systems language. We just haven’t landed on a language that really nails the design.
- johnnyjeans 1y ago
  > For better or worse, modern C++ is still the most capable and expressive systems language. Not really. Rust, ATS, D, and some implementations of Lisp and even Haskell if you slay the dragon of actually learning GHC. Modern C++ is honestly overrated in my opinion as an extensive user of the language with 300k lines in a modern dialect alone. It's a pain in the ass to step through in a visual debugger and core dumps may as well be useless no matter the platform. It's extremely grating to read and to write. Compilers have a tendency to crash like crazy if you get too cute. There's still no compile-time (or runtime) reflection. I would literally rather be writing proofs for a dependent type system than deal with heavy template metaprogramming.
  - jandrewrogers 1y ago
    C++20 metaprogramming is pretty clean and straightforward. It became usable around C++17, though the learning curve is a bit steep. I can’t remember the last time I saw a compiler crash, and I’ve used many compilers on code bases that use a lot of dark corners of C++. The occasional compiler bug is a thing though. I didn’t say C++ was amazing, just that recent dialects are better than the alternatives in practice, many of which I have also used for similar code. Rust is not a substitute for C++ unless your code isn’t all that low-level, it lives closer to the abstraction level of Java. There are a number of odd gaps in the Rust feature set for low-level systems programming (database kernels in my case), the rigid ownership/lifetime model doesn’t play nicely with fairly standard systems-y things like DMA, and the code is always runs slower for some inexplicable reason. I’d love something to replace C++ but to be a candidate it can’t be less expressive, slower, and so rigid that it is difficult to do some ordinary systems-y things. A nerfed programming language is not the answer to this question.
indigoabstract 1y ago
I think this saying applies here pretty well: Horses don't die when the dogs want them to.
pjmlp 1y ago
First someone needs to rewrite famous open source compiler development tools like GCC and LLVM into something else.

Let the language die, hope it goes quicker than cobol.

by e-dant 1y ago

Let the language die, hope it goes quicker than cobol.

COBOL is alive and well. Why would a company rewrite a codebase that has decades of error free functionality? What do they get?

cheema33 1y ago
> Why would a company rewrite a codebase that has decades of error free functionality? What do they get? All well and good if it is something you do not have to modify/maintain on a regular basis. But, if you do, then the ROI on replacing it might be high, depending on how much pain it is to keep maintaining it. We have an old web app written in asp.net web forms. It mostly works. But we have to maintain it and add functionality to it. And that is where the pain is. We've been doing it for a few years but the amount of pain it is to work on it is quite high. So we are slowly replacing it. One page at a time.
- gosub100 1y ago
  the insurance companies running COBOL don't care. it's cheaper to pay a cowboy $X00,000/yr to keep the gravy dispenser running than trying to modify it. by definition, this is code that's been in use for decades. Why change it?

bdangubic 1y ago

“quicker than cobol” means it will die in the next 100 years (maybe) :)

jimbob45 1y ago

I suspect the committee agrees with you. I think they’ve anticipated a competitor coming to kill C++ for two decades now and see themselves as keeping C++ on life support for those who need it. It’s shameful that there’s no good successor to C++ outside of C# and Java (and those really aren’t successors). Carbon was the closest we came and Google seems to have preemptively dropped it.

compiler-guy 1y ago
Carbon is still quite active.
- jimbob45 1y ago
  The addition of a safety design is a shift in our milestones for v0.1, and you can see the difference here. Both of these are fundamental parts of v0.1, and will take long enough that the earliest date for v0.1 is pushed out to the end of 2026 Look, no one is more excited than me for this, but this is reaching Star Citizen levels of delays.
wffurr 1y ago
The latest Carbon newsletter is here, from March: https://github.com/carbon-language/carbon-lang/discussions/5117 https://github.com/carbon-language/carbon-lang/discussions/5...
jhasse 1y ago
Carbon doesn't have exceptions which makes it DOA for some. I think Cpp2 / cppfront will become the successor language instead.

compiler-guy 1y ago

https://www.phoronix.com/news/GCC-15-Merges-COBOL https://www.phoronix.com/news/GCC-15-Merges-COBOL COBOL Language Frontend Merged For GCC 15 Compiler Written by Michael Larabel in GNU on 11 March 2025 at 06:22 AM EDT. 33 Comments

greesil 1y ago

I don't think it's going anywhere, too much existing code that's still useful. People STILL use Fortran 77 for goodness sake.

lblume 1y ago
Fortran may still be used but is considered functionally dead nonetheless. Nobody is hiring Fortran devs anymore (and those who do put themselves in a really hard market position). Yet, learning C++ might still be a more valuable skill than learning Rust.
- kergonath 1y ago
  Fortran 77 is dead. Fortran is not, and yes, people still get hired to use it. Just maybe not in your field.
- pjmlp 1y ago
  Yet, Fortran 2023 is the latest standard, and Fortran support is one of the reasons why CUDA won over OpenCL.

trealira 1y ago

C++ is not going anywhere. It's even still used in gamedev to make new games. It's used in HPC and scientific computing. Windows applications often use it. And so on.

jandrewrogers 1y ago

For better or worse, modern C++ is still the most capable and expressive systems language. To replace it, we need (at a minimum) a language with similar capability and expressiveness in the low-level systems domain. The options are really thin; Zig probably comes the closest but it is a bit austere coming from recent C++ versions. I think we can do significantly better than C++ as a systems language. We just haven’t landed on a language that really nails the design.

johnnyjeans 1y ago
> For better or worse, modern C++ is still the most capable and expressive systems language. Not really. Rust, ATS, D, and some implementations of Lisp and even Haskell if you slay the dragon of actually learning GHC. Modern C++ is honestly overrated in my opinion as an extensive user of the language with 300k lines in a modern dialect alone. It's a pain in the ass to step through in a visual debugger and core dumps may as well be useless no matter the platform. It's extremely grating to read and to write. Compilers have a tendency to crash like crazy if you get too cute. There's still no compile-time (or runtime) reflection. I would literally rather be writing proofs for a dependent type system than deal with heavy template metaprogramming.
- jandrewrogers 1y ago
  C++20 metaprogramming is pretty clean and straightforward. It became usable around C++17, though the learning curve is a bit steep. I can’t remember the last time I saw a compiler crash, and I’ve used many compilers on code bases that use a lot of dark corners of C++. The occasional compiler bug is a thing though. I didn’t say C++ was amazing, just that recent dialects are better than the alternatives in practice, many of which I have also used for similar code. Rust is not a substitute for C++ unless your code isn’t all that low-level, it lives closer to the abstraction level of Java. There are a number of odd gaps in the Rust feature set for low-level systems programming (database kernels in my case), the rigid ownership/lifetime model doesn’t play nicely with fairly standard systems-y things like DMA, and the code is always runs slower for some inexplicable reason. I’d love something to replace C++ but to be a candidate it can’t be less expressive, slower, and so rigid that it is difficult to do some ordinary systems-y things. A nerfed programming language is not the answer to this question.

indigoabstract 1y ago

I think this saying applies here pretty well: Horses don't die when the dogs want them to.

pjmlp 1y ago

First someone needs to rewrite famous open source compiler development tools like GCC and LLVM into something else.