~/funzen

rIDE: a composable non-IDE for terminal junkies

2025-10-20T00:00:00+00:00

This is just my opinion and a very subjective affair. YMMV. I express preferences that may not match yours. And that’s fine. I neither pretend nor imply to lay down this as a paper nor as a definitive solution for everyone. There’s nothing scientific about this. Paraphrasing a Grace Jones song</a>: this is not perfect, but it’s perfect for me.
That being said, I’m passionate and I like sharing things I believe have merits and could benefit others. This is the spirit you should keep in mind, while reading this.

I first heard of non-IDE in a Zed video</a>. That made me realize I was assembling a non-IDE. I had recently switched to Helix. I decided to name it rIDE</code> and to blog about it, there and then. I believe they deserves credits for inspiring this blogpost.
</a> The Elevator Pitch</h2> I’ve used every text editor under the Sun1</a> and I’ve editor hopped</a> for years, while sticking with (n)vim, looking for the perfect IDE. One that would fit my needs and tick all checkboxes2</a>. Until I heard about Helix Editor</a> and decided to give it a go. Helix is fast. It’s modal. It’s featureful. It requires no maintenance. It supports all I need. The learning curve and switching costs were minimal. I never looked back. Helix, despite the name, is an IDE</a>. However, it doesn’t have - to name a few - a file manager, a terminal emulator, nor git porcelain. By design. Helix’s focus is to offer core IDE features - no more3</a> - out of the box. A choice akin to the UNIX philosophy</a>. One that other editors users may find limiting or lacking. On the other hand, it’s an approach that enables comprehensive modularity, which is rIDE</code>4</a> core principle. rIDE</code>, simply put, is: use the best tool for the job. Each with its own configuration5</a>. Easy to integrate with Helix. Easy to replace, when you want to swap a specific tool for another. All within your favorite terminal emulator. Live happily ever after. 🥳 🎉 Having to compose external tooling may seem unnecessary extra-work, at first. I thought so too, after some usage and when pondering the switch. It didn’t take me too long to accustom to this new normal, though. Which is comparable, for the most part, to using extensions. That said, the perks of the rIDE</code> approach are numerous. Most importantly: a level of flexibility and peace of mind I haven’t had in a long time. </a> The Full Story</h2> </a> Holy Wars</h3> In my early days of involvement and falling in love with Copyleft6</a>, I’ve ideologically been closer to FSF</a> than OSI</a>7</a>. Thus, for reasons as silly as the editor war</a>, I was tempted to join The Church of Emacs. Although, as I was looking into a Linux System Administrator</a> career, I made a pragmatic choice. Systems shipped vi(m). Thus, I learned vi(m) and extensively used (n)vim - vanilla, custom, with plugin managers, or distros - for about 20 years. It would still be my backup editor, should the need arise. </a> Terminal Mon Amour</h3> As system administrators do, I live(d) in the terminal (with or without a multiplexer). The terminal is my preferred environment. When feasible and reasonable, I rely on and prefer terminal applications. Not a brag. It’s relevant for later. Put a pin on this 📍 </a> GUIsclaimer</h3> Later, I’ll get into some of the editors I explored and used for a varying amount of time and degree of satisfaction. Some of them are graphical. A common issue I have with graphical editors: they slow me down. In this context, GUIs are distracting. I often have found myself fighting them and having to think about most interactions. </a> It’s Not You, It’s Me</h3> (n)vim is a great modal editor I love(d). It became second nature to me, and it’s the one I’ve always went back to during my editor hopping explorations. That being said, personal pain points motivated me to seek out alternatives. Lately, more intensely. </a> Every Text Editor Under The Sun</h3> Amongst the many I explored1</a>, whilst still using (n)vim8</a> as my GOTO</code> and fallback, the three alt-editors shortlist, for features-related merits, comes down to: VS Code: supports basically everything; Live Share / pair programming tooling.</li> DOOM Emacs: the meta key; the bottom drawer; which-key; the pickers; ease of configuration; one stop shop. Org Mode / Roam / Agenda. The list could go on9</a>.</li> Zed: fast; written in Rust; native AI integration; great communication tooling.</li> </ul> These are some of the features I wished a definitive editor would pack in by default. The single most important of the list - can you tell!? 😜 - is, arguably, DOOM Emacs. Lazyvim also plays a major role, when it comes to features set. We’ll get to them next. </a> Not So Unique, Pal</h3> Nowadays, the most widely used editors all share many features. Influencing and inspiring each others. Thank Ceiling Cat</a> for Open Source! Nothing I’m about to say next is intended as unique to, nor distinguishing for, any particular editor. Helix is, however, the main subject of this whole story; and it’s used as basis of comparison. </a> So Many Checkboxes</h3> While Helix didn’t implement all the desired features, it ticked enough checkboxes to convince me that it was worth sticking with it. To make the switch. To get used to it. Only then, ponder how to fill in the blanks. In no particular order, they all rock: Modal</a> text editor ✅</li> Terminal</a> based ✅</li> Written in Rust</a> ✅</li> Blazingly fast</a> ✅10</a></li> Core IDE features out of the box</a> ✅</li> Great support for languages and tools</a> I care about ✅</li> Minimal configuration</a> and maintenance ✅</li> Great support for a keyboard-only</a> workflow ✅</li> Minimal learning curve and switching costs ✅</li> </ul> To me, these clearly were solid foundations I could build upon, at a later stage. 🍾 🎊 </a> So Many Blanks To Fill In</h3> Alas, early on in the switch, it still felt like Helix missed important bits I was used to. Let’s address the elephant in the room: how was I gonna fare without Vim’s mode and editing approach? Action first vs Selection first? Surely, the filliest elephant to filly-fill. And what about tooling? Helix doesn’t have, to name a few: extensions3</a> nor package managers, a file manager, a terminal emulator, nor git porcelain. What you mean I have to install things externally? Can I easily integrate Lazygit? So on and so forth. The blanks didn’t end there either. What about what’s left from the earlier shortlist? </a> The Meat Of The Tomato</h2> Before discussing how to fill in the blanks and develop the rIDE</code>4</a> concept, let’s first expand on the checkboxes. Hereby grouped by their common characteristics. You should consider each of them as something absolutely indispensable, in this context. </a> Modal and terminal based text editor</h3> Being accustomed to (n)vim, with a long-serving experience, and suffering graphical text editors</a>, the perfect editor had to be both modal and run in my favorite terminal. </a> Written in Rust. Fast and Featureful</h3> I love Rust for personal</a>, technical</a>, and social</a> reasons. You may love Zig (I’m Zig-curious), Go, or C++. For different reasons. That’s absolutely fine. As you’ll see in the next section, when we’ll get to rIDE</code>, I do tend to go all-in but I’m not a maximalist. There are more specific points of the utmost importance - besides, of course, the responsiveness of executables built with it - in wanting the perfect editor to be written in Rust. I.e: its guarantees - like memory safety and error handling - and its language design</a>. These may seem frivolous reasons but there’s a common thread: I’m not willing to cope with entire categories of bugs and annoyances, if I can help it. This leads into the last point: extensions vs core IDE features out of the box</a>. In this case, less is more. Specifically, less dependencies and things that can go wrong or that I have to manage. While no language is immune to supply chain attacks, this to me - I may be wrong, of course - feels like having a smaller attack surface, overall. </a> Support for languages and tools</h3> While Helix bakes in plenty core IDE features by default</a>, to support languages</a> it relies on LSP</a>, Tree-sitter</a>, and external tooling. Such as language servers and, for example, external formatters. This is, of course, common to other editors and pretty much the standard. With a difference: most editors rely on package managers (or extensions) to install them. With Helix, one is required to install external tooling. Initially, this seemed a nuisance and a bug. It soon turned into a welcome feature. This was also the moment where modularity as a plus bubbled up my neural paths. </a> Minimal configuration and maintenance</h3> (n)vim configurations can get out of hand</a> and turn into a PITA. Even an expert11</a> admits not touching it for a year; that must mean something. Distributions like Lazyvim (or DOOM Emacs) may do a great job at handling and hiding them for end users, however, this was still too high maintenance and my main paint point with it. On the other hand, Helix comes with great defaults and only has two main TOML configuration files</a>. One for the editor. One for customizing languages support. Needing to tweak the editor settings or languages support is, pretty much, set and forget. Something that doesn’t happen that often either. Mostly when swapping tools. </a> Support for a keyboard-only workflow</h3> Arguably, this is the most subjective preference of the checkboxes. It does, however, tie in with my difficulties with graphical editors</a>. Moerover, it is a preference shared by most - if not all - terminal text editors users. Nonetheless, this is worth mentioning because Helix’s selection first editing</a> works amazingly for a mouseless workflow. Here’s the kicker: even more so than (n)vim’s action first approach. “HERESY!!!” As greatly stressed in this whole story, I’ve been using (n)vim for the best part of two decades. I enabled Vim Mode everywhere I could. This obviously was a huge blank to fill in. Unlike others, however, I neither think Helix made a bad design choice nor seek out an evil-mode</a>. Like I previously did by choosing DOOM Emacs over vanilla. This time, I wanted to see if it was worth making the switch. To get used to it. I love it. </a> Minimal learning curve and switching costs</h3> The cat is out of the bag. The learning curve and switching costs mainly comprised the editing style: selection → action model</code> vs action → selection model</code>. Other differences were negligible enough. Missing features and tools? Easy to deal with. Moreover, exploring so many editors widened my perspectives. Adjusting to Helix mode, pickers, commands, and shortcuts, was never an issue in the first place. </a> So, What Is rIDE?</h2> By now, it should be clear that rIDE</code> is nothing new under the Sun. The non-IDE concept pre-dates it. What it is, is my own approach to it and a funny - inside joke4</a> - name; and, of course, a tooling set of choice. To wit, there are distros for Helix too. Like Yazelix</a>. This is something I looked up and gave it a miss. I was not going down that path again. No thanks. It would have meant picking a different distro lock-in, configuration-hell, and someone else’s (often maximalist) restrictive choices. Let’s start from what Helix does not feature by design, and compare my choices and differences with Yazelix. The most important is definitely the terminal emulator. This is where everything runs, after all. I made a different choice, for a few key reasons. </a> Ghostty</h3> Most Rust aficionados run with WezTerm</a>. I did to, until I heard about Ghostty</a>. Yazelix (and most people using WezTerm) relies on Zellij</a> to multiplex and resemble an IDE layout to run Helix and other tools. Whatever floats their boats. I did try the Zellij approach to run Helix on my own and it felt like a GUI editor all over again</a>. 😱 Ghostty has many other great qualities that made me prefer it. Above all, it behaves natively on all platforms. Using the same keystrokes and macros on my ZSA Voyager</a> (with Colemak DHm</a>) in all of my terminal based environment is a huge plus. Besides, Ghostty ships with clever split functionality and great tabs management. Final note on Zellij: I’d still use it in lieu of tmux for multiplexing tasks on a daily basis. Until: Ghostty delivers on its promise to revolutionize multiplexing</a> as well. When it will eventually be implemented, this feature will certainly spawn a number of tools and pave the road for wide open possibilities. I look forward to it to have native remote pair programming, sessions sharing, and communication integration. For the time being, I would like to try out Team Type</a> and see how that works out. </a> Fish Shell and Starship</h3> As an ex-system-administrator, the CLI is my preferred habitat</a>. I don’t need a non-POSIX</a> fancy shell trying too hard</a>. I extensively used BASH and Zsh. So, lately, I’ve switched to Fish</a> and Starship</a> for QoL improvements. That’s plenty already. </a> Helix, of Course</h3> This should go without saying, however, it’s worth mentioning for a reason: running a terminal emulator within a terminal text editor (within a terminal multiplexer) within a terminal emulator seems too convoluted and inefficient. Especially if you can just run Helix in a Ghostty tab, and rely on the latter for terminal tabs or splits for any task you’d run in a terminal. And that’s it. Missing feature?! Quite the contrary. </a> Yazi and Lazygit</h3> Let’s address the other two missing features: the file manager and git porcelain. Yazelix name is a portmanteau of Yazi</a> and Helix. Yazi is a great TUI file manager. I do have it installed but rarely use it. I navigate the filesystem in the terminal when I need to. From there I open what’s needed, directly in Helix. Should I need to open more files, I rely on Helix file picker and fuzzy find. Lazygit</a>? I constantly rely on it. All it takes to integrate both with Helix - provided one has previously installed them - is just to add two lines to ~/.config/helix/config.toml</code> to map them as pleased: [keys.normal] C-g = [":new", ":insert-output lazygit", ":buffer-close!", ":redraw"] A-f = [":new", ":insert-output yazi", ":buffer-close!", ":redraw"]</code></pre> Side note: if you prefer Magit</a>, give gitu</a> a try. Wanna use GitUI</a> instead? No problem! Just replace the name of the binary in that specific one liner! Easy peasy! </a> Catppuccin</h3> This is subjective, of course, but all it takes to theme Helix - and all of rIDE</code></a> - is to choose or install a theme and add a one liner to ~/.config/helix/config.toml</code>: theme = "catppuccin_macchiato"</code></pre></a> Kiro CLI</h3> I don’t rely on AI too often and don’t subscribe to vibe coding (at all!), however, when using Zed I tried out AI and it was useful to some extent12</a>. I went from fully skeptic to cautious user and I still agree with most criticisms. Especially with the argument about AI in the hands of a knowledgeable user vs a cheap lazy sod. I do like to use Claude Sonnet</a> with Kiro CLI</a> for small, boring, and repetitive stuff; or when I struggle with an issue for too long and can’t understand it/find my own solution.13</a> </a> Harper and Codebook</h3> For grammar checks and typos avoidance, Harper</a> and Codebook</a> are great. </a> Typst</h3> There’s one last missing desired tool from editors shortlist</a> to talk about: Org Mode</a>. When I used DOOM Emacs as my daily driver, I fell in love with Org Mode. Its features set allows for great documents; especially with LaTeX export</a> to anything. I wanted to migrate all my writings to it and even replace LibreOffice. That’s how powerful it is. When I left DOOM Emacs behind, I switched to Zed and Obsidian</a>. To wit: 1) Obsidian is OK; 2) I’ve since fantasized with the idea to create an office suite with Org Mode as its engine, in Rust. So, I sought out and found some ports and libraries but a) they don’t have features parity and b) I’m not that good (yet?!). And then one day, I stumbled upon Typst</a>. They do a fantastic job indeed. So now, I’m thinking to migrate everything writing to it instead. At the moment I’m only using the web app to manage my CV with it. That being said, Typst engine is written in Rust and it’s Open Source. Anyway, momentarily I’d be content with using Typst with Helix for my writings. Guess what: Helix supports it out of the box or with minimal tweaks. [language-server.harper-ls] command = "harper-ls" args = ["--stdio"] [language-server.codebook] args = ["serve"] command = "codebook-lsp" [language-server.tinymist] command = "tinymist" [[language]] name = "typst" language-servers = ["tinymist", "harper-ls", "codebook"] formatter = { command = "typstyle" } auto-format = true</code></pre></a> Markdown Oxide</h3> While Typst would work great to replace everything writing, I’d still like to rely on Markdown Oxide</a> for PKMS</a>. I’ve been fascinated by Zettelkasten</a> and Org Roam</a>, for a while. However, I never went farther than using The Archive</a> app for my creative writings; then replaced by Obsidian. Mostly because Obsidian offers a mobile app with sync. I’d like to ditch Obsidian in favor of a full Helix experience, though. Helix easily supports Markdown Oxide - install it and add a few lines. To avoid conflicts with my global settings, I rely on Helix local settings and a on demand bespoke Nix Flake</a>: { description = "PKMS environment with Markdown Oxide"; inputs = { nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable"; flake-parts.url = "github:hercules-ci/flake-parts"; }; outputs = inputs@{ flake-parts, nixpkgs, ... }: flake-parts.lib.mkFlake { inherit inputs; } { systems = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ]; perSystem = { config, self', inputs', pkgs, system, ... }: { devShells.default = pkgs.mkShell { name = "oxide-pkms"; buildInputs = with pkgs; [ harper codebook markdown-oxide mpls starship ]; shellHook = '' eval "$(starship init bash)" # Create .helix directory and manage the local languages.toml mkdir -p .helix cat > .helix/languages.toml <<- EOF [language-server.harper-ls] command = "harper-ls" args = ["--stdio"] [language-server.codebook] command = "codebook-lsp" args = ["serve"] [language-server.mpls] command="mpls" args = [ "--browser", "duckduckgo", "--no-auto", "--full-sync", "--enable-emoji", "--enable-footnotes", "--code-style", "catppuccin-macchiato", ] [[language]] name = "markdown" language-servers = ["markdown-oxide", "harper-ls", "codebook", "mpls"] auto-format = true EOF cat <<- EOF PKMS environment with https://oxide.md EOF ''; }; }; }; }</code></pre></a> You Get the Gist</h3> I could go on about Helix languages support and how to configure them, or about adding more tooling to rIDE</code>, but that would be pointless. In sharing all this, I just wanted to counter frequent criticisms and exemplify my idea to give meaning to it all. If you like the concept of a modular IDE, hereby presented as rIDE, the sky is the limit. Whether you do or don’t, I’d like to invite you to try out Helix, if you please: Helix Documentation</a></li> Helix Tutorial</a></li> Helix Golf</a></li> Helix Editor Tutorial Series</a></li> </ul> Thank you so much for your time, I appreciate you. 🍻🚌 A non-exhaustive and non-chronological list of the ones I do remember exploring: Gedit. BBEdit. Notepad++. TextMate. Sublime. Atom. VS Code. Zed. Rust Rover. DOOM Emacs. Possibly more, but probably not worth recalling. ↩</a> ↩2</a> </li> During my explorations, I always missed (n)vim - not the pain points that made me look for others in the first place, though - and always came back to it. Having said that, I really liked some of the features of some of the other editors too. This made me long for an editor that would Frankenstein those into a single package. ↩</a> </li> If you are wondering: yes, Helix will eventually be extensible with plugins</a> - should you need those. However, this would not mean that Helix will distort its core philosophy. ↩</a> ↩2</a> </li> The r</code> in rIDE</code> stands for Regular. It is both an inside joke for Ken</a>’s listeners and a play on the fact that it’s technically not an IDE. Let alone a regular one. ↩</a> ↩2</a> ↩3</a> </li> As opposed to having a humongous (n)vim configuration you have to schedule maintenance for; one would install and configure external tooling independently from Helix. We’ll get into this, when expanding on rIDE, much later. ↩</a> </li> Care to read My Linux Story or: How I Fell in Love with Copyleft and Revolution</a>? ↩</a> </li> There are pretty good arguments to be made. I’ll blog about this too, soon-ish. ↩</a> </li> With custom configurations and / or plugins managers; or distros like Lunarvim, AstroNvim, and Lazyvim. ↩</a> </li> When I switched to DOOM Emacs</a> for a short while, I realized many of the tooling I was used to and loved in Lazyvim (for sake of argument) that the amazing and incredibly prolific folke</a> develops, were concepts inspired from Emacs counterparts. It was revealing. These were the catalysts toward the final step. Please, correct me if I’m mistaken. ↩</a> </li> I cite every JavaScript framework motto mainly as a joke. Anyway, if you hate yourself you could watch this fasterthanlime take</a> instead. ↩</a> </li> I can’t pin point exactly where The Primagen said it. I think it was during his appearance on Lex Fridman</a>. A great watch. I’m not a regular follower of neither but I genuinely appreciated their conversation and felt (not as in pity) for him. I may not agree with most of his takes and only occasionally watch his content for light entertainment - I don’t mean this derogatorily - however, I have plenty respect for The Primagen story. You should make time for it and watch it. ↩</a> </li> When relying on AI, however, I won’t just let it do stuff. When I need help to understand an issue it’s analysis first. In the case of help me code this, I like prompt engineering</a>. ↩</a> </li> Enshittification</a> has rendered search engines, basically, SPAM and scam engines. I begrudgingly find it quicker to ask my contextualized Kiro cli - after some reading of notes and bookmarked articles - to help me understanding an issue at hand. Of course, with a good dose of skepticism and the proverbial pinch of salt. ↩</a> </li> </ol> </section>



Random Word API
2025-10-10T00:00:00+00:00
</span></a>
Premise</h2>
Four years ago, I learned frontend development and I really wanted a career with
Elm</a>1</a></sup>. You can read more about this in
My Rust Story</a> blogpost. At the
time, I made a little demo for junior job interviews. A
Speak and Spell</a>
clone</em>. It used an API</a> that
closed the spigot (presumably costs?). This is to say that, when I needed an
itch to learn restful API development, I had a hole to fill in and somewhere to
start from.</p>
To keep this summary of my learning brief, I’ve only reported the main points to
highlight the reasoning behind the process; rather than using a lengthy bullet
point list. A technical learning summary is available in the
Random Word API repository</a>
README file. I hope you like it as much as I loved learning with this project!
❤️🦀</p>
</span></a>
What this Is</h2>
A restful API</a> built with
Axum</a> in Rust and a personal project to dive
deep into web service development. A simple, straightforward showcase of
technical skill and learning – built to demonstrate capability at job
interviews. Because I really want a career with Rust. As per premise: this API
was primarily designed to support my Speak and Spell clone. Then, it evolved
into a comprehensive learning experience.</p>
</span></a>
Demo It</h2>
You can check the demo</a></del>, browse the
source code</a>, and
run it with Docker</a>.</p>
Note that the free tier I’m using shuts down after some time of inactivity or
stop serving entirely if quota is reached. You may experience slow loading times
or no demo at all. In the latter case, you could run the demo in Docker. My
apologies.</del></p>
</span></a>
KISS</h2>
I knew I needed to devise the same model and response of the OG API, as a
starting point, so I could use my existing app as a real world scenario</em> to
test against. The OG API used a very small response. I treated it as a black box
to reverse engineer. A methodology I find best suited for learning2</a></sup>: it
forces one to think hard</em> while offering a safety net. Thus, I started from the
response I was
already decoding in Elm</a>:</p>
<!-- An actual response from my Random Word API --></span></span>
[</span></span>
  {</span></span>
    "</span>word</span>"</span>:</span> "</span>unknown</span>"</span>,</span></span>
    "</span>definition</span>"</span>:</span> "</span>not known or identified</span>"</span>,</span></span>
    "</span>pronunciation</span>"</span>:</span> "</span>/ʌnˈnoʊn/</span>"</span></span>
  }</span></span>
]</span></span></code></pre></span></a>
The Database</h2>
I chose to use SQLite. It still offered good learning opportunities, both for
the API and Rust tooling, so I was happy with going down this path. In
preparation for the demo, it also meant running one less service (PostgreSQL) I
can’t afford at the moment.</p>
The OG API adopted data in JSON files. That could have been easier to implement,
but what would have given in terms of learning? Moreover, I like SQL. I’ll take
SQL and rely on SQLx</a> guarantees over learning
and using ORMs3</a></sup>, any day of the week!</p>
</span></a>
Beyond the Basics</h2>
The model, simple by design, fulfilled all app’s requirements and it allowed for
a broader learning scope. Once I had an
MVP</a> in place, I sought
to learn and to implement more. I stumbled upon two great resources that
provided guidance and ideas: https://restfulapi.net/</a>
and https://rust-api.dev/</a>. Besides, I recalled that the
OG API, had these weird @swagger</code> comments: “what are these!? - Put a pin on
them</em>”.</p>
All great pointers I wanted to delve deep into. To extend my learning and
improve my API:
middleware pattern</a>,
authentication, authorization,
JWT token</a>,
OWASP</a> OHSP recommendations, and
OpenAPI</a> documentation. Besides
everything else</a>.</p>
</span></a>
Iterate Iterate Iterate</h2>
In an iterative process, I refactored the code and added more features. I.e:
enabling grammatical types endpoints. I future-proofed the API to accommodate
additional languages with minimal efforts. This may seem like a pointless
exercise for an API this simple with no real use, however, it was as valuable to
my learning as best practices and design patterns. It also demonstrates a
forward-thinking attitude and a meticulous approach to projects. I suppose these
are good things. Right!? 🖖🫣</p>
</span></a>
Conclusion</h2>
All things considered, I’m very happy with this learning journey. Starting from
a known with simple requirements was a great choice. Especially for a curious
as a cat always longing to know more</em> person like I am. Moreover, the
simple model</a> opened up a plethora of
possibilities beyond the MVP. Is this enough!?</em> Nah. Can I call myself a
backend developer?</em> This was the first step towards it and I’m way more
confident and knowledgeable than when I started this project. So, final verdict:
HELL YEAH! 🤟</p>
</span></a>
Disclaimers</h2>
I have sometime relied on Claude via
Amazon Q CLI</a> for
boring</em> and repetitive stuff.</p>
I prompt engineered
rustdoc</a>,
utoipa</a> documentation, and both testing
suites.</p>
As my first API, I modeled the MVP on
Code Like a Pro in Rust</a>
API chapter.</p>
</span></a>
Credits</h2>
Translation image by Kawalan</a>
from Noun Project used under CC BY 3.0.</p>




I’m sure you are aware of
Elm influence</a> on the
Rust compiler error messages</a>.
And on many Rust Web</a>, GUI</a>,
TUI</a>,
and App</a> frameworks. ↩</a></p>
</li>

Truth be told, as this is my first API, I also relied on
Code Like a Pro in Rust</a>,
which I had previously studied and modeled my initial design on its API
chapter. ↩</a></p>
</li>

Learning many ORMs, one or more for each language one uses, over just
learning SQL? That also grants you database skills!? Nah. ↩</a></p>
</li>
</ol>
</section>


My Rust Story or: How I Learned to Stop Worrying and Love Rust
2025-08-02T00:00:00+00:00
</span></a>
Premise</h2>
This is a post I’ve been procrastinating for the longest time. Because of an
aversion to what modern exposure</em> dictates mixed with “who would care about
this anyway?!”</em>.</p>
So, why now? As I’m actively pursuing knowledge in Software Engineering with a
focus on idiomatic Rust - hoping to pivot
my career</a> at 50 - I may as well
document my journey. Despite the aforesaid aversion, the very welcoming and
inclusive Rust community</a> makes me feel
like sharing again. Like in the Internet days of yore</em>.</p>
Apologies for taking the long way round. I believe the full story helps
delivering the Kubrickian title metaphor. Having said that, I tried summarizing
every step of the way as much as possible, to keep this reading as brief and as
entertaining as possible.</p>
</span></a>
The very beginning</h2>
I’ll summarize a typical excursus for Gen X’er software engineers:
chronologically apt for the
microcomputers’</a> revolution;
learned programming with BASIC</a>; pursued
STEM education; majored in Computer Science. Except, I didn’t. This is not my
story.</p>
I did have a SEGA SC-3000</a> and, years apart, a
Nintendo NES</a>. My
parents gifted me both</a>, to stop me from
squandering money at the
arcades</a>. I was
an avid coins hunter</em>. As far as gaming was concerned, I was all in with the
microcomputers and the video games revolutions. At times, playing truant to
spend a morning at arcades in the big city. Or at a C64 friend’s</em> to play hot
new ones, from freshly copied cassettes.</p>
I can’t say I met any</em> other aspect of microcomputers with the same enthusiasm.
At least, this is what I can recall, decades later, at the best of my memory
abilities. I do remember, with a high degree of certainty, that this was true
for BASIC, though. I toyed with it and I wasn’t attracted to it. No
transformation on the road to RAMascus.</p>
</span></a>
First fascinations</h2>
Many years later: my first fascinations with programming belong with
AppleScript, Flash</a>, and PHP.
Respectively: 1) opening up my curiosity with a language even I could
understand; 2) for fun animations and websites to feed one more creative alley;
and 3) “what the hell is this trickery on this website! I’ve gotta learn how to
do this!”</em></p>
That said: “the Impostor Syndrome is strong with this one”</em>. So, no dice. Yeah,
nah.</p>
</span></a>
This thing called Linux</h2>
Combine the lack of STEM education1</a></sup> and the
impostor syndrome</a>, and you
can understand why it felt like I had no choice but to learn Linux, systems, and
servers administration instead2</a></sup>. It felt like I could never fill my knowledge
gaps in Software Engineering. Unless I had proper math and Computer Science
education. On the other hand, thanks to Open Source’s nature, night dwelling on
IRC, with logic and hard work; this felt more like a path I could master. I just
needed a server or two.</p>
So, I did. At the end of my hospitality career, I worked as a fishmonger with my
family, while I self-taught Linux and
system administration</a>.
Early morning. Open-air market. Lunch. Shower. Study hard. Hack away. Drop dead.
Rinse and repeat.</p>
</span></a>
Why don’t you listen?</h2>
Right at the very beginning of my IT career, I did Windows Help Desk. The irony.
I hadn’t done all that hard work to work with Windows. I started looking around.
I did my first job interview. It could have proven revealing. Life changing, in
hindsight. Because of one particular hypothetical scenario. I can’t recall the
exact details, and it went something along these lines (this was some time
before the iPhone revolution):</p>

