[OkayPhysicist]

In my experience, a language switch rewrite can be a benefit only when switching from a dead ecosystem to a living one.

For example, migrating a web app from a language that predates Unicode to something that won't require a bunch of scaffolding around every user input sometimes is worth it. Moving from LABVIEW to a real programming language that integrated with remotely modern development tooling was worth it. Switching from C++ to Rust? Probably not.

[imtringued]

Your final example feels wrong. Rust provides features that are basically unmatched by the fast majority of C++ and Rust competitors. I've also been soured enough on C++ to the point where rewriting an entire ecosystem in Rust seems like less effort than to figure out how to make the decrepit C++ one work for my purposes. You spend weeks trying to install a C++ library only to realize that it is not fit for purpose and then you spend another week on the next one, until you've tried most of them and realized they are all kind of bad in one way or another. Even if they worked as advertised, you're already going far beyond the intended use cases of the existing libraries so why limit yourself by the past?

[OkayPhysicist]

Don't get me wrong: Starting a new project, I'd choose Rust hands-down. But rewriting a massive project is a massive investment, and unless there is something extremely deficient in the language you're currently using, that there isn't sufficient tooling to work around, it's probably not worth it.

[pjmlp]

Sure, if we forget about the ecosystem in industry standards, IDE tooling, libraries, and training costs in existing industries where C++ is the standard.

Comparing language grammars on their own isn't enough any longer.

[cozzyd]

what C++ libraries take weeks to install? It's true that C++ compile times are atrocious but even that is over the top :).

[tcfhgj]

> Switching from C++ to Rust? Probably not.

Counter example:

https://fishshell.com/blog/rustport/

[bri3d]

FWIW, this was an intelligent rewrite, piece by piece. This is the only way I have ever seen "rewrite it in X" ever work. Fish also isn't a commercial product, so the calculus is a little different.

[bmitc]

> Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not.

Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs.

> remotely modern development tooling

I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern. Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.

[bri3d]

> Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.

Do you have examples of working version control for non-text programs, including the ability to combine work from two parallel workstreams (aka, merge)? I worked for a long time at probably one of the largest companies using non-text based programming and version control was never even close to solved, and my subsequent forays into the literature when I worked in the "no code workflow" space still came up empty handed for working solutions here. We always fell back to "try to represent the structure of the change in some text-based way."

[OkayPhysicist]

Spoken like someone who's never worked on a large-scale LABVIEW system. A moderately sized codebase (equivalent to a project with a million-odd lines of code) ends up with a project containing tens if not hundreds of thousands of files. Each file opens up two windows, so if you're working on anything nontrivial you're going to have dozens and dozens of windows open at a time. Compiling such a project takes upwards of an hour, and you can't rely on the interpreter environment because it has observably different behavior than the resulting builds (oh, and the compilation process happens in the same process as the IDE, so that's completely bricked during that hour or two).

No one ever names their wires, so there's no variable names anywhere. To see the name of a subvi (think function), you have to hover over it. Sure there's a little picture, but that just means instead of just merely naming my functions I have to draw a little picture. Don't even get me started on wire routing, which is a crucial, manual process for any vi of non-trivial complexity.

Then there's the fundamental engine bugs, which National Instruments' response to hearing about is approximately "get fucked". Like, for example, the GUI rendering breaking in subtle ways when Windows has an update queued. Imagine getting a bug report that consists of "We can't do feature X", and trying desperately to figure out if your code is wrong, or if your customer's just an idiot, only to discover that 0.1% of the buttons in your project just... don't exist sometimes.

Then there's version control, which is rudimentary at best. In order to compare two files, you need to load both files, which even with lazy loading takes what feels like an eternity. Merges? No automation whatsoever. Every merge is manual.

Extremely useful features (like metaprogramming, which is important because of just how miserable writing LABVIEW is) are locked behind shoving obscure keys into ini files like "ABANDONALLHOPEYEWHOENTERHERE=1" or "SuperSecretPrivateSpecialStuff=true" (That second one is real).

Don't get me wrong, LabVIEW has its place as a way to hack together a little control panel to talk to some instruments. But anyone suggesting adding a subvi should be shot, and the project should be rewritten in a real programming language.

[bmitc]

> Spoken like someone who's never worked on a large-scale LABVIEW system.

That's exactly false. I've single-handedly developed multi-thousand VI projects on different systems, including heavily using the OOP system and actor frameworks.