Hi there,
I've been in the programming world since around 2007. Focusing mainly on JavaScript/TypeScript on the frontend side (Next.js, React, React Native, Node.js in various runtimes), and TypeScript and Go on the backend. Occasionally, I work with Python or Rust when the situation calls for it.
I'm currently open to work.
In recent years, there's been a surge in vibe-coding and automated AI usage. I take a different approach. I write code like an artist preparing brushes, paint, and canvas. Not just to check off tasks, but to build something with real structure, meaning, and readability. I'm open to using AI for exploration and analysis—especially prompt engineering—but when it comes to composing core code, I prefer slow, mindful, and measured craftsmanship.
My work in prompt engineering runs deep too. I draw from semiotics, linguistics, and constructed languages to design small notation systems that help with annotation and thinking. One example is a note-taking language I designed that can transform text meaning into syntactic or symbolic form. Some of these experiments were supported by AI models, which I used as sparring partners for ideas.
Maybe one day I'll write about those in more detail—blog essays or public notes. For now, I want to share several projects I'm working on or have completed, so you can get a sense of how I think, work, and build things from scratch.
GitHub: github.com/raitucarp/gomix
Status: WIP (v0.0.3x)
I want the experience of writing frontend in Go to feel natural and integrated, without constant context switching. Go's built-in html/template doesn't quite fit for me. React, on the other hand, removes the boundaries between HTML, CSS, and JavaScript through JSX—and that's not just technically elegant, it's semantically aligned.
So the question was: Can that approach work in the Go ecosystem?
That's what gomix is about. It's primarily focused on DX engineering. I'm building a UI syntax for Go that's consistent, pleasant to work with, and reduces mental overhead when moving between view representation and logic. There's inspiration from Zed editor's gpui and component systems like ChakraUI.
Long-term goal: UI rendering for HTML, WebView, and desktop-native all through the same syntactic language.
The process is slow and ongoing because this project needs a solid foundation.
GitHub: github.com/raitucarp/epub
Status: Ready for use, prior to official v1.0.0 release
This one came from a different place. I wanted to translate the W3C EPUB technical standard into a truly functional Go implementation. It's not just reading code examples—I had to actually understand the specification and reassemble each part into functions that people could reasonably use.
It started as a personal need. I was building an EPUB reader application with a fairly unconventional UI approach, and I needed a solid foundational library. The existing Go EPUB libraries at the time didn't fit what I needed.
The library works now. There's room for refinement, but the foundation for reading and writing EPUB is solid and usable.
GitHub: github.com/raitucarp/openlibrary-go
Status: Pre-release (v0.1.1)
While working on the EPUB library, I kept running into incomplete or broken metadata in some EPUB files. The W3C specification doesn't solve this—it just defines the format, not the content. So where does the missing information come from?
Third-party APIs. I built a Go wrapper for the OpenLibrary API. Much of their documentation is implied rather than explicit, so I had to build my own understanding of their data patterns.
The next step is to let OpenLibrary know this library exists as an unofficial option.
Active at various points between 2020–2024:
- raitui: GUI framework based on raylib for Go. Halted due to text rendering and shader limitations.
- wordxkit: A web-based dictionary application built on WordNet, with embeddings, vector database, GraphQL, PostgreSQL, pattern-based lexicon, and semantic play.
- leksikon: A localized Indonesian version of wordxkit using Neo4J and a large lexicon dataset.
- HN reader: Several desktop applications experimenting with real-time reactivity.
- scrolls: A reading app with a structural reading approach, unreleased.
- And many more (at least 10+ projects)
Most of these weren't published for various reasons—technical and otherwise. But they each shaped how I think about systems, data representation, and reading as a cognitive activity.
If you're a recruiter or part of a team, I'm open to conversation. I can walk you through my working approach, how I make design decisions, and what I've learned from projects that didn't see public release.
Outside of programming, I read a lot of philosophy, science fiction, and experimental work. I'm something of a digital bibliophile too. I still have ambitions to write books and draw.
Thanks for reading this far. I'd love to hear from you—technical or conceptual conversations both welcome.