qemu-system-i386 -hda war
The submitted file in2war64.com shows only the blue "background" when run from bare-metal booted DOS floppy on a Pentium D (x64 based on dual x86) with its associated Intel graphics hardware. No sound either.
Your file "war" is a nice binary, works natively as sector 0 of a floppy disk, with a traditional FDD plugged directly into the legacy FDD parallel connector.
On the same hardware.
Also works with USB floppy drive, even on a UEFI PC as long as the Legacy/CSM is enabled and Secure Boot is disabled.
To use a common USB Flash Drive (UFD) natively instead of a floppy, legacy BIOS can require a partition table to be also present on sector 0 of the removable UFD. This can be effectively added by partitioning (format not needed) after copying "war" to sector 0 of the UFD:
from Linux command line:
First copy "war" to sector 0 of the UFD, where X is the identifier of your unmounted UFD:
(sudo) dd if=/<path to>/war of=/dev/sdX bs=512 count=1
This overwrites any MBR and partitontable that may already be on sector 0 of the target X UFD; with the functional "war" replacing the MBR, and zeroes replacing the partition table.
Only sector 0 is replaced, all other sectors remain unchanged.
At this point sector 0 of the UFD is no different from sector 0 of the working floppy disk.
Then create a partition on the target X UFD using cfdisk:
(sudo) cfdisk /dev/sdX
make it primary, full size, bootable, type 0C
Only the final portion of sector 0 is altered (leaving the "war" binary intact at the beginning of sector 0), all other sectors remain unchanged.
Then the UFD boots natively just like the floppy.
Still for UEFI need Legacy/CSM to be enabled and Secure Boot disabled.
Still no sound.
Yeah I know assembly language isn't a sensible choice for all but a tiny specialized niche of projects, hardware/bandwidth is far cheaper than developer time and so on but it's still refreshing to see people doing this kind of thing just out of pure passion.
The 1500 npm dependencies problem you speak of is exactly what I expect to never even see, let alone have to deal with, in the Go ecosystem. It's not exactly surprising coming from one inventor of UNIX and C (Ken Thompson) and Rob Pike, two greats from Bell Labs, but when I heard that the creator of NodeJs had ditched that to go work in Go, now that I registered loud and clear.
After seeing for myself, I can understand. Go is a wonder, truly, and such a treat for systems (from sysadmin to CI/CD passing by performance, readability and safety). Something like Js can only eventually collapse on itself, when there's a better alternative. I mean, we could just as easily bundle a Python interpreter in browsers (to name just one candidate), Js is the frontend bible written in stone only because we keep it this way. Progressive apps are already showing a way between browsers and OS and I expect this line to get ever more blurry as virtualization (containers etc) continues its re-imaging of the entire computed infrastructure.
I'm so thankful that computing evolved so fast that we can be here now, from there/then, and yet still have relatively young giants walking among us. The program-star hall of fame of very alive and active pioneers / creators is honestly humbling and inspiring.
Tbh, I don't know how or why the language wouldn't be suited to very elegant front-end design, I feel the biggest obstacle is general framework fatigue: people are tired of seeing every language under the sun try to do everything, so they stick with what's existing on the frontend (convergence around a few Js frameworks over the last years for instance), while Go devs keep it to server/infra mostly (unrelatingly, just doing their thing). These being just two examples.
Thus GUI options are the same as anything else afaik, provided you can interface with your Go backend. Note that I've heard bad experiences with code injection so I wouldn't try that first nor without extra care.
The solution depends on your use-case, and what platforms you are targetting. I'm partial to KDE on Linux desktop thus Qt is a strong candidate for me; however I dislike non-native apps in most situations so I'm not sure I'd recommend Qt for a wider project in target OS scope. Again, use-case, design specs should preside over this debate. Embedded, sure.
Language is hardly ever the cause of any significant bloat.
I can find similar dependency hell problems in every platform I have used.
Maybe it's me. I could charge a fee to stay away from your favorite platform...
3D, Raytracing, fish-eye effect, movement.. its fascinating!
> The string contains invalid characters.
Of course it's one downside among many upsides but I think there's a point to having a simpler interface to allow stuff like this
With 64 bytes you can't even initialize a window on Linux or Windows.
I saw it discussed on Lobsters.