Suppose you launch a cellphone. Would you like to build it or to make it
work?</em></p>
</blockquote>
Being an HSP</a> - genuinely interested in most things and
longing to delve deep into everything</em> - I answered “both”</em>, trying to reason
holistically. Alas, I didn’t grok the true nature of this hypothetical. Nor the
subtle guidance they were kindly offering. Eventually, they forced me to choose.
So, I chose “make it work”</em> over “build it”</em>. They had tried to make me
realize I was better disposed toward software engineering.</p>
That said: “the Impostor Syndrome is strong with this one”</em>. So, no dice. Yeah,
nah.</p>
</span></a>
A Linux career</h2>
Thus, I kept my job with the company that first hired me. I asked for a Linux
job and, when the Windows Help Desk contract expired, I obtained my first junior
position. Nothing too fancy, but it was a good start. In the years that
followed, I worked at great companies and loved each experience, both in Milan,
Italy; and in Bristol, UK.</p>
In a nutshell, it never felt completely fulfilling. I experienced stalling and
burn out. Twice. Both times I went on to attempt pursuing a creative career as
professional Sound Designer. Because pursuing a musician career, despite
interest from indie labels and moderate success, filled all but one of
Ikigai</a>’s aspects. Take a guess.3</a></sup></p>


    
</div>

