nu11ptr

Have they made a way to move those tiny icons in the lower left (aka "activity bar") to larger icons on the upper left like VsCode? As it stands, I can barely see them on my 4K screen and selecting them with a mouse cursor is like a pixel hunting contest. No go for me until they offer a way to change that. Beyond that it seems like a decent editor, but if I can't switch modes back and forth, that is a deal breaker.

UPDATE: Looks like they haven't yet, bummer, and doesn't seem to have much traction either. They redirect to discord, but AFAIK that doesn't have a way to make a feature request directly?

https://github.com/zed-industries/zed/discussions/47593

https://github.com/zed-industries/zed/discussions/48098

https://github.com/zed-industries/zed/discussions/47626

Interesting. I started working on this same idea a couple of years ago as a way to bypass CGo. Eventually I moved on to something else. Glad someone else is working on this. How does the generated Go performance compare to the original WASM performance?

Wow, written in just over a month. Say what you will about AI, but it has enabled serious speedups in the hands of a talented coder.

I'd like to use this, but I don't want to refactor all my services when they change the request/response types. Interested to know the timing of 1.x. It seems to be moving pretty fast atm - hopefully that momentum keeps going.

Interesting. It doesn't bother me at all, but the animation on Windows 11 to switch spaces feels very unsmooth to me and drives me crazy. Here I was wishing it was like the one on macOS.

What part of this that is crucial to your use isn't free? I personally think what they offer for free is quite good.

> But I keep wondering if they could integrate at a lower-level than the source code.

Unfortunately nothing below source code level is stable, so they would constantly be chasing changes after any Go release. I personally wish they would focus on making it accessible, as Go actually has a nice runtime and would make a good language target.

I did, but having the buttons on the bottom vs the side is a deal breaker for me, esp. since they are VERY tiny on my 4K screen. I can barely even get my mouse over them, and it seems they aren't movable to the left side like VSC? Am I missing something? Hard to believe this shipped, it is unusable for me.

> Personally waiting for one agent to do something while I shove my thumb up my butt just waiting around for it to generate code that I'll have to fix anyway

I spend that time watching it think and then contemplating the problem further since often, as deep and elaborate as my prompts are, I've forgotten something. I suspect it might be different if you are building something like a CRUD app, but if you are building a very complicated piece of software, context switching to a new topic while it is working is pretty tough. It is pretty fast anyway and can write the amount of code I would normally write in half a day in like 15 minutes.

I've been running Claude Code in my Cursor IDE for a while now via extension. I like the setup, and I direct Claude on one task at a time, while still having full access to my code (and nice completions via Cursor). I still spend time tweaking, etc. before committing. I have zero interest in these new "swarms of agents" they are trying to force on us from every direction. I can barely keep straight my code working on one feature at a time. AI has greatly helped me speed that up, but working serially has resulted in the best quality for me. I'll likely drop Cursor for good now and switch back to vanilla VsCode with CC.

Claude Code isn't really "all terminal" if you embed that terminal in your IDE. I still use Cursor (for now), but I embed a CC panel via extension. With this launch of Cursor 3, I'll probably get off Cursor for good. I have zero interest in this.

That is actually still React. React is React Core + ReactDOM (web) renderer. React Native is the React Core + native renderer. They are both still React, and they both use Javascript, which while fast when JIT'd, is typically much slower than native code.

I'm not commenting on whether this is a good or bad thing, but the article strikes me as a bit misleading.

No thanks. I should be able to use any copy of Windows for whatever use case I want. MS is free to disagree, and I am therefore free to keep not buying their products.

> I disagree, at least on end-user devices as opposed to servers.

And who determines what is an "end-user device" vs a "server"?

> If you're running a server, and willing to accept the risk of deferral because 1) you're in a better position to assess the risk and apply compensating controls than a regular user is, and 2) you're OK accepting the personal risk of having to explain to your boss why you kept deferring the urgent patch until after it blew up in your face, then yes, you should have a control to delay or disable it.

So you do want choice after all it seems. Who do you think should make this choice on risk vs. workload/criticality?

I would say you actually agree with me mostly based on your comments, but you have not clarified _who_ makes these choices. I'm saying as the consumer, _I_ should get to make that choice. In the enterprise, my admin will make that choice via group policy, but I do not want Microsoft determining what I'm allowed to do with my OS. They are of course free to keep doing that, but then I also have the right to keep not buying their products.

> fewer automatic restarts

No automatic restarts! I understand that in our security patching world that patching and restarting automatically is the default, fine, but there absolutely should be a dead simple way of disabling auto restarts in settings. I'm fine if it pesters me to restart or whatever, perhaps with growing alarm the longer I wait, but it should always be optional in the end. There are just no words for how bad it can be for mission critical workloads when your computer restarts without your consent. Please make disabling this simple.

HN is the best tech site on the web for a reason. It has a generally intelligent audience, and while there are certainly inappropriate comments, compared to what you find on social media or even other sites, it is unique and far more respectful. Due to this, you can often have better and more meaningful discussions.

Sadly, probably not. I fear new languages will struggle from here on out. As a language guy, very few things in this new AI world make me more sad than this.

What hardware do you have it running on? Do you feel you could replace the frontier models with it for everyday coding? Would/will you?

Have you used this for Rust coding by chance? I'm curious how it compares to Opus 4.6. I realize it isn't going to think to the same level, but curious how code quality is for a more straight forward task.

We are on the same wavelength. I'm thinking maybe a pass for now.

Thinking about getting a new MBP M5 Max 128GB (assuming they are released next week). I know "future proofing" at this stage is near impossible, but for writing Rust code locally (likely using Qwen 3.5 for now on MLX), the AIs have convinced me this is probably my best choice for immediate with some level of longevity, while retaining portability (not strictly needed, but nice to have). Alternatively was considering RTX options or a mac studio, but was leaning towards apple for the unified memory. What does HN think?

Quite good. I ported my codebase from Go to Rust in a fraction of the time it would have taken me to rewrite it.

> The computer science answer: a compiler is deterministic as a function of its full input state. Engineering answer: most real builds do not control the full input state, so outputs drift.

To me that implies the input isn't deterministic, not the compiler itself

That sounds great, but if Opus generates 20% better code think of the ramifications of that on a real world project. Already $100/month gets you a programmer (or maybe even 2 or 3) that can do your work for you. Insanity. Do I even care if there is something 80% as good for 50% the cost? My answer: no. That said, if it is every bit as good, and their benchmarks suggest it is (but proof will be in testing it out), then sure, a 50% cost reduction sounds really nice.

> but nothing comes to the top of my mind for other languages

"cargo clippy --fix" for Rust, essentially integrated with its linter. It doesn't fix all lints, however.

I am primarily using Claude as well, but I still have my old fix from Cursor, and as long as it is accurate like Cursor, I like it, if it falls below that level of accuracy, I find it annoying.

Yeah, why fork and create confusion if you don't plan to do anything with it?

Thanks. I probably could have answered my own question had I simply looked here:

https://github.com/gpui-ce/gpui-ce/pulls

and here:

https://github.com/zed-industries/zed/pulls?q=is%3Apr+is%3Ao...

Not sure how the UI engine itself compares, but to me it is all about the available components (as a total non-designer, although AI helps with that now). The only choice I have at the moment that would meet my needs is gpui, as gpui-component now exists.

Thanks. Have you used cursor or copilot (recently, tab completion has gotten better)? I'm curious how this compares in actual performance. Last time I used Zed, this was a showstopper as the completions were much worse (though if I configure it to use copilot as my source, I guess it should perform the same as VsCode?).