Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Kragen Javier Sitaker Newsgroups: comp.lang.misc Subject: Re: =?utf-8?Q?What=E2=80=99s?= Your Least Favourite Programming Language? Date: Thu, 27 Aug 2026 21:11:55 -0300 Organization: A noiseless patient Spider Lines: 142 Message-ID: <87ik4vdrxw.fsf@debian> References: <10e1m38$8ukd$1@dont-email.me> <20251031081742.00003c76@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 28 Aug 2026 00:14:12 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2022280"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ZPGy6dlHTEzSHnjM+FGJI"; posting-host="20f15c747cee91003e0b3dab76b5eff8" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:StBfLcSAJ8jurhd43IgObMlDTw0= sha1:3F/KaPdvaHb4+AbRHPvM/55b/Xo= sha256:G06Axe0lzlo+AGzeWd/eInifCQZ/fG1dHVAyqv52Zik= sha1:4kJPJ+e3aEg/VFiPb86ORFesRkM= sha256:HlRdfpfUU3jfeCI8emmToZPWh49p+MYgjYmPQa0PV3U= Xref: csiph.com comp.lang.misc:11835 John Ames writes: > Another language that feels needlessly gross and tedious is Java - > (...) but then it's somehow still the best solution we've got for > write-once-run-anywhere development, which is maddening :/ I think that may have been true around 02001, when J2ME could run more or less normal Java code on *all kinds* of fairly small feature phones. But it never made the leap to smaller microcontrollers like the AVR, feature phones evaporated, feature-phone-sized microcontrollers never acquired J2ME support, and now in 02026 we have a number of better solutions: C under Unix, portable C, Rust, Python, JavaScript, Wasm, Godot, and Golang. (In the following, by “Unix” I mean GNU/Linux, FreeBSD, and similar systems, but not Android, Microsoft Windows, macOS, iOS, or System/360.) - C under Unix, because you can run QEMU on just about anything that runs Java. If you run Microsoft Windows, it ships with WSL2, so this works out of the box. Unless you want a GUI, in which case you still probably want to run QEMU. Android might be the main exception; it ships with an incompatible implementation of Java (without, for example, AWT), and although you may be able to recompile Unix software for it, it can be difficult. I’m currently trying out the “Limbo x86 PC Emulator” QEMU package from F-Droid, and I’ve gotten SeaBIOS to complain that it can’t find an OS image, but I haven’t gotten Linux to boot in it yet. Unix doesn’t run on small microcontrollers, but C sure does. With sdcc you can even run it on a PIC or an 8051, though you wouldn’t want to. - Portable C, for example with wxWindows or Qt. For libraries rather than applications, this has historically been a much better choice than Java, because you can call it through FFIs from other languages. Of course, you can also write nonportable C, but you don’t have to. WORA applications written this way (and in portable C++) historically vastly outnumbered WORA applications written in any other way, including Java, but now JS has taken the crown. - Rust seems as easy as C to call through FFIs, and it’s almost as portable, and significantly less error-prone. It seems uglier and clumsier, though, and its support on microcontrollers is rocky and unpredictable. - Python, which ships with somewhat adequate web server support, and Tkinter, which is a somewhat adequate GUI library. It’s relatively easy to write a Python program (GUI, command-line, or HTTP server) and have it run consistently on Unix, Microsoft Windows, or macOS; and lots of Python libraries can also run on microcontrollers with MicroPython/CircuitPython. As with C, you can write nonportable Python, but there’s much less temptation to do so, because the portable standard-library API is significantly more complete, including things like filesystem access, multithreading, asynchronous I/O, and Tkinter. This is a much less compelling choice in the last several years since the Python maintainers have adopted a policy of deliberately breaking standard library backward compatibility in every point release. WORA GUI applications written in Python include Calibre, and there are a vast number of WORA applications that run as web services. - JavaScript reduces the barrier for running your software on any cellphone or other personal computer about as far as possible — just click on a link, and your JavaScript application starts running. The performance isn’t as bad as you’d expect, although JS authors habitually squander performance, and the text handing isn’t nearly as bad as Python’s or C’s. This has been the overwhelmingly most popular choice for WORA for the last 15 years. JS has the unique advantage that you get portable access to not just a basic GUI library, but platform features like 3-D acceleration, multitouch, cameras, audio input and output, a form of internet access (though not plain sockets), the clipboard, and NFC (except on iOS). The browser console and inspector also represent a kind of live interactivity and debuggability that is really lacking in Java, C, Rust, or even Python (though a Jupyter-style notebook interface would improve the browser console further.) This is a huge advantage for JS in my book. Microcontroller-capable JS engines include Moddable (XS) and MicroQuickJS; maybe also Duktape, JerryScript, MuJS, and Hermes, but I’m not sure. And JS is maybe the most popular language for writing HTTP server apps in with Node and Deno. I don’t think there’s a Tkinter-like option for writing non-browser GUI apps, unless you count Electron, which is basically just a browser without an address bar. People who hate dynamic typing will appreciate TypeScript, a statically-typed dialect of JS. - Wasm (WebAssembly) also runs in all the mainstream browsers, as well as some non-browser runtimes, and it’s a much easier compilation target for things like C than JS is, and gets much better performance as well, like, double-digit percent overhead rather than small-integer-multiple overhead. It doesn’t support multithreading (or, it sort of supports multithreading if you bend over backwards enough — Godot 4 supports this option, but you have to configure your web server specially). You can compile just about anything to Wasm that you can compile to native code, using Emscripten, which uses LLVM. But, when it’s running in browsers, you rely on JavaScript for access to any platform APIs. This can be annoying, but it isn’t really that restrictive, since JS has access to 53 tonnes of platform APIs, as mentioned above. - The Godot game engine, like C, Rust, and Python, doesn’t have any artificial sandbox limitations like Wasm, JS, and Java, and games written in it tend to run unchanged across Unix, macOS, Android, iOS, Wasm, and even Microsoft Windows, even when they use advanced graphical capabilities like custom 3-D shaders. The development environment is also “live” in a way that exceeds even JS’s liveness. (There’s also very limited support for something called “visionOS”.) Godot 3 can export to single-threaded Wasm that can be run from any web server, but Godot 4 requires you to configure the web server in a weird way so that Wasm can implement a sort of multithreading. - Golang, like Python, has an API that’s significantly more stable across platforms than C’s, and unlike Python, it isn’t totally screwing the pooch when it comes to text handling and library API stability. It has much better performance than Python or JS, and is, to my eyes anyway, more readable. Because of its Plan9 heritage, cross-compiling for multiple platforms is trivial, but I don’t think it supports small microcontrollers at all. I’ve never heard of a successful Golang GUI app (it’s used almost exclusively on web servers) but apparently there’s a Golang widget toolkit now called Fyne, which supports Android, iOS, Unix, and Microsoft Windows. The above probably isn’t news to most people reading this post, unless I got something wrong, in which case please correct me in the traditional Usenet fashion. Kragen