Besides, “the Impostor Syndrome is strong with this one”</em>. I don’t know music
theory</em>.</p>
</span></a>
Giving back to Open Source</h2>
Since I had been initially drawn into - and loved - Open Source for its
revolutionary ethos, philosophy, and philanthropy; I reached a point where I
wanted to give back with more. More than what I was already doing with activism
and education about the importance of Copyleft. I wanted to contribute code to
open source projects.</p>
I had to start from somewhere. I needed learning BASH for my system
administrator position. So, I made a
wrapper for a Dell firmware upgrade tool</a>.
At the time, I was close with Ruphy and I started fantasizing</em> about making it
a KDE app. I asked for some guidance. That would have meant learning C++ and Qt.
That was short-lived. Perhaps, I had to slow down and learn something within my
abilities. Some time later, I tried learning Ruby. After even some more time, I
learned some Python4</a></sup>.</p>
That said: “the Impostor Syndrome is strong with this one”</em>. So, no dice. Yeah,
nah.</p>
</span></a>
Learning web development</h2>
After the second burn out and attempt at professional sound design, I decided to
go back to IT. As a web developer this time. Since I love crafting UIs, UXs, and
websites. I’ve learned HTML, CSS, SASS, and some JavaScript</em>5</a></sup>. Until I fell
in love with Elm</a>6</a></sup>.</p>
While I appreciated being able to code my own ideas and websites, I felt
unsatisfied and disillusioned with JavaScript. Plenty of console errors and
warnings were not only widely accepted, this was going to be the norm. That I
had to ignore it and live with this?! That didn’t sit right with me. Perhaps,
web dev is not for me. After all.</em></p>
On the other hand, Elm has great design baked in</em>. Elm makes all the right
choices</em>. Elm has a great community and amazing tooling. Elm made me feel like I
could code, for the first time in my life</strong>. With Elm, my brain finally
clicked the right way. Eureka!</p>
</span></a>
Lowest common denominator</h2>
Since I had fallen in love with Elm and Haskell, I yearned a functional
programming job. Alas, my</em> career with Elm or Haskell wasn’t going to be
feasible. Elm still required JavaScript. Haskell? I lacked too much foundational
knowledge. I wished someone had told me about functional programming way
sooner</em>. THAT I would have studied.</p>
What now?! I still loved doing UIs and UXs. I had a couple of apps ideas to
scratch. I had been Swift-curious</em> since its announcement at WWDC 14. I enjoyed
Swift7</a></sup>, like most languages before it, up to that</strong> certain point:
Object-Oriented Programming.</p>
My brain just can’t cope with OOP. I’m not wired that way. I cannot think that
way. I understand OOP selling points</em> theoretically, however, it feels very
unnatural to me. What I loved about Elm, Haskell, and
(purely) functional programming</a>,
among many other qualities, was the separation of concerns between data and
functions.</p>
That said, I still felt very stupid for not getting OOP</em>, though. I was never
going to be a software developer now, for sure. Too stupid for OOP. Too late and
uneducated for FP.</p>
</span></a>
Software development is not for me</h2>
Combine the story thus far laid out with the fact</em> that OOP was the only way
to do software</em> and you can see why I was about to give it all up. Ready to be
content with a dead-end job, poor but sexy</em>, to stay afloat and pursue music
and creativity. Ikigai?</p>
Going back to system administration wasn’t an option, at this time. I was too
severely, and repeatedly, burned out. Besides, this all certified</em> that I
wasn’t good enough for software development. Repeated failed attempts at a
creative career, on top of it all.</p>
Before throwing the towel, I decided to explore Rust and see what the hype</em>
around it was all about. Up to this point I had avoided it because of a narrow
and uninformed view: low-level programming was definitely not for me. I had no
education for this.</em></p>
</span></a>
Software engineering with Rust</h2>
In a short exploratory phase, I briefly familiarized with the language, I
learned about the community, the tooling, the design choices, and I fell in
love. Rust felt like the language I had been dreaming about for so long; from
technical to
social aspects</a>.</p>
It combined what I loved about functional programming with what I
loved about Swift</a>.
It retained the
good bits of OOP and excluded the aspects I hated about it</a>.
It offered a complete ecosystem</a> allowing
great DX, and to avoid pointless bugs and frictions. Moreover, Rust’s
design philosophy</a>
aligned with what I always held high in a list of fundamental characteristics.
Rust is way more</strong> than system programming!!</em></p>
Rust - like Elm before it - reinvigorated me8</a></sup>. Profoundly. This time around,
I’m going to learn more than yet another programming language</em>, though. I’m
gonna study the fundamentals. I’m going to make up for my deficiencies as much
as humanly and reasonably possible. To be(come) a good Software Engineer, with a
focus on Rust.</p>


    
</div>

