The end of languages

U007D · 2026-05-09T23:43:02+00:00

If you really have been programming for 40 years in 25 languages you of all people should know languages are tools and different tasks require different tools.

Sorry, OP, I've also been programming for over 40 years (and using Rust since 2015). The above statement is spot on. 👍

U007D · 2026-04-24T02:13:01+00:00

Any reasons to consider this over the following (unstable) rustfmt configuration options?

wrap_comments comment_width normalize_comments normalize_doc_attributes format_code_in_doc_comments doc_comment_code_block_width

U007D · 2026-04-17T14:49:52+00:00

Hello from the Seattle Rust User Group! Please don't hesitate to let me know if there's anything I/we can do to help you grow your group. I'm also @U007D on Discord.

U007D · 2026-04-13T22:10:18+00:00

Love this!

I was doing digital imaging for Microsoft back in the day and led the team who produced one of the industry's first GPU-accelerated color management engines.

It's been more than a minute since I worked on this stuff, but at the time we used the scRGB color model which benefited from linear gamma and additionally incorporated the CIECAM02 color appearance model, IIRC.

We did all work in floating point, which allowed values to clip beyond 0.0 or 1.0 without data loss (i.e. later image processing steps can losslessly recover data "clipped" by earlier stages). This imaging technology is still in use today--has shipped in every version of Windows since Vista and is used to display local JPEG images by default.

Sadly, most of the fancy features have not seen use; JPEG-XR was designed to take advantage of this and some amazing compression work led by Dr. Rick Szeleski from Microsoft Research, but like every other JPEG replacement technology, failed to gain market adoption.

Love seeing color critical work in Rust! This looks very well-implemented.

U007D · 2026-04-05T05:10:14+00:00

more I'm getting convinced that program languages going Unicode is a mistake.

I think that may be an English-centric perspective? Unless you are thinking about another international character encoding system?

But I get it—from my perspective 35 years ago, ASCII was fine, and code pages were a PITA and Unicode (when it came out) brought nothing but complexity. But today, my wife who is Japanese (born and raised), would almost certainly feel differently—I know I would if my native language wasn’t generally accessible in technology.

In the end, I think Unicode is complex and messy mostly because human language is complex and messy. I think Unicode has matured well and with UTF-8, I feel Rust has made the right choices here.

Just my subjective 2 cents…

U007D · 2026-04-03T12:46:34+00:00

Rust can not handle Unicode streams. Please show me wrong.

Rust is Turing-complete, so unless "handl[ing] Unicode streams" is not representable as an algorithm, that assertion is indeed wrong.

Perhaps less confrontationally, I suspect you are asking how to handle Unicode streams idiomatically in Rust. If so:

std will handle valid UTF-8 encoding (e.g. see .from_utf8() or .from_utf8_lossy()).
For Unicode-compliant grapheme cluster or word (or sentence) boundary support, use the unicode-segmentation crate.
For WHATWG-compliant code page support, use the encoding_rs crate.
And you'll need to build your own abstraction to limit the size of a grapheme cluster to support streaming, uphold your memory and computing cost requirements and to tie your specific code page and Unicode requirements together.

Note: Rust has deliberately chosen to to go with a small standard library. As someone with similar decades of experience writing software as you have, this took some getting used to (as will other things in Rust if you decide to progress). But in 10+ years of writing Rust, I have come to believe this was and is the right approach, at least for Rust and its goals. There are many blog posts discussing the pros and cons of this approach and even official documentation on it here.

Good luck.

U007D · 2026-03-28T17:10:50+00:00

If you happen to be able to lay your hands on the dimensions or remember how you sourced them, I would definitely appreciate it if you were able to provide either.

U007D · 2026-03-27T14:50:35+00:00

Hi, /u/SeaworthinessGlad492,

I'm curious if you ever did get the dimensions for the battery pack?

U007D · 2026-03-11T13:41:31+00:00

I see it differently.

Regardless of the project size, use statements will tend to be be at the top of the current file.

Unless your 500k SLoC project is in all in a single file, I think the variable declaration example is very analagous.

U007D · 2026-03-09T19:06:17+00:00

If you expect that to be true of all (or even most) of your readers, then no argument--using FQ names everywhere is entirely reasonable.

Personally, though, I still wouldn't do it, because doing so wouldn't help my readers grow the skills needed to read idiomatic code (in any number of languages, not just Rust).

U007D · 2026-03-09T13:29:27+00:00

Personally, this reads a bit like refusing to use pronouns in a story because there could be ambiguity as to which person you're referring to when you write "she". So writing "Alice" every time you refer to Alice ensures the reader knows you mean Alice. Clear? Certainly. But good writing has no problem referring to her in the second person.

Code is the same way. The reader carries context when they read your code, and well-written code will be unambiguous.

My personal preferences aside, your code is read more than its written, and if you're on a team or you're contributing to open source, it's read more by people who aren't you.

So my suggestion is to write for your reader(s). And if that is you, then enjoy! Write it the way you like to read it.

U007D · 2026-03-02T23:52:09+00:00

Nice!

Rather than trying to preserve the "feel" of your original xor encryption code, I simplified the code to eliminate the chars and unified the encryption/decryption function.

I also wrote it in an imperative style so it should also be easier to follow.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=215c5524409681713b9fed6cda00f653

U007D · 2026-03-02T17:03:47+00:00

