busybox VS xgo

Well.

Maybe you have better luck with the Busybox diff: https://github.com/brgl/busybox/blob/master/editors/diff.c

You can use busybox devmem to debug. The source code gives you an idea of how it works to write your own code.

You can fairly easily spot things like recursive search tree implementations in the wild.

Also, compilers and interpreters often recursion, and that goes to as many levels as the program requires.

Have you heard of a "recursive descent parser"? GNU C++ uses one (a huge source file written in C++, well over a megabyte long). This will recurse as deeply as the program's nesting goes; C++ programs often go to more than three levels of nesting. (There are some non-recursive hacks mixed in there, like some operator precedence parsing involving an explicit stack: Shunting-Yard or similar?)

https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/parser....

Let's switch over to embedded. Have you heard of BusyBox? BusyBox provides scaled down system utilities for embedded systems. It is very widely used.

BusyBox's "libb" internal library contains a function called "recursive_action" for walking file system trees. This is actually recursive, and frequently goes more than three levels deep in actual use:

https://github.com/brgl/busybox/blob/master/libbb/recursive_...

This is used by BusyBox programs like mdev (udev replacement) lsusb, lspci, chmod, ...

Also, HN isn't a good place to exhibit Lisp condescension/ignorance.

This is almost the same implementation you see in busybox's id command source

I see, in this thread, talks about what Sciter does and does not offer.

It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.

I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)

On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.

The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.

I cross-compile the apps using xgo (https://github.com/karalabe/xgo)

It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)

However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.

The test program runs great on macOS, but when I use xgo to cross-compile it for Linux, all it outputs is:

And, xgo to build cross-platform from Linux; yet I can run in Windows and macOS.