Now, could it be viable professionally? Whilst the market is momentarily
unfavorable</em> to a beginner, Rust enables developing for a high number of
technologies - including full stack web and apps - and it’s here to stay. Rust
is growing steadily and has great momentum. Companies adoption is growing by the
day. Thus, I decided to bet my future on it. Fingers crossed on the market
opening up to a 50 years old junior. 🤞</p>
</span></a>
Conclusions</h2>
I’m not sure there is a moral to this epic or if it is more of a cautionary
tale. I shared a very personal journey -
a long excursus</a> -
hoping its details can help someone going through the same kind of
impostor-driven life</em>. You’d be the judge. Be kind. Please. I’m doing my best.
Every day. Will time tell a good story</em> when it’s all said and done?</p>
Having said that, I’d like to end with a constructive note. Sharing three books
that, in my humble opinion, would make for a great beginner’s path to solid
foundations. Hoping these books would help the reader, and whomever is curious
and willing to learn Rust but is still hesitating. Like I was. They are,
however, only the beginning.</p>
</span></a>
The must first read</h3>
There are many great resources for learning Rust. Great books9</a></sup>. Exercises,
bloggers, and diverse platforms10</a></sup>. If one doesn’t know where to start, they
should start from the top: Rust’s
learning page</a>. Definitely with
The Book</a> - the must first read</strong>.</p>
</span></a>
The most common paths</h3>
The two most common paths - often recommended by the community helping out
newcomers seeking advice after learning Rust basics with The Book</em> - are:</p>

