New project by NODE:

Today I want to show you a project I’ve been working on. It’s a digital book called Make it Yourself: 1000 Useful Things to Make, and it’s basically a showcase of some of the best open hardware and DIY projects from across the Internet.

The book is free to download and every project is illustrated with a beautiful line art graphic. Download it at: makeityourself.org

Dirk Jonker:

I started building “version 2” of the application. I chose Rust as the language for the backend and SvelteKit for the frontend. Initially, the new version looked great, was blazing fast, but only had about 10% of the required features. As Rust doesn’t really have anything comparable to Rails, I ended up having to do a lot of plumbing instead of writing business code. After a while, it became obvious that I could never write a feature complete version 2 without completely freezing version 1. So version 2 got thrown in the bin.

I did Rails professionally for more than a decade and there’s no argument that it lets you develop functionality quickly. This is partly due to it being a very complete framework, much more-so than all the Rust ones. Rocket comes closest but Rails still has a lot more built-in.

Was this the end of the story? Absolutely not. Having experienced the joy of Rust, with beautifully typed code and blazing fast performance, the feeling of confidence you get when something compiles without errors, I knew I had to have Rust in the application. Despite over four years with Ruby, I still regularly wrote code that had issues at runtime. Mostly issues with null values and unhandled exceptions. After each deploy, I would closely watch the error reporting tools and quickly fix any issues that would occur in production.

Runtime issues are the catch to Rails though. In every Rails app I worked on there was always a constant stream of exceptions, many related to nil. I eventually became quite demoralised by this, especially when on-call and having my sleep ruined by yet another NoMethodError: undefined method for nil:NilClass exception.

When the opportunity arose, I left the Rails ecosystem. I now work on a product that is implemented in languages that don’t suffer these problems¹. This entire class of bugs almost never occurs now—and we didn’t have to resort to heroic testing to get there, the compiler does it for you.

I build all personal web applications in Rust now too, including this very site. They take longer to implement initially but once deployed are efficient and stress-free.

Every project is a trade-off though and Dirk addresses some of this at the end of the post:

But what about the downsides of Ruby and Rails then? Well, those are simply things to take into account when writing code. Let me give my opinion here. Have many issues at runtime? Test more. Does it turn into unmaintainable spaghetti code after a while? Only if you let it. It’s typically caused by developers, not programming languages or frameworks. There are plenty of ways to nicely organize your code and you should probably spend more time refactoring.

Hello and welcome to Linked List. I’m Wesley Moore and through this site I hope to bring you interesting posts on tech with a bit of commentary. Topics include open-source, programming, hardware, software, Linux, Rust, retro computing etc.

The site takes plenty of inspiration from John Gruber’s Daring Fireball, a site I’ve been reading for a couple of decades now. As time has gone on I’ve drifted away from the Apple ecosystem and I feel there is space for a Daring Fireball style blog covering topics outside Apple and mainstream tech news. Basically stuff that interests me—and hopefully you.

I expect the site will cover technology and software ecosystems with a slant toward open systems. If you’re a developer, technologist, Linux, BSD, UNIX user I think you’ll enjoy the site.

In addition to reading on the website you can also subscribe to the RSS feed or follow the Mastodon account, details of which are on the follow page. Thanks for stopping by.

Kirill Fedorov:

In this article I’ll discuss different strategies for incrementally adding Rust into a server written in another language, such as JavaScript, Python, Java, Go, PHP, Ruby, etc.

I think all of the strategies are good, but Tier 3 stands out as being the best bang for the buck. If you can use an off-the-shelf binding generator library then writing a native function in Rust is super easy and it can have a profound effect on performance.

This is an interesting case study to read alongside Nolan Lawson’s recent post: Why I’m skeptical of rewriting JavaScript tools in “faster” languages:

One reason for my skepticism is that I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster. Marvin Hagemeister has done an excellent job of demonstrating this, by showing how much low-hanging fruit there is in ESLint, Tailwind, etc.

In the browser world, JavaScript has proven itself to be “fast enough” for most workloads. Sure, WebAssembly exists, but I think it’s fair to say that it’s mostly used for niche, CPU-intensive tasks rather than for building a whole website. So why are JavaScript-based CLI tools rushing to throw JavaScript away?

Now I will admit the posts are talking about different applications: CLI tools vs. web servers but they both consider performance. In Kirill’s post the Rust rewrite has 4.93× the request throughput, which I think supports Nolan’s thesis. However, the Rust version does it using 13 MB of RAM compared to 1.35 GB for the node.js version!

Jan de Mooij writing on the SpiderMonkey blog:

In September, machine learning engineers at Mozilla filed a bug report indicating that Firefox was consuming excessive memory and CPU resources while running Microsoft’s ONNX Runtime (a machine learning library) compiled to WebAssembly.

The issue with the ONNX module was that the Ion compiler backend took a long time and used a lot of memory to compile it. On my Linux x64 machine, Ion-compiling this module took about 5 minutes and used more than 4 GB of memory.

⋮

With these changes, Ion can compile the ONNX Wasm module in less than 3.9 seconds on my machine, more than 75x faster than before these changes.

I find it satisfying reading about optimisations like this. The same end-state is achieved, but in vastly less time and space—it feels like magic.