Thank you.
Semicolons make parsing easier and, removing them is backwards-compatible, so I decided to add them for ease of parsing and might remove them in the future.
This will never going to happen for obvious reasons; if it ain't broken, don't fix it!
Create interoperability with other languages, like what Swift is currently attempting to do, yes; but to completely rewrite an entire project that consists of millions of lines, I don't think so.
All the code rewrites from the last several decades would like a word in return.
A bunch of those rewrites managed to miss critical things that were encoded in the existing logic in non-obvious ways. They broke a bunch of workflows that way.
A bunch of others went wildly over-budget and wound up getting shut down before they produced anything usable.
But surely the documentation will tell you all the use cases, and the expected inputs and outputs, right? Right? Oh, you don't have documentation like that? Yeah, then it's used in ways you don't know about, and your rewrite is likely to break them. (And that's true even if you do have such documentation, because it's incomplete.)
Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
"But this time we're going to use Rust!" Yeah, but the thing that makes rewrites so hard was never the language, so using Rust isn't going to actually fix it.
> Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
This is a major reason why so many financial/healthcare/insurance/government institutions still runs COBOL software on mainframes. Many times, you're looking at what is essentially a monolith (in many parts, but everything is connected in some way) that was 50+ years in the making.
Rewriting it is a huge and extremely expensive task, and had it not been because COBOL is considered a "bad language" by the young people, and thereby causing problems with recruitment, i'm guesssing the mainframe would be around for 100+ years to come.
As it is now, these companies are forced to migrate away from COBOL, and most companies in the financial sector would probably go for Java, which is posed to becomming the new COBOL.
If you start a career today as a young COBOL programmer, you will most likely have a high salary (for your career) for your entire work life.
The mainframe is certainly on the way out, but it's a big beast to move, and most "estimates" i hear from financial institutions is that they plan to migrate away in 10-30 years, and predicting what happens in 30 years is kinda pointless. Suffice to say that the Mainframe and COBOL is probably here for another 30-50 years.
I agree with your take and want to add that "we want less CVEs" and "we want meaningful rewrites" are not necessarily at odds with each other. We can have both.
I'll also note that efforts like rewriting a lot of UNIX userland in Rust also introduces the benefits of rewrites -- you have to think super hard if you want that obscure command-line switch that only works in X way if another switch has another value or it does the thing Y if two other switches have these other values. I forgot the examples but that's what happened there: people figured "we will not implement command switches X and Y" and lo and behold, people using those tools never even noticed, myself included.
So, rewrites have positives as well. And not everyone doing rewrites is clueless.
I didn't say that those who do rewrites are clueless. I said that rewrites are really hard - far harder than most people expect.
That weird switch behavior? I almost guarantee that someone, somwhere, some when depended on that behavior. Either they no longer use the switch behavior or they no longer use the tool, or they just don't use the rewritten version. But how do you know that? In the best case, the code would have a comment: "This code is to simulate Berkeley 3 behavior for users porting from..." But even that doesn't tell you whether anybody today still depends on it.
I mean, it could be a valid strategy to not rewrite weird behaviors - any of them - and see what breaks, and then only add the ones that are still needed. The upside is a much cleaner rewrite, with fewer (and, hopefully, better documented) weird behaviors. The downside is that you have to break stuff temporarily to find out. (Hopefully you break it in live staging rather than in production...)
>Rewrites are hard. They're deceptively hard. They look like they should be easy, and they very much are not.
well yeah, when we switch to an industry that values poaching over retention, you're going to have way too many cases of landmines whose knowledge was held by an employee who left or got laid off 4+ years ago. That makes them much harder than they need to be.
A close 2nd is indeed that documentation is the least valued business item out there. Employees who want to "grow" (financially) are practically encouraged to simply keep moving instead of ensuring future knowledge is spread.
All code has a lifespan, either because it rots or it becomes irrelevant/unneeded. Existing C++ code will gradually expire and the most important pieces will indeed be rewritten, accelerated by shrinking expertise.
This may be technically true on a long enough timeline, but COBOL is still the backbone of the financial sector even though companies have dumped millions into attempting to convert it to something new with limited success.
For sure, we can debate the timeline, we can debate what language will replace C++. The way I read stefanos82's reply is that they don't believe C++ code will ever be rewritten, which is obviously not true.
COBOL running the financial sector is a myth in my opinion. There are still companies running aspects of their business on it, but calling it the 'backbone' is an overstatement. If you tallied up lines of code by language in the sector, I would wager COBOL makes up less than 1%.
Yep, I've worked for two companies where Fortran handles all of a major department's business - in both cases it was buried deep under layers of more modern stuff... but it was hugely risky to change it so it stayed.
While the argument is generally correct, Fortran and COBOL aren't in the same league. Fortran is still being upgraded and has some use cases that are hard to achieve in another language. I've seen the Rust subreddit recommending use of old Fortran code with Rust, rather than rewriting it in Rust. Unlike most other languages like C++ and Rust, Fortran kept its scope mostly limited to numerical processing - making it still one of the best solutions to code highly parallel numerical algorithms in.
Fortran isn't surviving just because nobody wants to rewrite Fortran code. Unless you're talking about Fortran77 code.
Oh agreed - Fortran is much more alive than COBOL - but in both cases I think the Fortran had outstayed its welcome. I never saw one of the codebases but the one I did see was Fortran 77 I believe, and there were a lot of gotos and labels.
I argue it's very broken. Business has simply made the decision to throw money at the symptoms rather than the cause. Maybe that is cheaper (I doubt it), but both approaches aren't going to be cheap, so what you gonna do?
Apple is a rare exception, even if their incentives are perverse.
Rewriting existing code in another language might be one thing LLMs can actually get good at. I wouldn't doubt if they could convert complex projects someday, without too much error or hassle.
"I used to think that the worst thing in life was to end up alone. It's not. The worst thing in life is to end up with people who make you feel alone." - Robin Williams
From a desktop app's point of view, I have tried liferea for a while and liked it a lot.
I'm not using anymore though, because the websites I used to follow went behind captcha mechanism(s) and cannot fetch their feed any longer which saddens me just by thinking about it.
If I did not need to work and was financially secured, I would dedicate my time to learn and master the craft of parsers, compiler design and implementation, and research new design patterns and algorithms for Garbage Collection.
My only question is: why the use of semicolons? Why not let the compiler add them implicitly for you?
This way, will look a lot cleaner, and closer to Golang's elegance.