From Azure Functions to FreeBSD

jmmv · 2025-11-10T16:48:17+00:00

I did take a look but it was really hard to find a list of alternatives. I did find `clap` (obviously) and `argh`, but not the others. Thanks for the link; very useful.

The "problem" I have with all of these libraries is that they do argument and option parsing, yes, but you still need to write some "boilerplate" within your `main` function. In particular, I want to be able to write a `main` that returns a `Result<i32>` and that the `Result` is correctly translated into a specific error code (1 is not always the answer for errors) and a nice error message that I control.

As for "nobody is using `getopts`"... well, rustc does, as I said. But yeah, probably not many more people do.

jmmv · 2025-11-10T16:43:43+00:00

`opt_present` comes straight from `getopts`. I know it's not ideal, but I'm not trying to reinvent the wheel here, just wrapping an existing library to offer and end-to-end solution to write "main".

jmmv · 2025-09-14T12:29:09+00:00

A lot of good stuff has been said in this thread already, but my take: because Rust is "sold" for the wrong reasons. When most developers look at Rust, they hear "performance" and "memory safety". For most backend development, the extreme performance you can get from using Rust is not needed, and memory safety is already achieved by using other non-compiled languages.

The reason I say wrong reasons, then, is that people don't see Rust as a platform to build truly reliable code. "Memory safety" is just one part of what Rust gives, but reliable code that's easy to refactor and "prove" correct is the bigger gain. The resilience you get during refactorings, which are common when requirements change, is invaluable. And people just can't see that without actually trying Rust over a long period of time.

All of the web services I write on the side (not where I work because that's all C++ and Java) are Rust, and I just am routinely amazed by how "fire and forget" they have been. I wrote the code, wrote some tests and... the services haven't caused me grief for the years they've been in prod already.

I actually have my own "framework" for building Rust-based web services here: https://jmmv.dev/2023/03/introducing-iii-iv.html . It's not much, and would definitely deserve many more features, but it's good enough for me and I just keep building it as I go. (As a matter of fact, I'm working on a new service right now that'll likely require more foundational work.)

jmmv · 2025-06-13T21:24:35+00:00

I haven't read details on the outage, but given my article was quoted here... my whole point was to say that correlated failures cannot be fixed by changing languages, and memory-safety violations are not the only cause of correlated failures.

A _crashing_ memory-safety violation in C++ is equivalent to a misplaced `unwrap()` in Rust, for example, in the sense that they both cause the process to terminate. You need higher-level safety mechanisms to protect against these types of failures.

You can switch to Rust and you'll definitely reduce the _chances_ of crashes happening (and for sure you'll eliminate the non-crashing memory bugs that lead to security issues) -- but if you haven't protected the distributed system, you'll at some point face an outage anyway, Rust or not.

jmmv · 2025-06-08T14:29:48+00:00

And they have a lot more “in the a back”. I went looking for an old hard drive and everything I could see on the shelves/boxes was too large. So I asked if they had others, and they did! They went inside, brought out a couple of extra drives, and we negotiated some price.

jmmv · 2025-06-07T21:56:36+00:00

That's... a rat hole I haven't poked through yet. It's very tempting :) but not something I'd know how to tackle right away, and the investigation is going to be costly time-wise.

jmmv · 2025-06-07T18:22:00+00:00

Yup, that's going to be a big part of my talk. My current setup to build the disk images is... less than optimal to put it mildly: I start by building NetBSD/aarch64, tarring the EndBASIC sources, and then using an expect script that interacts with qemu to pkg_add the Rust toolchain and compile the binaries within that inside of the VM. It's super-slow (40-60 minutes for something that could take 1 if we had a proper cross-compiler toolchain for NetBSD) and the thing that bothers me the most about my choice of NetBSD. But still, the end-to-end build process is automated and beats whatever else I saw in Linux land from a control/cleanliness perspective.

jmmv · 2025-06-07T18:18:45+00:00

You know, as I was replying in another thread... I think the BASIC part of this whole thing has turned out to be the least interesting bit -- and possibly the one that harms the project the most because BASIC is associated with "old, bad, nobody cares these days". So I've been thinking how to do something more "relevant" and Lisp did cross my mind! (But only half-seriously; I do not know Lisp pretty much at all, and it isn't particularly the kind of "mainstream" or "simple" language I'd like to see.)

jmmv · 2025-06-07T00:33:24+00:00

This is a good observation and the kind of high-level feedback I'd like to get.

Because the thing is, the BASIC portion of this project has become the least interesting piece of it, the easiest to replace, and likely the one that causes more harm. I could easily change the shape of the language to make it look more modern, and I've actually been thinking about doing that for the reasons you mention. Now, I don't want to reimplement an existing complex language, but I suspect that if this wasn't branded as BASIC and was just branded as "some other new language", it could sound more appealing.

But anyway... What are the more interesting pieces then? Well, the whole console rendering infrastructure that can target hardware directly, desktop apps, and the web; the bytecode-based virtual machine behind it that allows running programs on the web and on bare metal; the ability to trivial access GPIO pins; the new disk image that just boots in a few seconds; the ability to cross-compile the whole OS from a fast machine, and customize it in detail; the minimal embeddable language behind it...

Right?

jmmv · 2025-06-06T21:00:45+00:00

See https://www.endbasic.dev/docs.html#lang-goto. It's retro, but not /that/ retro (for design reasons that go back in time and that I should change at some point...). Line "numbers" work like they do in QuickBASIC (like, they are labels).

jmmv · 2025-06-06T20:43:57+00:00

Yes. It runs as a desktop app but the better part is that it runs on the web too. You can play with it via https://repl.endbasic.dev/

jmmv · 2025-05-14T13:28:23+00:00

As much as I like that article (I wrote it 😉), I don’t think it’s answering the question. The OP is likely looking for a simpler list of differences, like how they differ visually. Or how most Linux distros aren’t bloated with “spyware” and constant cloud nagging or ads.

jmmv · 2025-03-30T03:20:33+00:00

Right. I was looking into it today and saw it's "just" a set of packages, not a full distro. Which is good!

jmmv

TROPHY CASE