Hacker News Reader

Comment by littlestymaar | Hacker News Reader

The language itself doesn't have much importance, what matters is :

- is it portable ? Or will the users have to install a specific runtime to run the tool ? For Linux it's not a big deal because it comes pre-installed in most distributions, but making Python work on Windows requires some work. It's not too much if you're going to use the tool often, but for merely testing it, the runtime installation burden can deter users.

- is it fast ? For many application, speed doesn't matter, but for some it matters.

- is it stable ? Or will it crash every now and then ? C or C++ software have memory bugs, that leads to crashes (segfault). The most mainstream one don't have too much of it, but as soon as you start using niche software, you'll face crashes more often than not.

For these three reasons, the language matters, but there's not much difference if it's Rust, Go or Haskell.

View on HN

* Python is not all that difficult to package into an exe. C/C++ are very cross-platform.

* Python can be reasonably fast with pypy.

* Go and rust maybe don't have segfaults, but they can still crash and burn, or have other kinds of bugs.

Python is not hard to package into an exe, but most Python programs aren't packaged like that.

C and C++ are very cross-platform, if you only use cross-platform dependencies and if you are careful to write portable code. Most C and C++ applications don't do that.

Huh? What do you have to do to be careful? Just:

* Don't include windows.h

* Use a gui toolkit like gtk and qt (which you probably want to do anyway)

Generally, making a software windows-only is a deliberate choice, not something that happens 'by accident'.

Not really, most of the standard library and basic stuff is incompatible on Windows. So sockets, file system calls, event loops, file configuration & default folders... It's never THAT different but different enough that just compiling your code won't work.

> So sockets, file system calls, event loops, file configuration & default folders... It's never THAT different but different enough that just compiling your code won't work.

But if you use something like Qt you've got all of this cross-platform out of the box - I have a multiple hundred lines of code C++ software which does all this and much more ; it has almost zero platform-specific stuff except one function at some point to set real-time priorty to threads.

So you think it's appropriate for tools like ripgrep and xsv to bundle a gui toolkit to do its job?

I feel like this whole line of argument is disingenuous. In Rust, you don't need to bundle a GUI toolkit to get cross platform stuff that works. The standard library was built with Windows in mind, and it shows. You don't need any additional POSIX layer. You just use the standard library.

If you go and look at competitors to things like xsv and ripgrep that are written in C or C++, they either require some kind of POSIX thing on Windows to run correctly (like cygwin), or they jump through lots of hoops to behave as a native Windows application.

It really should not be a controversial statement to say that Rust has a better cross platform story (Windows/mac/Linux). It was a design goal.

> So you think it's appropriate for tools like ripgrep and xsv to bundle a gui toolkit to do its job?

Qt is not a GUI toolkit, it's a general framework. If you only link to -lQtCore you won't have anything remotely related to GUI in your binary. For instance doxygen is built like this.

Why isn't this more common then? I've literally never seen this done in any of the C++ command line tools I've looked at.

https://github.com/search?l=QMake&q=%22CONFIG+%2B%3D+console...

common enough for me

Don’t you end up with licensing fees if you use QT in a commercial product? Seems like a downside to me.

LGPL isn't that hard to comply with for a desktop application, so no.

With LGPL, you can't statically link the library though. Which requires your user to install it manualy, unless you package your software with some kind of installer (which is not so common on windows for cli executables).

> With LGPL, you can't statically link the library though.

no, that's tiresomely false. You can link proprietary code statically with LGPL code. LGPL does not give a shit about static or dynamic libraries because LGPL is not a language-specific license.

Right from the source: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

Thanks for the link. The nuance I was missing is that you can distribute statically-linked LGPL library as long as you provide a way for your user to override the chosen library with his own version of the library.

It's very common to ship windows CLI tools as a .zip file with an exe and a bunch of .dlls, that's not exactly burdensome to install compared to only an executable.

Not at all. You have to respect the license of Qt (e.g. if your customer asks you for the source of the Qt libraries you have to provide them - including any modification you made to them), but you can keep your own app proprietary and ship the whole however you like.

QT seems interesting.

For those like me who’ve never used QT: As long as you don’t statically link the QT libraries you don’t have to open source your entire commercial application. I’m not a lawyer.

General notes about licensing https://www1.qt.io/licensing/

Comparison of licenses https://www1.qt.io/licensing-comparison/

> As long as you don’t statically link the QT libraries you don’t have to open source your entire commercial application

I provided a link from the FSF that shows that this is not the case just below - you can statically link proprietary apps with LGPL qt.

“(1) If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.”

So for LGPL. As a commercial application developer I’m not sure I’d want to do that. I’d then have to field support requests for that object file.

Still, good to know.

Mingw?

It’s not THAT hard to make a cli C program portable between windows, Mac and Linux. I’ve done plenty of projects that support all three platforms and the amount of work wasn’t excessive. For some projects it was just getting the build environment up that was the biggest issue. Once you use cmake, modular design etc a lot of the issues vanish.

I never said it's complicated, I find it pretty simple, it's just not going to work by default straight away.

It's not difficult to package, but if your experience is anything like mine, distributing a 400+MB zip containing all the dependencies and the python core+stdlib is no fun.

I don't want reasonably fast, I want the 4 billion Hertz to rattle my teeth.

> Python can be reasonably fast with pypy.

Until it can't and then you are stuck with reimplementing the hot path in a language that can.

Reply on news.ycombinator.com