The Rust for Rustaceans</a> Path. For anyone
willing to delve deeper into Rust.</li>
The Zero to Production</a> Path. For anyone wanting
to learn Rust backend.</li>
</ol>
Great recommendations, each with its own merits. I admire both
Jon</a> and
Luca</a>. Luca was immensely kind</strong> to me. Zero2Prod,
however, didn’t work for me.11</a></sup> I haven’t got around reading/studying Rust
for Rustaceans</em> yet. I want to remedy that, soon.</p>
</span></a>
The beginner recommends</h3>
Without any further ado, these are the two books12</a></sup> that - after learning
Rust basics with The Book</em> - in my humble opinion, make for a great beginner’s
path to a solid and idiomatic foundation. On which to build upon any career path
they may choose.</p>

Code Like a Pro in Rust</a>:
delve deeper into data structures, essential tooling, testing, memory
management, async, optimization, and project management.</li>
Idiomatic Rust</a>: delve deeper
into traits and generics. Be up to speed with idioms, best practices, design
patterns, anti-patterns, macros; and much more.</li>
</ol>
Both from Brenden Matthews</a>. I thoroughly enjoyed his
writing and teaching style.</p>
</span></a>
Bonus book (Z2P Alternative)</h3>
Rust Servers, Services, and Apps</a>:
delve deep into RESTful API design and learn to implement it with Actix-web.
Understand concurrency and parallelism. Truly understand async</code> Rust with a
practical re-implementation of its mechanisms.</p>
If you made it this far, thank you for your time.</p>




