If you want portability, use Python and Qt5. Qt5 not only provides an uniform look across all operating systems (not exactly "native", but uniform), but also has uniform interfaces to things like network, and serial and usb ports. A carefully written Python application can work as-is on most/all OSes.
Unfortunately, Python I/O is not very efficient. If the application works on a lot of data, Python will be slow(er). Also, you do not use Python if the source code is a trade secret. You can license it however you wish, but the end users will be able to read the source code.
Finally, the current official Python interpreter, CPython, only runs Python code in one thread per process. You can have multiple threads in the same process, and that is very useful for things like asynchronous I/O, but for heavy math, you need to use process parallelism to max out the performance.
If you need OS drivers, in Linux you do it in C. (While technically it is nowadays possible to write an userspace "driver", those are fragile things that to an end user like me, are just turds. I know many members here advocating doing that instead of trying to write a kernel driver, but in my experience, the userspace stuff just isn't worth the effort. The only exception is "drivers" that use an userspace-exported bus, like USB, Ethernet, Infiniband, or similar.)
If you deal with lots of data, and want a graphical user interface, then your choices are basically C or C++. There is only one pure C GUI toolkit, GTK+, that has been ported to all OSes, but it does not provide a "native" use ańd feel on Mac OS or Windows, and outside the POSIX/Unix/Linux world, GTK+ is not well known among programmers. With C++, you have a lot more options available, including Qt; but also things like FLTK, that allows you to do portable GUIs that do look and feel native on different OSes. Some OSes, like Windows, have much better C++ support for their OS and kernel-level interfaces.
If I was limited to a single programming language for whatever odd reasons, but still wanted to work on that project, the language I'd choose would depend on the particular requirements of said project, emphasizing the above points.
If I was to work on it alone, right now I'd probably go with C and GTK+, developing on Linux, just because in the last few years I've done a lot of POSIXyC, and not much C++, so it'd be less effort for myself personally.
If I was to work with other programmers, I think C++ (and Qt for the GUI) would be the best choice.
You see, even if limited to a single tool – and this really is similar to asking a builder which tool they would choose, if they had to build a house using just a single tool –, I would still pick the tool based on the problem at hand.
(For the house, it'd be a Finnish wood axe, because I could build (a horribly ugly, but livable) log cabin with that; for anything better, I'd need more tools.)