Cross-platform alternative to LabVIEW

[Andrey_Dmitriev]

---

@Intaris wrote:

---

wiebe@CARYA wrote:

---

---

That doesn't reflect from the website at all. I stopped looking as it sure looks like a commercial product.

---

Same here, was put off by the license costs of this one..... Almost makes LV look cheap in comparison. Pricing "Per App" or even "Per app, per year"

OTOH, even they include a "perpetual fallback" which enables the version of the year of purchase to still be functional even after a subscription expires. Just like the old Developer Suites.

---

No, Avalonia is free, licensed under MIT:

So, if you developing application using Avalonia "from the scratch", then its free regardless from the platform (optionally you can purchase paid support, if needed).

But if you have already WPF-based app, then you can "port" this to Mac using Avalonia XPF, and this is not free, Avlonia XPF is not open source. In general axaml used in Avalonia is close to WPF's xaml, but slightly different. "Avalonia is similar to WPF but not 100% compatible and will require work to port your application, and you can save this time using paid binary-compatible cross-platform version of WPF, named Avalonia XPF that utilises Avalonia. It allows you to run your WPF app on macOS, Linux, iOS, Android and Browser without modification as well as using existing WPF controls, such as those developed by Actipro, Telerik, Syncfusion, SciChart etc within Avalonia application — this is what costs money.

[Andrey_Dmitriev]

---

@lucian.grec wrote:

Thank you for your reply Andrey!
I don't care much about Open Source, actually I would prefer it having the backing of a larger player in one way or another, someone that can ensure a degree of stability and quality of the framework and provide support where needed.
What I meant by comparable to LabVIEW was more in terms of flexibility, UI capabilities and parallel programming(something like actors) not in terms of the language. At this early stage I'm open to any language. We've tried doing MVVM in LabVIEW but I think it mostly wasn't worth it at the end of the day due to the extra complexity.

---

In general Open Sources are very helpful in case of troubleshooting, just to understand how it works "under the hood". LabVIEW Run-Time is just "black box" and I have had in the past situations where it doesn't work as expected or crashed, and the only way to get rid of such situations is just "workarounds" or hard debugging sessions. On the other hand latest versions of LabVIEW are pretty stable, I have relative complex  apps, and everything working like a charm.

Another important point for migration from one platform to another are risks and costs. Great example — is LabVIEW NXG. That was a nice attempt to move from C++ to "modern" C#/WPF and obviously failed. Its a very hard if you have active app under continuous development, then porting such app to completely different platform could be a challenge. By the way the LabVIEW 2024 still compiled by old Visual Studio 2015 as far as I can see.

And one more point is comparison - "text-oriented" programming versus "graphical". In our large company  we have different departments, they using both C++ and C#, and in my area LabVIEW saves lot of development time, I can deliver same or better results much faster than colleagues (hard to say which is exact speedup ratio, it depends, may be in average 1:3 or so). Really love this. It just programming language, but this is absolutely different world, ahead of time.

[Jay14159265]

---

@lucian.grec wrote:

Given that macOS support ended with LabVIEW 2023 I am looking for alternatives that I could use to build complex cross-platform GUI applications on Mac and Windows.

We've been selling a feature-rich software in the audio industry, think something like TestStand and LabVIEW combined, and that has been developed and sold over the course of two decades, all thanks to this language that we all love, but we will lose the Mac business as soon as we won't be able to build G code on macOS.

The codebase is large and complex and moving to a potentially different language, framework will take years of work for my team so we might not even afford to do it, in which case we'd just have to settle for losing the Mac side of the business.

We're a team of developers that mainly develop in G and to some degree in Python and C++ so we'd need to train ourselves and hire new talent as well.
I was also wondering if there was a way and if it was advisable to gradually transition the codebase to a new technology and ship a product that's both G and this new stack for a while to soften a bit the blow.

Features we'd need are:
1. Interactive graphs since we do a lot of plotting both online and offline.

2. A consistent look and UI API across platforms.
3. We'd like to maintain only one project if possible.
4. Support for multiple windows like we have in G

5. All the UI elements that G has and more: Trees, MCLB, Buttons, Textboxes etc...

---

Here is some heavily biased opinion: 

I have been on the "Abandon Ship! Abandon Ship!" paradigm in regards to LabVIEW since 2021. What I can say after searching and testing is that there is not a direct replacement for LabVIEW but there are tools that are so much better than LabVIEW. Now is a great time to be a developer and/or software architect. 

