Great question. Because of its unique spot in computing history, COBOL takes a different approach as compared to other languages like the C or Lisp families, and we'd be here forever trying to figure out which differences are good or bad. So for now I will list a few benefits that COBOL may have for a project compared to other languages:

• COBOL is based on English, which means that while it may be a bit harder to write, it's a little bit easier to read, which may help bring developers up to speed as a project grows in size. For example, the keyword ADD only refers to adding numbers, so there's no ambiguity there
• COBOL programs are split into different divisions and sections, which means that the variables, functions, I/O, and other aspects are in predictable locations and just a ctrl+F away. Combined with the above point, this means that COBOL programs are less likely to become messy over time.
• COBOL natively supports the fixed-decimal format for numbers, which, unlike floating-point numbers, does not lose precision for very large and very small numbers. This is very useful in use cases where numbers must be very exact, like banking. Hence why the banking system still runs on COBOL.
• In my opinion, COBOL's message-passing model is superior to the thread-sharing model in terms of safety, which would otherwise require something like a borrow checker to stop race conditions and the like

I hope that answered your most pressing questions.

Hi, I'm Otterkit's lead developer, I'll add a few more reasons why you might want to choose COBOL.

COBOL takes a different and often unique approach to common problems that in my opinion is more efficient and elegant than most other approaches.

The way COBOL handles strings is in my opinion much more efficient than C#, Java or even Rust. In most newer languages strings are implemented as objects (C# and Java), which means that they'll later need to be garbage collected at some point, which then leads to nondeterministic memory usage and forces it to always be heap allocated. In Rust they are (usually) heap allocated structs, and you have to deal with the borrow checker and the complexity Rust brings to the overall project.

In COBOL, strings are built-in primitive types, not an object or struct at all. This brings a couple of nice compiler optimization opportunities:

• COBOL strings are not subject to, and do not need to be garbage collected. The compiler will handle its memory for you, this applies to both fixed and dynamic length strings.
• Being primitive types, the compiler is free to choose the most appropriate allocation strategy for a particular string, and in some cases (fixed length strings) can allocate it completely on the stack which leads to it being automatically freed after returning from a function or method.
• Dynamic lengths strings, where the length can change at runtime, are still available, and yes they are still a primitive type. The compiler will handle the allocations for you, and without involving the garbage collector. Because they are not subject to GC, the compiler is free to copy the contents into a new bigger buffer, update all references to it, and immediately free the older buffer.
• This means that COBOL strings can have deterministic memory usage, no waiting until the GC decides to run, and without the use and complexity of a borrow checker.

The way COBOL handles concurrency is much safer, more efficient, and in situations where you need both local and remote communication, much easier and painless to use. While other languages opted for multithreaded concurrency, where a single process runs on multiple threads, COBOL opted for multiprocess concurrency, where multiple processes run concurrently, sharing data through message passing. COBOL processes have a global per machine Message Control System process, which handles all the message routing between both local and remote processes.

• Because the language has this safer concurrency model built-in, you never have to worry about race conditions, locks, mutex, or other thread safety precautions and issues. Your messages are all handled by the MCS, this includes the sending, receiving and storing of the messages (if needed). User code never has to worry about thread safety.
• Otterkit's implementation uses Unix domain sockets for fast local message passing, and while you could argue that this might be slower, in practice the MCS will be sending messages between multiple processes concurrently without needing locks or a mutex everywhere on user code to ensure thread safety, which can be faster in the end.

A few other minor things that COBOL handles more efficiently or better than other languages:

• String formatting is amazingly simple, including any numeric formatting.
• Standard decimal arithmetic. Most languages either don't have it at all, or use a non-standard decimal representation. C# has its own weird format, Java uses a slow arbitrary precision implementation, and Rust doesn't have one at all.
• Multi-paradigm is handled better, you don't need a public static class and a GC (C#, Java) to write procedural code, if all you need are functions and don't need any objects at all, you can write COBOL in a purely procedural way. On the other hand, if what you need are classes and objects with a GC to safely handle memory for you, then you can write COBOL is an OO way without stressing over a borrow checker or manual memory allocation (Rust, C). You can mix the two in a single codebase, and the compiler is free to optimize purely procedural code to not require a GC at all.
• It has a boolean primitive type (and a literal for it) that is optimized for bit operations with a user-defined size, the type only accepts bit values (1s or 0s). In contrast with other languages where bit shifting and boolean operations have to be performed on fixed size integer types, which can lead to error prone code by accidentally using an integer or literal of incorrect size (0U vs 0UL vs 0ULL in C). This also makes it overall easier to process binary data directly.
• Declarative error handling. You don't need a try..catch, if err != nil or similar things everywhere in the middle of you code. You can define "declaratives" that run whenever an exception or error occurs, and as soon as it occurs your program will jump into the declarative for that particular error to handle it, and then if the program continues or not is defined by the user. You can easily use and import these into your source code without it becoming messy.