In a nutshell: I didn’t like studying when I was a teen. Despite my
professors strongly recommended my parents for me to take this or that
institute and study path. All I wanted: a job for independence and to get
out on my own. ↩</a></p>
</li>

Care to read
My Linux Story or: How I Fell in Love with Copyleft and Revolution</em></a>? ↩</a></p>
</li>

To drive a point, I’ve used a famous Venn diagram. Ikigai is more of a
concept. Image Source:
https://www.linkedin.com/pulse/why-you-shouldnt-use-ikigai-venn-diagram-saori-okada/</a> ↩</a></p>
</li>

I strongly recommend Allen B. Downey free books for anyone wanting to learn
the basics of development with Python (and Python of course):
https://greenteapress.com/wp/</a> ↩</a></p>
</li>

I strongly recommend Academind for anything Web Developer learning:
https://www.academind.com/</a> ↩</a></p>
</li>

I’m sure you are aware of
Elm influence</a> on the
Rust compiler error messages</a>.
And on many Rust Web</a>, GUI</a>,
TUI</a>,
and App</a> frameworks. ↩</a></p>
</li>

I strongly recommend Hacking With Swift</em>:
https://www.hackingwithswift.com/</a> ↩</a></p>
</li>

When I fell in love with
Rust design</a>, it made me feel like
I didn’t waste time in learning other languages. Although each of them
seemed like a failed attempt at learning how to code</em>, they all gave me
something. Nothing you learn is wasted. ↩</a></p>
</li>