If you want cross platform with maximum support for all platforms you cant go wrong with Python. I live in Python world now writing control systems across the big three platforms and it works great and is fun to develop with.  The Python cross platform support is as good or better than cross platform support from LabVIEW ever was. 

The three big issues with using Python over LabVIEW for commercial code is: 

1) If you use all the great libraries in Python, you typically cant sell your code 

2) Creating a UI in Python is not the same as creating a UI in LabVIEW, there is a learning curve (and hundreds of UI packages to use / learn / pay for (I'm looking at you QT ) 

3) There is no reasonable way to hide your IP

So is Python really a solution? Maybe for some things, certainly for automating lab testing and data analysis, but maybe not so much for commercial software. So what to do for that? Well there is a solution that covers all 5 of your requested features, and does not have the commercial limitations of Python. I have been using this toolkit for about 3 years now and once I got up the learning curve, I would only go back to LabVIEW for nostalgia. I really enjoy being able to make one application that runs everywhere and when I say everywhere, check this out: https://flutter.dev/

Unlike LabVIEW you can actually build great looking modern UIs, and like LabVIEW you get a nice GUI in which to build UIs https://flutterflow.io/

The backend programming language DART has a good Foreign Function Interface that allows you to use all your favorite APIs like NI-VISA. You have to level up your developer skills a bit but I never saw that as a negative. 

I have always used VERILOG to write FPGA code so I'm not missing anything LabVIEW had to offer there (especially the cost of NI hardware). In your description it didn't look like you care about FPGAs. 

If there was a continuum of developing automated testing system applications for me it would look something like this: 

<easy: LabVIEW, Python> ...................  < mid: Flutter > ................. < Hard: C++> 

<fast development: LabVIEW, Python> .......... < mid: Flutter > ...... <slower: C++>

<good UI: C++, Flutter> ................ <mid: > ........................ <meh UI: LabVIEW, Python >

<code exe speed: C++, Labview> ........... <mid: flutter> ............... < slow exe: python>

< many libraries: Python> ........ <some libraries: C++, Flutter> ........ <few libraries: LabVIEW>

There are some things that LabVIEW does great but is that worth sticking around? For me it's a no. 

Some other solutions I tried in this period: 

.NET (works of but I question if it has enough momentum to stick around for MAC and LINUX, see Microsoft ) 

C# ( I like C#,  Works but has the same issues as .NET, also Microsoft) 

Rust (just for fun, don't even bother, maybe in 10 years or so) 

</end imo> 

[Intaris]

---

@Andrey_Dmitriev wrote:

---

---

No, Avalonia is free, licensed under MIT:

So, if you developing application using Avalonia "from the scratch", then its free regardless from the platform (optionally you can purchase paid support, if needed).

---

I will admit the situation with the Avolonia licensing is a bit..... opaque.

Avalonia is free, and open-source, this much is clear. You say this is capable of being used in a cross-platform way? I understood from the licensing options that cross-platform was only available using "Avalonia XPF". What you're saying is that the "XPF" version simply adds compatibility (although not 100%) with EXISTING WPF apps? Yeah, not important for us personally. I can see how that would save huge amounts of cost though if it were required.

[Andrey_Dmitriev]

---

@Intaris wrote:

---

@Andrey_Dmitriev wrote:

---

---

No, Avalonia is free, licensed under MIT:

So, if you developing application using Avalonia "from the scratch", then its free regardless from the platform (optionally you can purchase paid support, if needed).

---

I will admit the situation with the Avolonia licensing is a bit..... opaque.

Avalonia is free, and open-source, this much is clear. You say this is capable of being used in a cross-platform way? I understood from the licensing options that cross-platform was only available using "Avalonia XPF". What you're saying is that the "XPF" version simply adds compatibility (although not 100%) with EXISTING WPF apps?

---

Yes, exactly, this related to existing WPF based app only. The cross-platforming is free. So, you can develop on Windows, then take your sources and compile under Linux or MacOS without any changes (the same as LabVIEW, in general) and visa versa.

Here is the video:

Explanation about XPF started from 22:00

Some additional links for you:

Questions about commercial use of Avalonia.

Building Cross-Platform Applications.

Can I cross-compile for different platforms?

[wiebe@CARYA]

---

@Andrey_Dmitriev wrote:

---

@Intaris wrote:

---

wiebe@CARYA wrote:

---

---

That doesn't reflect from the website at all. I stopped looking as it sure looks like a commercial product.

---

Same here, was put off by the license costs of this one..... Almost makes LV look cheap in comparison. Pricing "Per App" or even "Per app, per year"

OTOH, even they include a "perpetual fallback" which enables the version of the year of purchase to still be functional even after a subscription expires. Just like the old Developer Suites.

---

No, Avalonia is free, licensed under MIT:

So, if you developing application using Avalonia "from the scratch", then its free regardless from the platform (optionally you can purchase paid support, if needed).

But if you have already WPF-based app, then you can "port" this to Mac using Avalonia XPF, and this is not free, Avlonia XPF is not open source. In general axaml used in Avalonia is close to WPF's xaml, but slightly different. "Avalonia is similar to WPF but not 100% compatible and will require work to port your application, and you can save this time using paid binary-compatible cross-platform version of WPF, named Avalonia XPF that utilises Avalonia. It allows you to run your WPF app on macOS, Linux, iOS, Android and Browser without modification as well as using existing WPF controls, such as those developed by Actipro, Telerik, Syncfusion, SciChart etc within Avalonia application — this is what costs money.

---

For the record, I never doubted your statement. Just stated the website didn't reflect that.

Thanks for clearing that up.

[Andrey_Dmitriev]

This is how it works as very very basic "getting started" under Pop!_OS (which is Ubuntu 22.04 in general):

1) Install dotnet:

2) Install Avalonia:

3) Create new app:

4) Run it:

As source code editor you can use VSCode:

For example, I'll add Button and message text into axaml (if you familiar with WPF you will see — its quite similar):

and according handler into the code:

and now compile and run with dotnet run command:

I have no Mac in my hands, but should be the same.

Now this code also can be compiled in Windows as is:

That is.

[wiebe@CARYA]

Just some random remarks...

---

@Jay14159265 wrote:
The Python cross platform support is as good or better than cross platform support from LabVIEW ever was. 

---

I agree. LV was ahead of this 2 decades ago, and the rest got better, LV got worse.

@Jay14159265 wrote:
The Python cross platform support is as good or better than cross platform support from LabVIEW ever was. 

The three big issues with using Python over LabVIEW for commercial code is: 

1) If you use all the great libraries in Python, you typically cant sell your code 

2) Creating a UI in Python is not the same as creating a UI in LabVIEW, there is a learning curve (and hundreds of UI packages to use / learn / pay for (I'm looking at you QT ) 

3) There is no reasonable way to hide your IP

---

3), there's no way to hide IP in LV either. I suppose LV can create a dll or ppl, but so can Python (it seems). Code protection just isn't possible in any language. If a compiler can read it, so can a human. LV can discourage it, but it's not really protection.

My main beef with Python is things like the duck typing. This makes Python great for quick prototyping, but not so much for scalable applications. More importantly, I always found it hard to get to the good teaching material, and the good reusable code. There's so much garbage, it's really hard to get to the good stuff. I'd probably manage if I had to make the switch though.

@Jay14159265 wrote:

Unlike LabVIEW you can actually build great looking modern UIs, and like LabVIEW you get a nice GUI in which to build UIs https://flutterflow.io/

---

Google does seem to have it's own interpretation of 'open source'. If it's 'open source' like Android, it might as well be closed source (from the limited info I heard about it). But closed isn't bad per se.

[Jay14159265]

---

wiebe@CARYA wrote:

...

---

3), there's no way to hide IP in LV either. I suppose LV can create a dll or ppl, but so can Python (it seems). Code protection just isn't possible in any language. If a compiler can read it, so can a human. LV can discourage it, but it's not really protection.

---

I can see where that is true, at least with LV you can compile code so your users cant just load the source code in a text editor like in Python. There are some code obfuscation packages for python but they struggle with multiprocessing applications https://www.py2exe.org/

---

My main beef with Python is things like the duck typing. This makes Python great for quick prototyping, but not so much for scalable applications. More importantly, I always found it hard to get to the good teaching material, and the good reusable code. There's so much garbage, it's really hard to get to the good stuff. I'd probably manage if I had to make the switch though.

I think this is an interesting point, of all the software languages I have used LabVIEW is unique in that the discourse online is considerably weighted to engineers (electrical, mechanical, civil, etc ... not software ) solving engineering issues. So if you are an engineer, you fit right in around here. If you go to the Python developer boards 90% of discourse is on building servers, web stuff and super noob questions, engineering discussion can be hard to find. Let me tell you, setting up a Python server to interact with GPIB devices had no online discussion how one would do that, I just had to trail and error my way to success.