Yeah, Java can run maybe half as fast as equivalently complex C, while being far more maintainable. But to see that kind of performance, you'll want to use POJOs (plain old Java objects), not that enterprise bullshit. And there are many other optimization techniques that your average Java coder wouldn't see in their average coding job.

All that to say it doesn’t matter what language they use anyway, because rewriting from scratch with a short timeline is an insane thing to do that never works.

Schdule-driven development by people with no domain knowledge, with poorly understood requirements and life-and-limb-critical outcomes, led by an unpredictable moron. What could go wrong?

Bring back lotus notes and the command line!

Well you need static types I assume, for code safety and all that.

I'm sure having a corrupt non-government narcissist rewrite the code for SS will be fine. It's not like he could leave any code hidden in there for his own purposes, like controlling or redirecting payments or anything.

Made by IBM. We chose one of the worst company to do it.

This is considered usable in 2025?

https://learnxinyminutes.com/cobol/

The code is already in production, there is no point in rewriting it. It can be maintained for decades to come. New features can be implemented in other languages and over time.

Do you have reason to think that? Organizations that use mainframes keep them up-to-date in my experience.

COBOL code, like any code, was written to embody certain business processes, and also to work around the quirks and blind spots of COBOL. And the people who understood those business processes are likely to be dead by now, and any documentation they wrote might be current and correct, or it might not. And very few people under the age of 60 have ever used COBOL in anger. So any legacy replacement project is going to have to encompass a big reverse-engineering effort, including analysis of a code base nobody is familiar with.

I'm old. A friend of mine is a fair bit older, getting into his late 70s. He knows COBOL but his main area of expertise is OS services, database tuning and assembler on old IBM and Fujitsu iron. Those are critical to keeping those old systems running well. He works half-time, is booked over a year out, and has a jaw-dropping daily rate. He also has a rider: one provision is that they have to tell him where he can smoke on-site, and if the answer is "nowhere," the deal is off. Also, he won't schedule any work that conficts with Burning Man, and he looks like a homeless guy. I brought him in on a consulting gig once. He did his bit, including an amazingly effective presentation to the C-levels (despite his profoundly non-executive appearance), and went his merry way. Saved us a fortune. You need people like that in order to have even a remote chance of success, and they're becoming exceedingly rare. Musk and his kiddies don't even know what they don't know.

I've worked on teams converting legacy code for most of my life. The planning for something like this would take longer than six months.

If this proceeds in Trump's corrupt government, Elon will get the contact, will claim it is too broken to salvage, and will privatize it. The only way this goes anywhere is if Trump and musk stand to gain money, and they stand to gain a lot.

Right after they write yet another content management system.

Well, the other thing about COBOL is that most people would regard it as a living death to have to deal with it as a day job.

And I've had interactions with offshore COBOL shops. The ones I worked with were not at all good. You'll never get 99th-percentile coders to work in that language, unless their only motivation is money.

"ROFL"

Signed, everyone who has been involved in migrating a codebase before.

Java can be fast at runtime, but optimization is most effective on frequently-run, repetitive sections of code.

The slow Java interpreter spin-up time was a big annoyance for use of Java in serverless cloud functions. Now the big cloud providers have ways to minimize that spin-up delay.

Just no man.

Yes, JavaScript has been the most popular language but it is exclusively because of the front-end. Many companies do not want to pay for separate back-end devs and ask their front-end devs to do it instead. These people (ab)use JS because they're most comfortable with it and are under crunch; so we end up with the abomination that is back-end JS.

It is NOT rivaling much lower-level languages; it can't even rival C#.

First off, it is interpreted. You are never going to be faster than competently written C, C++, Go, nor Rust. Secondly, the resources it takes to exist makes in a non-option for embedded machines - which Social-Security facilities are all but guaranteed to use.

Not to mention the horrendous (and insecure) package infrastructure, and under-powered core libraries - it would be the fullest extent disaster.

The saddest part? The larpers at DOG(shit)E are all but guaranteed to pick the worst tools for the job, over-engineer, and have extremely poor management. Meaning whatever they ship WILL collaspe the system day 1; and all of the people refusing to pay attention will be like "hOw CouLd THis HaPPen"

Anecdotally, Python is about three times as concise as Java. You have to write lots of boilerplate to do anything much more complex than Hello World in Java. And one of the oldest and most reproducible results in software engineering is that the defect rate is proportional to the number of lines of executable code. The more concise the language, the cheaper it is to maintain. This has been measured in hundreds of environments, with dozens of languages, over decades.

Python is slow, though, so there are some situations where it's not a good choice. But those cases are probably less numerous than you might assume. There have been a few occasions where I was told Python would be too slow, I've then built a proof-of-concept, and it was more than fast enough. People suck at knowing where bottlenecks are in complex systems.

And now that the Python project has finally bitten the bullet and taken measures to allow removal of the GIL, things might improve considerably, though Python's dynamic nature and some features of its type inference mean that some things it does will never be ultra-speedy.

In my shop, some of the managers were OK with teams using server-side node, with Mongo.

Those managers are now gone, and one of my jobs was to lifecycle that shit out. Just being near npm was enough to shorten my life by several years.

Mongo's actually a really nice choice for some use cases. It just wasn't good for what we were trying to use it for. Its replacement was Postgres, one DB for OLTP-like processing and another for OLAP. Works like a champ, and the improved analytics mean we've been able to tune the hell out of that sucker.

Yep, months is a joke, doubly so when talking about tens of millions of lines of code and also COBOL specifically.

This is going to be a hilarious disaster but not so hilarious when people who need the benefits need them and won't be able to get them.

I think his and Trump's roles are to be saboteurs.

Okay but have you ever tried just throwing genAI at the problem and not caring about the consequences?