Show HN: I rebuilt the only parts of my IDE I use, in Rust, over a weekend
github.comI don't know Rust.
Friday after work I realised that 90% of my IDE time now is just the commit/diff view — and even good IDEs feel heavy for that.
So over the weekend I built a dedicated native tool for just that. Kyde is a macOS git commit + diff editor with one goal: be fast, do Git well.
I'm curious whether anyone else mostly opens their IDE for git operations these days.
It's open source, and there's a signed app in Releases.
Pretty good, and I think I could definitely use it. One thing that I immediately missed is syntax coloring. For Markdown and other known extensions. I am sure it will be trivial to add it.
Another possible useful feature would be to add "open in system" or similar in the right-click menu for a file, to open the file with whatever application the OS has bound to it.
EDIT: I see there's a plugin thing that when clicked installs the highlighting. Cool!
EDIT: Also missing is selectively staging lines of a changed file to commit. I would actually change the behaviour of the Git UI so that it matches the VSCode one, to reduce the learning curve. Most people already know how that works, no need to make them learn a new UX.
Yep of course, Syntax colouring will come. And it was intentionally left out first couple days due to critical path for me, I imagine I'll add intelisense too but I'm glad I decided to make language support installable - goal is fast + great Git.
>open in system:
Isn't that reveal in finder? I did add this if so :).
> selectively staging lines
Oh I've never actually done this! But I think I understand, so just pushing a few lines in a changed file. Fun! I've always used a different IDE where I don't think that's a thing. I'll add an issue.
Forced dark theme -- please don't punish me for having astigmatism--can't do dark mode
Haha fair enough, my colleague always says the same! Actually the theme's already separated into a JSON file so this will be trivial.
not to mention that light themes produce less eye fatigue and strain. but who cares about that
And dark themes hide my floaters and are easier on my old eyes.
There is not one singular answer for everybody.
Wouldn't it be the opposite? Light themes cause more blue light and thus increasing eye fatigue.
Oh man, that's a great idea. Well done.
Cheers! I'll be improving it as I use it every day, refusing to open old IDE haha.
What might you build when you let Claude take care of commits? :-)
A garden.
I like how it looks.
But the terminal already has excellent diff and commit tools.
Fair enough. I always switch to my IDE for a big branch, actually that's why I never switched VSCode, I liked my original IDEs Git UI. But maybe that's just muscle memory using the same IDE from Java to web over the years.
I'm curious, what's some user-friendly terminal based tool to say stage only a couple of discontiguous lines from changes in a single file to commit in Git?
I think I've tried the git command line "interactive" mode, and is really painful. I find myself going to an IDE, selecting the line and right-clicking + "stage selected ranges" to achieve that.
Lazygit is incredibly capable for everything (including this). I don't touch the git cli anymore.
Lazygit for a standalone program, or magit for an emacs package (some people use a different editor and just treat emacs+magit as a dedicated git frontend).
I'm with the other comments here, but what's the deal with the '120 fps scrolling' blah blah blah? This clearly isn't a game or movie -- why are we talking about frames?
Hey, I should have maybe made this more clear - I definitely don't care that it's 120fps more that the frame rate doesn't drop and we aren't seeing freezes. Initially the project was, with large files, with syntax highlighting especially or switching very large branches. The built-in FPS counter actually proved really helpful in observing these.
Just to add to this, I also observed in some of these cases the frame rate dropped in a non-transient way on that it remained low. I think this should be covered by more of a soak test but it has still been very useful for me to see a constant fps.
What models and tools did you use to create this?
What were your biggest challenges in making this?
> What models and tools did you use to create this?
Opus 4.8.
> What were your biggest challenges in making this?
UI that had to react due to things such as the window size changing, specifically with horizontal and vertical scrolling and getting it to work with mouse drag + text selection via shift and arrow keys. It was a lot of back and forth. In the end after getting it working for the main editor I (Claude) turned it into a with_scrollbars decorator method.
Knowing to splitting god functions before they sprawl / emphasising regression tests, and specifically frame rate regression has helped me a lot so far I think.
Would you mind supporting Intel Macs?
Yep sure I'll take a look at lunch, this is much easier than Windows / Linux since I can actually QA it.
Done, https://github.com/kyle-ssg/kyde/releases/tag/kyde-v1.2.0
UI looks great
Oh thanks that's made my day haha!
This is basically what the agentic apps do already right? Like Codex, Claude Desktop, Copilot etc. Except with those I can also write commands to the AI as well as review their output all in one app rather than multiple.
Hey, by this do you mean viewing a diff of before and after? If so I get what you mean, but given how important the review is pre-PR I do always come back to IDE.
Yes they have a diff view, both of each change and of each commit as well as the overall PR.
This is amazing and I will use this! Does it support git submodules? I like how VSCode divides changes into buckets across all git repos in current workspace, I can commit each separately from one sidebar.
Hey! That's actually something I haven't checked, none of my active projects use them. I expect it won't break but I haven't designed the diff to account for that. I will take a look though it's a great point.
Great. Otherwise I will find time to send a PR sometime.
<3
You didn't wrote this. Generating code from AI is NOT programming.
OP doesn't say they wrote it. They say they built it. This seems to be the word that people have settled on to describe having the llm put something together according to your requirements.
great idea! this use case is the only reason left why I start VS codium.
Thanks! Yep same with my IDE.
The code is...quite bad...
It seems the AI coding is just the software version of Temu. Lots of cheap stuff but none of it is very good and it breaks pretty easily when you try to do anything outside of a very very small list of uses.
Hey, have you got any fundamental examples of why? I get pessimism towards AI, I've battled against using it after programming for so long, but I do intend to keep building on this and I'd genuinely appreciate things you saw that are icebergs.
Ignore the people being negative about vibe-coding. These are either boomers or just insecure/afraid for their own jobs.
bro rly could have just made a custom nvim setup
Hey! I don't think I'd want to do that (maybe you're joking). I'm going to have a lot more control over this, how familiar it is to my current setup and things such as a local history that I can add the hunk diff view to.
Also it's just quite fun.
Actual title: I had Claude code up a diff tool in Rust over the weekend
My guess is this made it to the front page solely from the Rust boost.
> I had Claude code up
What's the difference?
The difference is that the resulting software is useless, buggy, unpolished, will only be used by the person who prompted it and only for about three days before they get tired of it, and that nothing was learned.
That's what I'm not getting about these kinds of posts. What is the point of sharing this? It's just a bunch of nothing.
It's still software. It's on frontpage because people (like me) found it a good starting point for things we wanted ourselves but were too lazy to prompt.
Hey, actually my goal is to stop using my IDE, it'll be one less subscription for me. So I won't get tired of this, I plan on using it daily. I've spent quite a few years obsessing over software quality so I won't accept unpolished and buggy!
Everyone who vibe codes something over the weekend thinks that their vibe coded software will be the greatest thing since sliced bread. Then they realise that as they continue prompting, it takes disproportionately large amounts of effort to see any progress as program complexity rises and the token predictor begins tripping over itself more and more. At least use it daily for a month rather than saying you plan to use it, then try showing it. If you could actually get through a month of using and prompting on the project without getting tired of it, that would already put you ahead of 99.9999% of vibe-coded projects. As it is, literally anyone could prompt for this over a weekend, so what value does showing this have?
I do agree with some of this principle, if I sat blasting prompts with all the things I could think of, of course it won't end well. Strong regression tests and good patterns are needed.
RE a month usage, that is a good idea, I will use it for a month and do a more long-form post.
I've been using it since I started building it, and have not touched my IDE, thats the goal. All commits to the repository have been made via the tool itself.
I think you are just afraid for your job.
Not in the least. If an IDE worth using could be built in two days, we would have seen one with widespread adoption months ago. There is a world of room to improve on existing IDEs, but nobody has done it yet. The only real attempt we've seen is a couple of forks of VSCode adding a chatbot prompt to the UI. What I am is sick of Show HN having become complete trash with nobody putting effort into anything, displacing all the cool little projects that people used to make.
To some, it's less authentic. In my mind, it's like "building" a house, when the truth it, you orchestrated contractors who did the actual work. A different set of skills, not necessarily less impressive, but probably is depending on the audience. (In my example, you wouldn't want to shoulder way into a group of tradesmen and talk about your building prowess)
You don't know the difference between "I painted a picture" and "I asked Samantha to paint this picture"?
Are companies allowed to make “Show HN” posts?
How is this different than X company saying we build Y, when they literally paid people to do it for them?
Notice how you said "we" instead of "I". If some CEO posted "Hey, 'I' made this neat tool!" and took credit for the work of the staff that would be a more accurate comparison.
That's just too funny, even the README is entirely vibe-coded and the label under the image doesn't describe AT ALL the content of the image:
> ~120fps scrolling a 37k-line package-lock.json — viewport virtualization + off-thread highlighting.
When it's a static PNG of an extremely small diff.
I'm flagging the post as spam, that's what it is.
Hey, actually there's a script that generates the screenshots so that I don't have to adjust them every time the UI changes. I do get 120fps with a 37k line package-lock, try it yourself if you don't believe me.
The primary value of IDEs in the agentic era are: debugging, code review (with good diffing), and management of the agent’s context. I also use mine for browsing databases, but not everyone does that.
You seem to have one of those three. I’m not sure what your coding background is, but debuggers/profilers are incredibly useful and important, and it’s essentially malpractice for a developer never to use them.
Hey! I'm a web and mobile developer for past 12 years and have wrote quite a lot of code over the years (github for receipts). I actually even written a mobile application profiler, it's on GitHub.
Debugging and profiling has always been outside of the IDE for me, except when I started out as a Java Developer.
My point was not at all to accuse you of using the wrong tools, but rather to point out that your rebuilt IDE is missing something very valuable (combining the debugging and editing experience).
I don't and have never understood why someone spins up a full-weight IDE and then not used that same GUI to manage their debugger, since you get a lot of added benefits from that (being able to copy/paste from the editor to code evaluation/REPL for example).
I wasn't trying to criticize this early work at all. It looks like a fun and promising project!
Hey, no worries, I don't think you were criticising! I guess this IDE was prominently started for me, and I wouldn't use an internal debugger vs debugging in Chrome for example. I think if I added one, the debugger would be opt-in/installable rather than always bundled.
It is a little crazy to accuse people not using the dev tools you like of malpractice.
"Debugger" is not just a "dev tool I like." It's the only way to see what a program is doing while it's doing it, unless you're just writing to your console and hoping you captured enough state with your write statements.
I understand there are people who haven't used debuggers before and don't know what they're missing out on, but there's no excuse for that anymore because it's become much easier to set them up and use them.
Your response doesn't do a lot to convince me that "debugger" is anything more than a dev tool you like. It is not the only way to see what a program is doing while it's doing it -- there are plenty of other effective ways. I have encountered many bugs where a debugger wouldn't have been a help at all.
To be totally honest, having such an absolutist view makes you look inexperienced -- and accusing people who disagree of "malpractice" is absurd.
Woah woah, temper down the assertion my friend!
Profiling is a tool meant for processes that relate to performance, or hot spots. Debuggers when integrated well[1], are great tools but compete with print based debugging which is a much more general skill one uses and needs to learn.
Let's reserve malpraxis considerations for writing code without any true thought given for security, privacy, accessibility and human rights affected.
[1] and I don't like the interface of any of the debuggers I used. Except maybe in ghci, if I had the patience to script a Tcl/Tk frontend one day.
Print-based debugging is worse in every way and also the wrong tool for the job.
You should absolutely be adding logging, including optional verbose logs, to code. It’s a form of self-documentation and a major convenience during maintenance.
But it doesn’t compete with or replace using a real debugger, which allows you to step through your stack at any point and see potentially many megabytes of state that you literally can’t consume from a text console.
Such a cringy and unpleasant statement... OP is smart to adjust to change. I have hand-written software for the past 30 years, and the moment I stop using my IDE, you’d tell me don’t know what I am doing?? Dude, I probably was writing assembly code by hand when there were no IDEs and you were still trying to figure out the taste of Play-Doh. Some people really need to put their head in the right place.
This response is so strange and unrelated to what I wrote, it feels like you're not even responding to me in the first place.
> OP is smart to adjust to change
When did I tell OP not to change? My comment was about how my own workflow has changed radically in the last couple of years.
> the moment I stop using my IDE, you’d tell me don’t know what I am doing??
What? I didn't do anything of the sort.
> Dude, I probably was writing assembly code by hand when there were no IDEs and you were still trying to figure out the taste of Play-Doh
This is incredibly childish. If you really are as old as you imply, the cringe is all you, friend.
I got out of the habit of leaning on debuggers with first making sure I'm not lacking in logging. I can't remember the last time I actually needed to set a break point.
>but debuggers/profilers are incredibly useful and important, and it’s essentially malpractice for a developer never to use them.
Just wait for the moment you need to write code for an embedded platform that doesn't have a debugging mechanism.
I've been programming for more than 30 years. Funnily, I used to use debuggers A LOT (in Borland Turbo C++ DOS "IDE" times, Visual Basic, Eclipse, Netbeans, Adobe Flash Builder, etc). But nowadays I seldomly use the debugger, if at all.
> Just wait for the moment you need to write code for an embedded platform that doesn't have a debugging mechanism.
Very close to 0% of programmers on this site are doing this. The vast majority are writing JavaScript/TypeScript, Python, or some other high-level language and targeting web platforms.
> But nowadays I seldomly use the debugger, if at all.
That might be fine for you and your use cases, but it's not fine for CRUD app developers who are essentially passing and mutating data around databases and state machines.
>That might be fine for you and your use cases, but it's not fine for CRUD app developers who are essentially passing and mutating data around databases and state machines.
I've done a mixed bag of these, but yep ultimately mainly just CRUD now days and yep that's all we're doing. It's what a lot of us are doing!
Haha I loved Netbeans, and in college(UK not US) got to the point when I taught actionscript instead of the teacher.
what kind of noob uses debugger from within their IDE?
How else do you use it? Unless you’re talking about a browser debugger, which is the same UX that I’m talking about.
I’m referring to server-side work when I say to use a debugger in the IDE, not something targeting the browser.
via terminal
Why would you choose to have the ai use a language you don't understand? Isn't this basically admitting you had nothing to do with this project and anyone else could pay an ai to make the same thing easily?
Is this something you expect other people to use?
Are you planning to maintain this?
Are you making a point about ai capabilities?
Is this just a joke?
I guess I don't really understand the point of posts like this.
I'm making a point about IDEs, I think their usefulness is declining. No, I do not expect other people to use this, but they can and I will.
> Isn't this basically admitting you had nothing to do with this project
No. They had nothing to do with the code. The project is not only the code.
> and anyone else could pay an ai to make the same thing easily?
This assumes that the difficult part is typing code, but in reality the most difficult part is to know what to build, specify it, evaluate and iterate on it.
If it were truly as easy as asking an AI once, then everyone would already be shipping successful products daily.
AI just lowers the bar to entry.
> If it were truly as easy as asking an AI once, then everyone would already be shipping successful products daily. AI just lowers the bar to entry.
I could not agree more! I think there's a finite group of people who have a strong software engineering background who really know the rewarding pain and are able to embrace AI in an optimistic way.
Yes!
Ignore all the negative comments, this is really cool. Looks a lot like a JetBrains IDE. One suggestion is to integrate claude code as a code editing window tab rather than a terminal window. If you'd like checkout https://github.com/sajithdilshan/agent-cli-plugin on how I did it for JetBrains IDEs as a plugin