Howdy HN, we built Claudette as an open-source desktop companion for Claude Code.
Run multiple Claude Code agents in parallel, each in its own git worktree, each with its own session and terminal. Claudette also supprots remote sessions run on another machine over an encrypted WebSocket connection. Full editor support means you can stay in one app for chat, diffs, terminal, and editor.
So why did we build Claudette? We liked Conductor and similar tools but didn't love that they weren't open source or required a login to use. So we set out to fill that gap, and address a few other things we wanted along the way.
We're continuing to add features with recent additions being Windows support, OpenPeon sound pack integration (300+ packs to pick from, Alan Rickman being my favorite), Monaco integrate for full editor support, and more.
We've got some really exciting features baking right now that should be dropping soon.
Using a lot of Typescript and Python in my current role and I find myself missing that part of Elixir. Ecosystems are night and day though. For what we're doing we'd have to write far too many libraries ourselves in Elixir and don't have the time right now.
Pasta is a cross-platform system tray application that converts clipboard content into simulated keyboard input, bridging the gap for applications that don't support direct clipboard pasting.
Created to solve a problem we've all run into before but there wasn't anything that did what we needed.
If you consider how this all works the issue becomes rather obvious: Your content is compiled into Elixir module attributes as strings at build time. The more content you have, the larger these modules become and the more data gets compiled into your application. For a small blog with a small number of posts this would work fine. In our case the ever growing list of lessons, posts, and translations results in a lot of content.
This creates two main pain points: First, compilation times have become painfully slow as the compiler has to process all that content into module attributes on every build. Second, on more than one occasion our Fly.io release has failed due to size and memory usage during deployment, thankfully retries have worked and gotten us on our way.
The trade-off here is that NimblePublisher's strength, everything pre-compiled for fast serving, becomes its weakness when you're dealing with substantial content volumes.
When we pull the trigger on a migration away from NimblePublisher we'll be sure to publish an updated blog post.
It is the same water but it's also fairly common for people to use harsh chemicals and toilet tablets to keep them clean and smelling fresh. Those would not be so good for your pet.
Elixir is only "better" because of the syntax and some of the developer experience. Anything good about Elixir is present in Erlang and likely originated there.
Well you yourself mentioned being hesitant to add a library that could likely help you solely based on it being in Erlang.
Erlang has many useful libraries, it's been around far longer. If everything has to be wrapped by Elixir to be useful, well that seems like a pretty significant limitation.
Learning Erlang and understanding it is an important skill for any serious Elixir developer. Erlang has been around longer and has a larger set of available tools, it's what Elixir piggybacks on, and we can't just rewrite everything in Elixir.
I love Elixir but I'm curious about your question: why not use Erlang for this? What would using Elixir do for this that can't be achieved with Erlang?
I'm working with a couple other contributors to Elixir School on new material that will go into more detail with regards to designing more involved applications.
I agree that resource is sorely missing from the Elixir community.