There are a couple of books lists I have saved, however, since I have not
read nor studied most of the books, I am sharing them in a footnote JFYI and
NOT</strong> as recommendations:</p>

https://lborb.github.io/book/</a></li>
https://github.com/sger/RustBooks</a></li>
</ul>
 ↩</a></li>

While there are great YouTubers and tutorials, they can be very subjective
and meet different learning style and preferences. Far too many to write
about them here. Not that books are exempt from subjectivity, however, we
are discussing my own book preferences here. Thus, making is a more focused
target. ↩</a></p>
</li>

Besides not clicking with the tutroial code dump style, How to Code it</em>
makes great arguments</a>
I wouldn’t make in a million years. I agree with them. ↩</a></p>
</li>

Since finding out about Manning Publications, with
Elm in Action</a> by
Richard Feldman</a> - another great person I
admire - they are the first IT book resource I rely upon. So far, so good.
Each book I studied has proven a great resource. ↩</a></p>
</li>
</ol>
</section>


My Linux Story or: How I Fell in Love with Copyleft and Revolution
2025-07-14T00:00:00+00:00
I’ll write about this soon-ish. Placeholder blogpost. Check back soon.</p>


I don't post much. Follow me on the Fediverse.
2024-08-07T00:00:00+00:00
Hi!</p>
This is my first post just to notify you that I don’t post much here. If you
would like to follow or stay up to date with my shenanigans,
@andreacfromtheapp@c.im</a> is the place. The
Fediverse</a> is decentralized and
more human. More socials in the footer.</p>
</span></a>
Projects And Apps</h2>
My projects and apps have their own dedicated blogpost. Check the projects
section!</p>
🍻🚌</p>


Freesound Credits
2024-08-06T00:00:00+00:00
A command line utility to help you credit Freesound</a>
samples for any given project.</p>
</span></a>
Rationale</h2>
Giving credits in the Creative Commons</a> community
is often the sole requirement to freely use samples in your creations. This tool
helps you abide to Copyleft</a> and credit
the generous artists whom contribute to Freesound</a>,
helping your creativity.</p>
Giving credits may have been a cumbersome and tedious process you begrudged.
This may have been stopping you from giving credits altogether. Not anymore!</p>
It takes seconds now! How? Instructions on
Freesound Credits</a>
README file.</p>
</span></a>
Credits</h2>
Sound Wave image by Dwi Ridwanto</a>
from Noun Project used under CC BY 3.0.</p>