Flutterby™! : Memory safety is a small part of safety

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Memory safety is a small part of safety

2025-11-20 01:59:18.495222+01 by Dan Lyke 2 comments

I've been thinking a lot about what language I want to use next. I've been mostly working in Objective-C for the past... egads... too many years, and while there are aspects of the language I like, it is not terribly performant in message dispatching, and introspection is possible, but can be ugly.

C and C++ are awesome for so many things, but there's always the memory safety thing lying over them, and C++ in particular is annoying as hell cross-platform: What version of Boost is on this platform? What compiler semantics have changed such that there's now some obscure template matching error that's preventing code that compiled fine a decade ago from working now?

Swift is...

I've done a little bit in Rust, and looked a little bit at Zig and Go, and all of them feel like it's hard to really express an idea in them. Which, I mean, on the one hand is kind of the point, they're about straitjackets, on the other hand I wonder how much value the straitjacket has.

TARmageddon (CVE-2025-62518): RCE Vulnerability Highlights the Challenges of Open Source Abandonware is, on the one hand, about trying to do responsible disclosure on a package that's been forked a gazillion times and is no longer maintained, on the other hand it's also about how memory safety is only a small portion of safety.

nullagent @nullagent@partyon.xyz who has "...a grey-beard rant about how Rust give developers a false sense of security.".

[ related topics: Free Software History Work, productivity and environment ]

comments in descending chronological order (reverse):

#Comment Re: Memory safety is a small part of safety made: 2025-11-20 20:41:52.436604+01 by: Dan Lyke

For literally decades, my go-to for a new language has been to port the Flutterby markdown+HTML processing parser into that language. It's a bunch of regexes, it's got some known issues, but it's been a good way to move forward.

But I've recently been playing with more better smarter parsers, so I figured I'd start there with Rust, and part of that was creating recursive data structures. You can see the problem looming...

So, yeah, I made an arena, used arrays of indexes into the arena as my substitute for pointers, but all of a sudden what was a parse tree that, sure, wasn't quite as clean as a Yacc input file, but with some C preprocessor syntactic sugar wasn't a nightmare, became an absolute nightmare.

And, sure, I could create a preprocessor that took some simpler form and output Rust, or do so with one of the existing systems (though I want to do somethings with autocompletion, so I'd really like to be able to explore the parse tree at run time), but I also want to work in a language in which I can feel expressive.

#Comment Re: Memory safety is a small part of safety made: 2025-11-20 17:58:29.597364+01 by: battjt

I'm a Java programmer by day and a Rust programmer as a hobby.

Rust feels like it is being developed by the hardware guys. As an application developer, somethings are really hard. For instance, adding a callback to a button that references a piece of single large shared "business object" data structure is hard.

I suspect that there will be some crate that addresses this in about 5 years, but until then it's going to be a lot of experimenting. I had to create a way of passing around lambdas that represent paths into the global dynamic data structure.

I think that the ecosystem of Rust is worth the pain. I would use Rust for my day projects if we didn't already have a million lines of Java. For example, everything being a crate makes it easy to update libraries, which can be very painful in Java. (Java could have had versioned libraries by default and made the ability to load multiple versions at once easy, but it is difficult.)

Comment policy

We will not edit your comments. However, we may delete your comments, or cause them to be hidden behind another link, if we feel they detract from the conversation. Commercial plugs are fine, if they are relevant to the conversation, and if you don't try to pretend to be a consumer. Annoying endorsements will be deleted if you're lucky, if you're not a whole bunch of people smarter and more articulate than you will ridicule you, and we will leave such ridicule in place.


Flutterby™ is a trademark claimed by

Dan Lyke
for the web publications at www.flutterby.com and www.flutterby.net.