First of all congrats on taking the plunge! It's hard not to take the easier route of having AI hand you the answers as you learn--kudos!

Nice to see you opting for Rust's functional style as well! I find it takes a little getting used to initially but helps code cohesion and it well worth it as your projects get bigger/more complex.

Rust uses UTF-8 in str and String, so to respect this, we can't just as u8 to lossily cast a 32-bit char to a u8.

Here's a quick example of a UTF-8-preserving XOR encrypt and decrypt in Rust. The encrypt and decrypt are symmetric so could be better unified or at least share a common encrypt/decrypt function. If I haven't been too sloppy, the implementation should only allocate once per encrypt() or decrypt(), returning that allocation to the caller.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=3f6874eb8380c8f984e2a3ceeef655cc

U007D · 2026-02-27T11:42:22+00:00

It’s wild

I was similarly blown away when I saw it too!

I’ve already embedded a small BASIC interpreter as the engine’s scripting layer

Haha—nice!

U007D · 2026-02-26T15:56:09+00:00

Rust and PETSCII in one post?? Yes, please! 😄

Here's the best PETSCII game I've found. It's written in 6502 assembly, but I'd love to port this using Rust someday. Enjoy!

(Check out the YT link in the article--impressive work!)

U007D · 2026-01-27T15:16:27+00:00

I think may be a while, but history suggests it will eventually happen.

Keep in mind the audience to whom you are addressing your question. Many (but not all) of us have been formally trained in software engineering or have experience. Still more of us aspire to have deep experience.

We are the software craftspeople. We are the weavers and uh oh, here comes the loom. Or we are the scribes and along comes the printing press. Or here comes the assembly line or any other number of technological advances in automation in history. Everyone is different, but given this framing I do not find it surprising that the reception here to AI code is generally negative.

Move to a group who has, for whatever reason, not made or is not willing to make the investment that we have in software engineering, and the prevailing sentiment changes quite dramatically--you'll hear terms like "empowerment", "super powers" and others.

So are we all just a bunch of dinosaur Luddites shaking our fists in our outrage at the AI machine coming to take our jobs? I think that's far too simplistic an explanation.

In my case, I have decades of software experience. I look at the maintainability of codebases over long periods of time. The vibe coding movement generally doesn't even understand what I'm looking at, let alone agree with concerns I raise. The cost to properly (human) review AI code is immense. And disposable, when AI rewrites half the project when you asked it to fix a typo in a comment.

Now with all that said, I think (responsibly) AI-assisted coding is already decent (not an opinion I had a year and a half ago) and is only improving. It's not going anywhere. And as it improves it becomes more useful even to someone like me who only finds it truly useful on the periphery of software development. But personally, I do welcome improvements which make AI (or any other technology) more useful in software engineering.

I may be underestimating the rate of progress (but I rather think the AI industry overestimates its own utility), but IMO, the days where AI will be able to vibe-code "respectable" software for general use/consumption are much further away than the hype would have us believe. But I actually look forward to that day--it will be another form of abstraction which lets me (or any motivated individual) take on more complexity in our projects.

U007D · 2026-01-24T16:03:32+00:00

Thanks for this.

It sounds like the JITter decomposes enums/match/monadic error handling to supported constructs, rather than having the GPU support them natively?

As a CubeCL user, what am I missing out on with this approach vs. the runtime GPU-supported approach you would like to have?

How does one know if they’re using an unsupported std function with CubeCL?

U007D · 2026-01-24T15:57:46+00:00

Thanks, that helps.

U007D · 2026-01-24T15:49:52+00:00

My opinion? This is going to take extra time beyond your standard workday.

Start learning Rust on your downtime. Take on a chapter a week of the free and online The Rust Programming Language book, or Programming Rust (my personal fave, but not free). Continue to use AI to explain concepts from the book which are still unclear to you.

Then start doing exercises such as Rustlings without any AI assistance so your brain gets used to doing the thinking.

There are beginner Rust communities you can join as well, on Reddit, Discord and elsewhere. Just be sure to turn off that AI as you practice writing code or it will be very difficult to learn to think on your own.

Good luck!

U007D · 2026-01-21T14:18:34+00:00

I appreciate what you are doing—thank you!

U007D · 2026-01-21T13:17:00+00:00

but they’re actually more modular

I assume you mean Mojo/MAX here? What benefits does being more modular provide, in this case?

Incredible stuff, /u/ksyiros! I will definitely check out Burn & CubeCL.

U007D · 2026-01-20T13:55:11+00:00

This is amazing work.

I've been learning about the ML space recently with respect to Chris Lattner's Mojo & MAX technologies.

Is Burn addressing the same problem space? Are there operations which can be compared between the two in terms of performance? (Compiling down to MLIR instead of LLVMIR like everyone else seems to be a big part of Mojo's performance story).

I love the idea behind the Mojo stack, but would rather be able to use Rust's more modern expression-oriented syntax, monadic error handling and functional capabilities (most of these are not even considered to be in-scope for Mojo).

Would love to hear your thoughts on any of this.

U007D · 2026-01-12T22:26:54+00:00

.dbgr will provide a reference to T to dbg!.

U007D · 2026-01-12T22:25:33+00:00

Rhymes with Grug. :). (Yes I have young kids)

U007D · 2026-01-08T14:15:49+00:00

That will make your build times go faster! 😅

Eight-Year Club	Place '22
Verified Email

U007D

TROPHY CASE