This is pretty exciting! While I’m betrothed to vim at this point, Zed’s progress has been super fun to watch. The screenshots/videos I’ve seen show off some slick UI.
GPUI being released under Apache 2.0 is really timely. I’m going to have to build a user facing GUI in Rust in ~3 months. Since my needs are relatively simple, I’d love to be able to kick the tires on GPUI assuming it’s relatively stable in different environments by that point.
wondering how it compares with egui, another immediate mode GUI framework for Rust, which is kinda clunky but using it was the first time I tried to make a GUI program that turned out to be… fun? actually enjoyable? not an unpleasant chore? I didn’t think it was possible (and I tried to use GTK2, GTK3 with gtk-rs, wxPython, touched Qt and Delphi, tried React, and had some more attempts that I don’t even remember). I don’t know if it’s immediate mode or specifically egui’s approach to it, but it was a very different experience from anything else.
Ugh, looks good, except the second feature they mention on their front page is “AI” baked in. And since “Providing server-side compute to power AI features is another monetization scheme we’re seeing getting traction”, I think they’ll have trouble getting away from “AI”, since that’s apparently a significant revenue stream for them.
Save time and keystrokes by generating code with AI. Zed supports GitHub Copilot out of the box, and you can use GPT-4 generate or refactor code by pressing ctrl-enter and typing a natural language prompt. Interact with the model conversationally without switching context in the built-in assistant panel, then reference your conversation during inline generation.
Those are just third-party tools that they’re supporting. Plenty of programmers use Copilot or GPT to help them write code, and this number will grow - we just had a call to discuss LLMs at work and it turned out every engineer was using some mix of Copilot or GPT to assist with writing code, SQL, etc. So calling out support in a feature list makes sense.
Regarding
Providing server-side compute to power AI features is another monetization scheme we’re seeing getting traction
Sounds like maybe one day they’d like to build their own version of Copilot. Doesn’t really seem like a problem, I’m sure there will be people who’d prefer not to pay Microsoft for a coding assistant.
I understand the desire to ride all the hype around AI, but there should be a big banner warning the users about the questionable copyright status of the output:
https://githubcopilotlitigation.com/
There should probably also be some markers inserted into the code to clearly delimit the AI generated and the human written parts, so that people reviewing the code would know they should take extra care with the AI generated part (which would look deceptively correct, but hide a number of subtle bugs).
There should probably also be some markers inserted into the code to clearly delimit the AI generated and the human written parts, so that people reviewing the code would know they should take extra care with the AI generated part (which would look deceptively correct, but hide a number of subtle bugs).
That reads like there’s both a clear delineation and large swathes of code generated and not reviewed. In my experience it’s more like the rest of a line or loop is “autocompleted” by AI and then the programmer continues writing the rest of the task they had in mind, rather than an entire class with multiple methods generated & committed. If the human wrote [var1, var2 and then the AI prompted completion for ].each do |var|, how do you mark that as generated for code review? And given it’s such a simple completion, does it even need calling out?
Indeed, I think most people concerned about AI coding assistance are imagining whole methods or classes generated and committed as-is, which IME is just not how these tools are used.
I don’t think that auto completion from a static set of completions is problematic (even if AI is used to make the choice); the problem is with generative AI where the possible output is some combination of the AI’s training corpus.
That is even more concerning then. Imagine that in the future you have to remove all AI generated code (e.g. due to a lawsuit). How would you find all the pieces that were AI generated? How would you prove what was written by a human (and thus your copyright), and what was created by an AI (either uncopyrightable, or potentially violating someone else’s copyright)?
In fact you probably can’t even add a ‘Signed-off-by’ line on your commit because that’d require you to verify that it was created by you, or that you have the right to use it (https://developercertificate.org/). But if you don’t even know which parts were written by you and which parts were written by an AI then you can’t use the signoff line.
How would you prove what was written by a human (and thus your copyright), and what was created by an AI (either uncopyrightable, or potentially violating someone else’s copyright)?
If even I can’t know, how can someone else know and thus how can they even be accusing it of being partly AI generated?
Has anyone yet coined the phrase AI-roll? That’s what I do when I read stuff like this. There’s no argument made, no clear critique. “They’re using AI stuff.” Yup. So?
Very few people are going to be convinced by a brief condemnation of LLMs in an internet forum. If you think “AI” is a good idea, my comment wasn’t for you, it was for people who share my concerns.
That said, I do have a long list of concerns, starting with GHG emissions, water usage, and “AI” pushing people to produce more code faster when we already have mountains of unmaintainable code.
This isn’t criticism, tho. It’s observation. It is true that they include LLM features and intend to monetize them. There’s no argument made. It’s not even really related to the story itself. What I see is an opportunity for them to make noise about their particular hobby gripe. I am annoyed by folks tryinna turn every topic into one topic they’re prepared to go in on.
I think there will definitely be room for external contributions. But I don’t think it’s the sort of thing where someone putting up a full “port Zed to Linux” PR is our desired outcome.
There are certain decisions that will be made by the Zed team, especially when it comes to things like how to build cross-platform APIs into GPUI.
I suggest changing the bit about licensing to present tense. At first I thought you were making the classic mistake of announcing that you were going open-source without actually releasing code. It would also help to link to the GitHub repo itself near the top of the post, to make it completely obvious.
Also, any plans to work on accessibility, particularly for screen reader users, in GPUI? It would really suck if a team came to depend on the collaborative features of Zed and excluded blind programmers as a result. I can help you integrate AccessKit, though I don’t have a lot of time to work on that integration myself.
I suggest changing the bit about licensing to present tense. At first I thought you were making the classic mistake of announcing that you were going open-source without actually releasing code. It would also help to link to the GitHub repo itself near the top of the post, to make it completely obvious.
Thank you for the suggestion! We have those amendments to the announcement post rolling out right now.
Also, any plans to work on accessibility, particularly for screen reader users, in GPUI? It would really suck if a team came to depend on the collaborative features of Zed and excluded blind programmers as a result.
Accessibility was one of the first things I asked about when I joined the team during the GPUI 2 rewrite. I agree that it’s an important thing to have in a UI framework.
I would definitely be interested in exploring integrating AccessKit, at least for GPUI on macOS. As we think about accessibility we’ll also need to consider what it looks like once GPUI is a cross-platform UI framework.
I saw a comment on HN saying you had helped out with egui’s accessibility story, so not sure if you also have thoughts on what the state of it is on Linux and/or Windows.
I’m the lead developer of AccessKit. Despite it’s Apple-like name (a possible source of confusion in retrospect), it’s actually a cross-platform library. The Windows and macOS backends are basically at feature parity now, while the Linux backend has some catching up to do, particularly when it comes to text editing support. I see that GPUI implements its own window system support rather than using something like winit, so there will be a little platform-specific accessibility code, but it should be feasible to keep most of the code cross-platform.
Zed is a fantastic editor and my default these days. It’s super responsive and has great defaults. I am sad there is no Linux version but understand why they build for macOS first. It feels it’s the user base that most likely will adopt it to me.
One thing I could never get my head around is the collaborative mode. In theory it’s amazing for teams, but since I mostly develop by myself or on open source at the moment there is little to no opportunity. One thing I do hope is that the collaborative mode extends to code review and debugging at some point.
As a Helix user, I wonder how hard or easy it would be to add Helix keybind support to Zed - both are Rust after all, and Helix is seperated into neat crates, just like Zed.
Looking forward to Linux support before that, though.
Since the author is here: the website has size issues on mobile Firefox. On the main page and a few others some of the text is cut off on the right side, the images are too wide, and the last button partially visible in the menu use “downlo”. Unfortunately custom zoom is disabled too so I can’t zoom out to see the rest.
I’m surprised they are trying to get this off the ground and this is macOS only. They should focus on producing a Windows version ASAP. Only 15-20% of desktop users use macOS. Linux is less than 1%. They are missing out on tons of potential users.
Windows > Linux > Mac according to the stackoverflow survey. Mac just over 30%, and the sum being far greater than 100%, which makes sense… I have a mac laptop and linux desktop in front of me right now for instance.
Interesting, but I’ll bet that high Linux usage is heavily server/Docker-based, where they’d be less likely to run an editor. I know it’s that way for me, anyway.
I always assumed this is about your workstations. Also, anecdotally, I have right now 10 PCs and laptops in my apartment. 2 Macs (personal), 1 Windows (wife’s work machine) and 7 Linux PCs. After that I can go start counting my servers and services, a few personal Linux machines and thousands of Linux containers we deploy at work (where we also almost only have Linux or Macs for workstations).
I’m not a typical user, I’m a developer frequenting stack overflow. And even as such, I’m an outlier. But my point here is that “it’s that way for me” is very anecdotal.
Yeah, I just did a quick wander around the coworking space here and counted 8 Mac laptops, 2 Linux laptops (which I know are Linux because I know the people using them), 3 (presumed) Windows laptops, and 2 Surface tablets. Two of the windows laptops and both Surfaces appeared to be in PowerPoint and the users were wearing ties.
If you’re making a “fast and beautiful” code editor, targeting OS X doesn’t seem like a bad call to me. Especially if it means the developers can start dogfooding it early.
On the other hand GP it’s open source now so if Windows support is something you really want you could start planting those seeds and see if anyone else wants to help!
I don’t have those numbers but I agree it’s reasonable to assume that among developers the distribution probably skews a little bit more to macOS and Linux. I don’t think it skews it enough though nor would I take that chance when building a desktop app.
I don’t have hard data but I get the vibe that Windows programmers are a distinct “culture” that doesn’t overlap much with “our” culture. Looking at the tags, there were fewer Windows stories submitted than any of Linux, Unix, macOS, or openBSD. It beats freeBSD by a few dozen more stories.
I also feel like most devs in “our culture” don’t really think about people on Windows. I regularly experience VSCode extensions breaking because they hardcode unix file separators or call posix functions or the like.
I don’t have hard data but I get the vibe that Windows programmers are a distinct “culture” that doesn’t overlap much with “our” culture.
That may be the case but if you want to produce a successful desktop application, it would make sense to venture out into the world of Windows and interact with that culture. Our culture, as you put it, is relatively very small, probably by a couple orders of magnitude, and it will be that much harder to build a sustainable business or project with this small slice.
The numbers are very humbling, more than 80% of desktops are on Windows. The vast majority of new people learning how to program today are starting off already owning a Windows PC. Realistically macOS and Linux are never going to reach that level of popularity. Macs are too expensive and Linux is too difficult to set up correctly for the average person, even the average developer (which is why the more well-off ones use macOS). If you want to build software for people, you have to go to where the people are.
I’m curious what the economics of developing productivity software for Windows is like nowadays. (Ignoring games - that seems to be pretty healthy.) There’s a ton of users, but I don’t know how many will actually use your software and pay for it. I suspect a lot are going to be either very minimal users who might as well be using a Chromebook but are on Windows out of inertia, or locked down corporate systems. I haven’t heard much out of the Windows shareware ecosystem in a while, while the Mac one seems self-sustaining, even if it’s not as strong as it used to be.
You can kinda see this in mobile too; even though Android is a lot healthier than Windows is as an ecosystem (i.e. less rudderless), but the money is made on iOS.
When I started at Microsoft, the big concern from the Windows org was that they had lost the battle for developers. To a first approximation, no one was writing new Win32 apps. This was viewed as the main reason that UWP was failing in the market: the only people still writing Windows-first applications were ones that had large existing codebases. UWP was intended to appeal to people entering the Windows ecosystem for the first time and there simply weren’t many of them.
Most application development was either web or mobile first. Web-first things were using Electron. This was the big reason that Edge moved to being based on Chromium: Windows needed to be a great target for Electron apps and that meant Microsoft needed to have people working on Chromium and it was duplication of effort to have an Electron team and an Edge team working on different browser engines.
Most server-side deployment had moved to Linux. WSL’s primary goal (the initial implementation was to run Android apps on Windows Phone, but I’m talking about the public versions) was to allow people to write Linux things locally that they’d then deploy in Azure. This is a big part of the reason for WSL2: Docker didn’t run on WSL because it didn’t implement all of the namespaces, cgroups, seccomp-bpf, and other goo required to fake jails on Linux and the engineering cost of parity there was too high. Docker was the big thing that people wanted: write Linux things on Windows, docker push them to a container registry, and then deploy them on the Azure Container platform.
This is why so much effort went into VS Code and especially on Docker integration with the remote extension: It lets you stay on Windows, but still write server code for Linux and web apps that run in Chromium-based browsers anywhere.
In contrast, macOS has enjoyed a lot of Mac-only applications for a long time with a lot of new developers coming along. In part, this is because OpenStep is an amazing piece of usability design for an API (though somewhat dated now), whereas Win32 and the layers on top are weird silos that hate each other and cause suffering to all involved. Anders is an amazing language designer but everything that he has created, at least from Delphi onwards, has been let down by mediocre and inconsistent standard library APIs. Catalyst has made it possible to write macOS and iOS apps that share most of their code, but take advantage of macOS features, making the incremental cost of macOS for mobile-first development much lower. Now that iOS has more than 50% of the market share in the US (and always had a significantly higher proportion of the users that paid for software), it’s quite feasible to be iOS first, macOS second, and Windows never and still be successful.
I guess when it comes to APIs, people should follow what Microsoft does (use Chromium and Electron), not what Microsoft says (use whatever Windows-specific UI framework exists today). Why be Windows-specific when it gets you little benefit, and ship a cross-platform app instead if you’re Windows-first? Whereas as you mention, you do get some benefit to staying within Apple’s ecosystem as a developer.
There’s a ton of users, but I don’t know how many will actually use your software and pay for it.
I don’t have any good reason to assume the percentage of people who would pay for software would be much different across windows and macOS. I think you’re implying that macOS users are significantly more likely to buy software. For curiosity’s sake, why would that be?
Just as another thought exercise. you’d also have to weigh that percentage by the relative size of each user base to assess the relative demand for your software. If we assume 80% windows and 20% macOS. Even if 100% of Mac users paid for your software, you’d only need 25% of your windows users to pay to match the macOS demand.
I suspect a lot are going to be either very minimal users who might as well be using a Chromebook but are on Windows out of inertia, or locked down corporate systems.
For better or worse, windows is the default pc platform for everyone. Not just gamers, not just office workers. You have graphic designers, video editors, audio producers, streamers, podcasters, students, and many more. You can’t do that stuff with chromebook (I think) and not everyone can afford a Mac.
This is a separate point but I’ve used linux for my entire adult life. I’ve been so entrenched in the programming world that I forgot ”normal people” also have to deal with computers. I always assumed that eventually windows would die off but that didn’t happen (it was partly wishful thinking due to overdosing on ideological koolaid). The only practical option for most people has continued to be windows. There is a lesson in there somewhere but regardless I’ve started to realize that there is a lot of opportunity on the windows platform that is being totally ignored by the software world. Both in terms of commercial opportunity but also in terms of spreading cool tech. OBS is sort of an example of that.
I don’t have any good reason to assume the percentage of people who would pay for software would be much different across windows and macOS. I think you’re implying that macOS users are significantly more likely to buy software. For curiosity’s sake, why would that be?
Mostly the fact that the Mac shareware ecosystem (i.e. you see the Panics and Omnis of the world still going at it, lots of indie developers still) is far healthier than the Windows one (most Windows stuff seems to be entrenched large ISVs and OSS ports from Linux, like OBS as you mention). Also that on mobile, iOS is outnumbered in most countries, but still makes more money for app developers.
For better or worse, windows is the default pc platform for everyone. Not just gamers, not just office workers. You have graphic designers, video editors, audio producers, streamers, podcasters, students, and many more. You can’t do that stuff with chromebook (I think) and not everyone can afford a Mac.
FWIW, I have a suspicion that long term (over the course of a decade, maybe two) the Windows userbase will shrink drastically, shedding the people who probably just use their phones now/better off buying a Chromebook (the “post-PC” future). However, the userbase floor it’s going to hit is still going to be pretty high, and a lot of those are going to be technical professionals/information workers/etc who need a desktop-experience computer. So, by proportion, the Mac/Linux userbase will grow quite a bit, but the Windows userbase that’s left is a lot likelier to pay for software.
I agree it would be crazy to try to make a big business while ignoring Windows entirely, but obviously there are tons of Mac only indie devs too. For Zed, I think it makes sense to start on a platform that their devs already use and that has more early adopters and plan to do a Windows port after you prove basic product-market fit as an expansion play.
My logic here is that the calculus used to justify launching on macOS first makes even more sense for launching on Windows first. At least the stack overflow post linked above shows that the number of devs that use Windows is about double the amount of devs that use macOS. On numbers alone, I think it’s easier to get traction through a Windows audience then leveraging that traction to get adoption on macOS than vice versa. Either way it’s not necessarily damning, it’s just a matter of how much of an uphill battle you want to fight.
Our culture, as you put it, is relatively very small, probably by a couple orders of magnitude, and it will be that much harder to build a sustainable business or project with this small slice.
more than 80% of desktops are on Windows
90%+ of desktop users are not the target market for a development tool.
Based on the SO dev survey linked elsewhere in this thread and the Jetbrains survey (https://www.jetbrains.com/lp/devecosystem-2023/development/) Windows has somewhere between 45% and 60% market share among developers, which is what matters here.
There are I would imagine, other factors too, that favour a macOS-first approach for something like this (these are just spitball theories off the top of my head):
POSIX compatibility, meaning potentially less work when adapting for Linux desktops;
Linux-using developers are probably more likely to be hardcore Emacs/Vim users relative to macOS users;
macOS is for the most part a single target. You can ship literally one binary to target multiple versions of macOS running on both Arm and Intel CPUs. Targeting “Linux desktop” is like saying “I want to eat some fish” - ok, but you need to be more specific.
Based on the SO dev survey linked elsewhere in this thread and the Jetbrains survey (https://www.jetbrains.com/lp/devecosystem-2023/development/) Windows has somewhere between 45% and 60% market share among developers, which is what matters here.
And I wouldn’t be too surprised to see that it’s mostly i.e. Visual Studio users writing ASP.NET/Windows GUI projects for LoB applications. Very 9-5 types (I believe Hanselman has a better term) who don’t engage with new developer tools like this.
And don’t forget that MacOS provides some great default APIs, e.g. CoreText and Metal. For a long time, it’s just been a lot easier to make a nice app on MacOS than on any non-web target.
It’s an interesting phenomenon really. I am admittedly a write-code-on OSX/Linux hybrid user who generally uses Windows for business tools (Fusion 360 and other CAD software, Visio and Project, etc). The other day I tried to do a git clone for a C++ project into a normal place (C:\Users\Tony\Documents) and the clone failed because the project has git submodules and ultimately there were paths in the checkout that exceeded the 256-byte limit :(
I think there’s a self-reinforcing cycle where the developer experience on Windows is painful when working with code that would otherwise be portable. For people who hang out in Visual Studio (not VSCode) everyday I’m sure they’ve got workflows that work for them but trying to get generic code running can be painful. I’ve run into similar issues with node and ruby in the past too.
I agree with this. Even macOS can be annoying, where the shell and the tools are just different enough that a script will break and waste a lot of time.
Windows on a personal machine I just gave up on because home versions of Windows increasingly resembles Adware.
I used Linux when you had to do web searches to get the mouse working properly. Now that a modern laptop often runs Linux out of the box, it’s pretty easy for me to go Windows free. Apple makes great hardware (though their quality has been getting iffy) and macOS is tolerable, but it is easier and easier to get a decent laptop to run Linux on.
There are certainly macOS annoyances, but being able to run native Word, Powerpoint, Outlook, Acrobat etc with all of the SharePoint integration that work expects us to work with… that’s the Killer App that keeps me on a Macbook instead of using my Linux laptop as my daily driver.
Yeah, I’ve been lucky to have been working at places that do ok with the Google suite of tools which are nicely platform independent, ever since we decided to make the browser the operating system.
I’ve tried. I’ve really tried. Both GSuite and Office 365 web versions and I just can’t handle it. They’re fine, for me, for smaller (say <5 page) documents but for larger documents I just get frustrated. And sometimes I end up working on complex Excel models (because the business people want to be able to vary the inputs and see the effects) that stress out the desktop version and trying to run them in either Google Sheets or Web Excel is miserable. I’ve tried LibreOffice too but often enough the formatting gets borked when I save to an Office-compatible format and send it to someone.
To add to it, I often end up doing field work where reliable Internet isn’t something that can be relied on, even over LTE/5G. [Edit: There’s a whole lot of comfort in knowing that I can grab all of the documentation for a project from (barf) SharePoint, throw it on a USB drive, and be able to open it on any of the computers on-site whether or not we happen to have a connection at that moment]
It’s not as if I’m a Microsoft fanboy either. Any notes that I’m keeping for myself/consulting company are in Emacs org-mode and any larger documentation is generally either ReStructuredText in Sphinx or through rst2latex.py to make a PDF with all of that gorgeous math in it.
Also, I would bet that a large portion of the Windows devs are using Visual Studio because they’re doing some sort of .NET development, or at least have to integrate with it in one way or another. Those people, as a group, are probably less interested in a new editor.
Turn off your adblocker. There are a lot of screenshots and screen-casts on the home page. Although https://zed.dev works fine with uBO, it might be a false positive with your specific adblocker.
This seems to get compared to VSCode a lot, but can anyone compare this to a full IDE ?
Specifically, how does it compare with the Jetbrains IntelliJ platform in terms of code ‘knowledge’?
Usually one of the more obvious tests is, can it handle refactoring of code i.e. renaming symbols, extracting interfaces, moving members up/down a class hierarchy?
Zed relies on the target language’s language server for those kinds of operations.
When renaming a symbol in a Rust project, for instance, Zed just calls out to rust-analyzer to handle that. Same thing with other kinds of refactorings.
There are things that Zed provides on top of the language server. To use the rename example again, when you rename a symbol in Zed we open up a multibuffer containing the rename for you to assess the impact before you commit it (and flush the change to all of the files).
That’s basically what I was told last time I ventured out of IntelliJ to try a “lighter” editor (Nova, by Panic, which LOOKS amazing but just doesn’t have the functionality to compete with IDEA).
I did just try Zed quickly - the ‘rename symbol’ feature just doesn’t seem to work on PHP apparently (it lets me provide a new name but then just discards it).
But more jarring than that - jarring enough that I had to convince myself to re-open Zed and try it again, is the appearance. I don’t know quite what “design decisions” were made but something about it just gives the feel of an early 2000’s “desktop in a browser” where nothing looks/behaves quite as it should.
It’s hard to comprehend but somehow IDEA, even being cross platform with a Java UI still feels more like a native app than this does. Maybe with tweaks to the various settings it’s possible to make it fit in more? I don’t know, but the defaults definitely don’t feel anywhere close to a native UI, which doesn’t bode well for that being possible IMO.
Along with Zed we’ve also open-sourced GPUI, the immediate-mode Rust framework that powers Zed.
It’s currently pretty intertwined with Zed, but our goal is to make it generally usable.
This is pretty exciting! While I’m betrothed to vim at this point, Zed’s progress has been super fun to watch. The screenshots/videos I’ve seen show off some slick UI.
GPUI being released under Apache 2.0 is really timely. I’m going to have to build a user facing GUI in Rust in ~3 months. Since my needs are relatively simple, I’d love to be able to kick the tires on GPUI assuming it’s relatively stable in different environments by that point.
[Comment removed by author]
wondering how it compares with egui, another immediate mode GUI framework for Rust, which is kinda clunky but using it was the first time I tried to make a GUI program that turned out to be… fun? actually enjoyable? not an unpleasant chore? I didn’t think it was possible (and I tried to use GTK2, GTK3 with gtk-rs, wxPython, touched Qt and Delphi, tried React, and had some more attempts that I don’t even remember). I don’t know if it’s immediate mode or specifically egui’s approach to it, but it was a very different experience from anything else.
Ugh, looks good, except the second feature they mention on their front page is “AI” baked in. And since “Providing server-side compute to power AI features is another monetization scheme we’re seeing getting traction”, I think they’ll have trouble getting away from “AI”, since that’s apparently a significant revenue stream for them.
Yeah, it’s enough to make me not want to even try it.
What I’m seeing is
Those are just third-party tools that they’re supporting. Plenty of programmers use Copilot or GPT to help them write code, and this number will grow - we just had a call to discuss LLMs at work and it turned out every engineer was using some mix of Copilot or GPT to assist with writing code, SQL, etc. So calling out support in a feature list makes sense.
Regarding
Sounds like maybe one day they’d like to build their own version of Copilot. Doesn’t really seem like a problem, I’m sure there will be people who’d prefer not to pay Microsoft for a coding assistant.
I understand the desire to ride all the hype around AI, but there should be a big banner warning the users about the questionable copyright status of the output: https://githubcopilotlitigation.com/
There should probably also be some markers inserted into the code to clearly delimit the AI generated and the human written parts, so that people reviewing the code would know they should take extra care with the AI generated part (which would look deceptively correct, but hide a number of subtle bugs).
That reads like there’s both a clear delineation and large swathes of code generated and not reviewed. In my experience it’s more like the rest of a line or loop is “autocompleted” by AI and then the programmer continues writing the rest of the task they had in mind, rather than an entire class with multiple methods generated & committed. If the human wrote
[var1, var2and then the AI prompted completion for].each do |var|, how do you mark that as generated for code review? And given it’s such a simple completion, does it even need calling out?Indeed, I think most people concerned about AI coding assistance are imagining whole methods or classes generated and committed as-is, which IME is just not how these tools are used.
I don’t think that auto completion from a static set of completions is problematic (even if AI is used to make the choice); the problem is with generative AI where the possible output is some combination of the AI’s training corpus.
That is even more concerning then. Imagine that in the future you have to remove all AI generated code (e.g. due to a lawsuit). How would you find all the pieces that were AI generated? How would you prove what was written by a human (and thus your copyright), and what was created by an AI (either uncopyrightable, or potentially violating someone else’s copyright)?
In fact you probably can’t even add a ‘Signed-off-by’ line on your commit because that’d require you to verify that it was created by you, or that you have the right to use it (https://developercertificate.org/). But if you don’t even know which parts were written by you and which parts were written by an AI then you can’t use the signoff line.
If even I can’t know, how can someone else know and thus how can they even be accusing it of being partly AI generated?
Has anyone yet coined the phrase AI-roll? That’s what I do when I read stuff like this. There’s no argument made, no clear critique. “They’re using AI stuff.” Yup. So?
Very few people are going to be convinced by a brief condemnation of LLMs in an internet forum. If you think “AI” is a good idea, my comment wasn’t for you, it was for people who share my concerns.
That said, I do have a long list of concerns, starting with GHG emissions, water usage, and “AI” pushing people to produce more code faster when we already have mountains of unmaintainable code.
Why are you bothered that people are critical of AI hype?
This isn’t criticism, tho. It’s observation. It is true that they include LLM features and intend to monetize them. There’s no argument made. It’s not even really related to the story itself. What I see is an opportunity for them to make noise about their particular hobby gripe. I am annoyed by folks tryinna turn every topic into one topic they’re prepared to go in on.
The anti-hype is the hype, too.
You seem new here 😉 People ride their particular hobby-horses at the drop of a hat all over the comments.
Looking forward to trying it out, but it’s still mac-only ? Any timeframe for Linux ?
Correct, Zed is currently only available on macOS.
We are planning to get it running on Linux (and then Windows), but no hard timeframe at the moment. I do think it will see movement this year.
Is linux support something that an outside contributor could meaningfully push forwards?
I think there will definitely be room for external contributions. But I don’t think it’s the sort of thing where someone putting up a full “port Zed to Linux” PR is our desired outcome.
There are certain decisions that will be made by the Zed team, especially when it comes to things like how to build cross-platform APIs into GPUI.
Congrats!
I suggest changing the bit about licensing to present tense. At first I thought you were making the classic mistake of announcing that you were going open-source without actually releasing code. It would also help to link to the GitHub repo itself near the top of the post, to make it completely obvious.
Also, any plans to work on accessibility, particularly for screen reader users, in GPUI? It would really suck if a team came to depend on the collaborative features of Zed and excluded blind programmers as a result. I can help you integrate AccessKit, though I don’t have a lot of time to work on that integration myself.
Thank you for the suggestion! We have those amendments to the announcement post rolling out right now.
Accessibility was one of the first things I asked about when I joined the team during the GPUI 2 rewrite. I agree that it’s an important thing to have in a UI framework.
I would definitely be interested in exploring integrating AccessKit, at least for GPUI on macOS. As we think about accessibility we’ll also need to consider what it looks like once GPUI is a cross-platform UI framework.
I saw a comment on HN saying you had helped out with
egui’s accessibility story, so not sure if you also have thoughts on what the state of it is on Linux and/or Windows.I’m the lead developer of AccessKit. Despite it’s Apple-like name (a possible source of confusion in retrospect), it’s actually a cross-platform library. The Windows and macOS backends are basically at feature parity now, while the Linux backend has some catching up to do, particularly when it comes to text editing support. I see that GPUI implements its own window system support rather than using something like winit, so there will be a little platform-specific accessibility code, but it should be feasible to keep most of the code cross-platform.
I see! I had only heard it mentioned by name and thought it was an Apple API.
We have at least one other engineer on the team (@mikaylacm) who is interested in adding AccessKit support.
Zed is a fantastic editor and my default these days. It’s super responsive and has great defaults. I am sad there is no Linux version but understand why they build for macOS first. It feels it’s the user base that most likely will adopt it to me.
One thing I could never get my head around is the collaborative mode. In theory it’s amazing for teams, but since I mostly develop by myself or on open source at the moment there is little to no opportunity. One thing I do hope is that the collaborative mode extends to code review and debugging at some point.
As a Helix user, I wonder how hard or easy it would be to add Helix keybind support to Zed - both are Rust after all, and Helix is seperated into neat crates, just like Zed.
Looking forward to Linux support before that, though.
That’s an interesting idea!
I haven’t used Helix much, but I’d be curious to see how far someone could get by creating a custom keymap like what we have for vim.
I imagine some of the stuff might be vim-specific.
Not to be confused with https://ocaml.org/p/zed/3.2.1
Since the author is here: the website has size issues on mobile Firefox. On the main page and a few others some of the text is cut off on the right side, the images are too wide, and the last button partially visible in the menu use “downlo”. Unfortunately custom zoom is disabled too so I can’t zoom out to see the rest.
Not sure how recently you were seeing this. We pushed some changes to improve the responsiveness a little while ago (about 30 minutes or so).
They seemed to look alright in Chrome on iOS, but could you let me know if things still look wonky for you?
Heh, that fixed it, probably as I was writing the message. The menu still overflows, but the contents are ok.
if only that was necessarily true
I’m surprised they are trying to get this off the ground and this is macOS only. They should focus on producing a Windows version ASAP. Only 15-20% of desktop users use macOS. Linux is less than 1%. They are missing out on tons of potential users.
What about developers? Probably much higher share of Mac & Linux users there
Windows > Linux > Mac according to the stackoverflow survey. Mac just over 30%, and the sum being far greater than 100%, which makes sense… I have a mac laptop and linux desktop in front of me right now for instance.
The 2022 edition asked the question this way
The 2023 edition broke linux up by distro, but looks consistent with the 2022 edition.
Interesting, but I’ll bet that high Linux usage is heavily server/Docker-based, where they’d be less likely to run an editor. I know it’s that way for me, anyway.
I always assumed this is about your workstations. Also, anecdotally, I have right now 10 PCs and laptops in my apartment. 2 Macs (personal), 1 Windows (wife’s work machine) and 7 Linux PCs. After that I can go start counting my servers and services, a few personal Linux machines and thousands of Linux containers we deploy at work (where we also almost only have Linux or Macs for workstations).
I’m not a typical user, I’m a developer frequenting stack overflow. And even as such, I’m an outlier. But my point here is that “it’s that way for me” is very anecdotal.
Yeah, I just did a quick wander around the coworking space here and counted 8 Mac laptops, 2 Linux laptops (which I know are Linux because I know the people using them), 3 (presumed) Windows laptops, and 2 Surface tablets. Two of the windows laptops and both Surfaces appeared to be in PowerPoint and the users were wearing ties.
If you’re making a “fast and beautiful” code editor, targeting OS X doesn’t seem like a bad call to me. Especially if it means the developers can start dogfooding it early.
On the other hand GP it’s open source now so if Windows support is something you really want you could start planting those seeds and see if anyone else wants to help!
I don’t have those numbers but I agree it’s reasonable to assume that among developers the distribution probably skews a little bit more to macOS and Linux. I don’t think it skews it enough though nor would I take that chance when building a desktop app.
I don’t have hard data but I get the vibe that Windows programmers are a distinct “culture” that doesn’t overlap much with “our” culture. Looking at the tags, there were fewer Windows stories submitted than any of Linux, Unix, macOS, or openBSD. It beats freeBSD by a few dozen more stories.
I also feel like most devs in “our culture” don’t really think about people on Windows. I regularly experience VSCode extensions breaking because they hardcode unix file separators or call posix functions or the like.
That may be the case but if you want to produce a successful desktop application, it would make sense to venture out into the world of Windows and interact with that culture. Our culture, as you put it, is relatively very small, probably by a couple orders of magnitude, and it will be that much harder to build a sustainable business or project with this small slice.
The numbers are very humbling, more than 80% of desktops are on Windows. The vast majority of new people learning how to program today are starting off already owning a Windows PC. Realistically macOS and Linux are never going to reach that level of popularity. Macs are too expensive and Linux is too difficult to set up correctly for the average person, even the average developer (which is why the more well-off ones use macOS). If you want to build software for people, you have to go to where the people are.
I’m curious what the economics of developing productivity software for Windows is like nowadays. (Ignoring games - that seems to be pretty healthy.) There’s a ton of users, but I don’t know how many will actually use your software and pay for it. I suspect a lot are going to be either very minimal users who might as well be using a Chromebook but are on Windows out of inertia, or locked down corporate systems. I haven’t heard much out of the Windows shareware ecosystem in a while, while the Mac one seems self-sustaining, even if it’s not as strong as it used to be.
You can kinda see this in mobile too; even though Android is a lot healthier than Windows is as an ecosystem (i.e. less rudderless), but the money is made on iOS.
When I started at Microsoft, the big concern from the Windows org was that they had lost the battle for developers. To a first approximation, no one was writing new Win32 apps. This was viewed as the main reason that UWP was failing in the market: the only people still writing Windows-first applications were ones that had large existing codebases. UWP was intended to appeal to people entering the Windows ecosystem for the first time and there simply weren’t many of them.
Most application development was either web or mobile first. Web-first things were using Electron. This was the big reason that Edge moved to being based on Chromium: Windows needed to be a great target for Electron apps and that meant Microsoft needed to have people working on Chromium and it was duplication of effort to have an Electron team and an Edge team working on different browser engines.
Most server-side deployment had moved to Linux. WSL’s primary goal (the initial implementation was to run Android apps on Windows Phone, but I’m talking about the public versions) was to allow people to write Linux things locally that they’d then deploy in Azure. This is a big part of the reason for WSL2: Docker didn’t run on WSL because it didn’t implement all of the namespaces, cgroups, seccomp-bpf, and other goo required to fake jails on Linux and the engineering cost of parity there was too high. Docker was the big thing that people wanted: write Linux things on Windows,
docker pushthem to a container registry, and then deploy them on the Azure Container platform.This is why so much effort went into VS Code and especially on Docker integration with the remote extension: It lets you stay on Windows, but still write server code for Linux and web apps that run in Chromium-based browsers anywhere.
In contrast, macOS has enjoyed a lot of Mac-only applications for a long time with a lot of new developers coming along. In part, this is because OpenStep is an amazing piece of usability design for an API (though somewhat dated now), whereas Win32 and the layers on top are weird silos that hate each other and cause suffering to all involved. Anders is an amazing language designer but everything that he has created, at least from Delphi onwards, has been let down by mediocre and inconsistent standard library APIs. Catalyst has made it possible to write macOS and iOS apps that share most of their code, but take advantage of macOS features, making the incremental cost of macOS for mobile-first development much lower. Now that iOS has more than 50% of the market share in the US (and always had a significantly higher proportion of the users that paid for software), it’s quite feasible to be iOS first, macOS second, and Windows never and still be successful.
It seems to me that the real reasons for UWP’s failure were:
Did these things not occur to Microsoft leadership? Or were they too distracted by fear of the iPad and the need to sell Windows licenses?
I guess when it comes to APIs, people should follow what Microsoft does (use Chromium and Electron), not what Microsoft says (use whatever Windows-specific UI framework exists today). Why be Windows-specific when it gets you little benefit, and ship a cross-platform app instead if you’re Windows-first? Whereas as you mention, you do get some benefit to staying within Apple’s ecosystem as a developer.
I don’t have any good reason to assume the percentage of people who would pay for software would be much different across windows and macOS. I think you’re implying that macOS users are significantly more likely to buy software. For curiosity’s sake, why would that be?
Just as another thought exercise. you’d also have to weigh that percentage by the relative size of each user base to assess the relative demand for your software. If we assume 80% windows and 20% macOS. Even if 100% of Mac users paid for your software, you’d only need 25% of your windows users to pay to match the macOS demand.
For better or worse, windows is the default pc platform for everyone. Not just gamers, not just office workers. You have graphic designers, video editors, audio producers, streamers, podcasters, students, and many more. You can’t do that stuff with chromebook (I think) and not everyone can afford a Mac.
This is a separate point but I’ve used linux for my entire adult life. I’ve been so entrenched in the programming world that I forgot ”normal people” also have to deal with computers. I always assumed that eventually windows would die off but that didn’t happen (it was partly wishful thinking due to overdosing on ideological koolaid). The only practical option for most people has continued to be windows. There is a lesson in there somewhere but regardless I’ve started to realize that there is a lot of opportunity on the windows platform that is being totally ignored by the software world. Both in terms of commercial opportunity but also in terms of spreading cool tech. OBS is sort of an example of that.
Mostly the fact that the Mac shareware ecosystem (i.e. you see the Panics and Omnis of the world still going at it, lots of indie developers still) is far healthier than the Windows one (most Windows stuff seems to be entrenched large ISVs and OSS ports from Linux, like OBS as you mention). Also that on mobile, iOS is outnumbered in most countries, but still makes more money for app developers.
FWIW, I have a suspicion that long term (over the course of a decade, maybe two) the Windows userbase will shrink drastically, shedding the people who probably just use their phones now/better off buying a Chromebook (the “post-PC” future). However, the userbase floor it’s going to hit is still going to be pretty high, and a lot of those are going to be technical professionals/information workers/etc who need a desktop-experience computer. So, by proportion, the Mac/Linux userbase will grow quite a bit, but the Windows userbase that’s left is a lot likelier to pay for software.
I agree it would be crazy to try to make a big business while ignoring Windows entirely, but obviously there are tons of Mac only indie devs too. For Zed, I think it makes sense to start on a platform that their devs already use and that has more early adopters and plan to do a Windows port after you prove basic product-market fit as an expansion play.
My logic here is that the calculus used to justify launching on macOS first makes even more sense for launching on Windows first. At least the stack overflow post linked above shows that the number of devs that use Windows is about double the amount of devs that use macOS. On numbers alone, I think it’s easier to get traction through a Windows audience then leveraging that traction to get adoption on macOS than vice versa. Either way it’s not necessarily damning, it’s just a matter of how much of an uphill battle you want to fight.
90%+ of desktop users are not the target market for a development tool.
Based on the SO dev survey linked elsewhere in this thread and the Jetbrains survey (https://www.jetbrains.com/lp/devecosystem-2023/development/) Windows has somewhere between 45% and 60% market share among developers, which is what matters here.
There are I would imagine, other factors too, that favour a macOS-first approach for something like this (these are just spitball theories off the top of my head):
And I wouldn’t be too surprised to see that it’s mostly i.e. Visual Studio users writing ASP.NET/Windows GUI projects for LoB applications. Very 9-5 types (I believe Hanselman has a better term) who don’t engage with new developer tools like this.
And don’t forget that MacOS provides some great default APIs, e.g. CoreText and Metal. For a long time, it’s just been a lot easier to make a nice app on MacOS than on any non-web target.
It’s an interesting phenomenon really. I am admittedly a write-code-on OSX/Linux hybrid user who generally uses Windows for business tools (Fusion 360 and other CAD software, Visio and Project, etc). The other day I tried to do a git clone for a C++ project into a normal place (C:\Users\Tony\Documents) and the clone failed because the project has git submodules and ultimately there were paths in the checkout that exceeded the 256-byte limit :(
I think there’s a self-reinforcing cycle where the developer experience on Windows is painful when working with code that would otherwise be portable. For people who hang out in Visual Studio (not VSCode) everyday I’m sure they’ve got workflows that work for them but trying to get generic code running can be painful. I’ve run into similar issues with node and ruby in the past too.
I agree with this. Even macOS can be annoying, where the shell and the tools are just different enough that a script will break and waste a lot of time.
Windows on a personal machine I just gave up on because home versions of Windows increasingly resembles Adware.
I used Linux when you had to do web searches to get the mouse working properly. Now that a modern laptop often runs Linux out of the box, it’s pretty easy for me to go Windows free. Apple makes great hardware (though their quality has been getting iffy) and macOS is tolerable, but it is easier and easier to get a decent laptop to run Linux on.
There are certainly macOS annoyances, but being able to run native Word, Powerpoint, Outlook, Acrobat etc with all of the SharePoint integration that work expects us to work with… that’s the Killer App that keeps me on a Macbook instead of using my Linux laptop as my daily driver.
Yeah, I’ve been lucky to have been working at places that do ok with the Google suite of tools which are nicely platform independent, ever since we decided to make the browser the operating system.
I’ve tried. I’ve really tried. Both GSuite and Office 365 web versions and I just can’t handle it. They’re fine, for me, for smaller (say <5 page) documents but for larger documents I just get frustrated. And sometimes I end up working on complex Excel models (because the business people want to be able to vary the inputs and see the effects) that stress out the desktop version and trying to run them in either Google Sheets or Web Excel is miserable. I’ve tried LibreOffice too but often enough the formatting gets borked when I save to an Office-compatible format and send it to someone.
To add to it, I often end up doing field work where reliable Internet isn’t something that can be relied on, even over LTE/5G. [Edit: There’s a whole lot of comfort in knowing that I can grab all of the documentation for a project from (barf) SharePoint, throw it on a USB drive, and be able to open it on any of the computers on-site whether or not we happen to have a connection at that moment]
It’s not as if I’m a Microsoft fanboy either. Any notes that I’m keeping for myself/consulting company are in Emacs org-mode and any larger documentation is generally either ReStructuredText in Sphinx or through rst2latex.py to make a PDF with all of that gorgeous math in it.
Also, I would bet that a large portion of the Windows devs are using Visual Studio because they’re doing some sort of .NET development, or at least have to integrate with it in one way or another. Those people, as a group, are probably less interested in a new editor.
I mean I have occasionally seen developer outfits that aren’t mainly on macOS but those have been pretty universally mediocre to bad.
I wonder how this compares to Jetbrains Fleet, they seem to have similar goals and architectures.
I would love to see some screenshots of this. Sadly these are often missing.
There are a number of screenshots and videos on the zed.dev homepage.
Turn off your adblocker. There are a lot of screenshots and screen-casts on the home page. Although https://zed.dev works fine with uBO, it might be a false positive with your specific adblocker.
You were of course right, but i accessed the site on mobile network and the videos simply did not load.
Love it, would love to switch when it’s running on Windows! Gave it a run on my macbook and it’s really nice!
This seems to get compared to VSCode a lot, but can anyone compare this to a full IDE ?
Specifically, how does it compare with the Jetbrains IntelliJ platform in terms of code ‘knowledge’?
Usually one of the more obvious tests is, can it handle refactoring of code i.e. renaming symbols, extracting interfaces, moving members up/down a class hierarchy?
Zed relies on the target language’s language server for those kinds of operations.
When renaming a symbol in a Rust project, for instance, Zed just calls out to
rust-analyzerto handle that. Same thing with other kinds of refactorings.There are things that Zed provides on top of the language server. To use the rename example again, when you rename a symbol in Zed we open up a multibuffer containing the rename for you to assess the impact before you commit it (and flush the change to all of the files).
That’s basically what I was told last time I ventured out of IntelliJ to try a “lighter” editor (Nova, by Panic, which LOOKS amazing but just doesn’t have the functionality to compete with IDEA).
I did just try Zed quickly - the ‘rename symbol’ feature just doesn’t seem to work on PHP apparently (it lets me provide a new name but then just discards it).
But more jarring than that - jarring enough that I had to convince myself to re-open Zed and try it again, is the appearance. I don’t know quite what “design decisions” were made but something about it just gives the feel of an early 2000’s “desktop in a browser” where nothing looks/behaves quite as it should.
It’s hard to comprehend but somehow IDEA, even being cross platform with a Java UI still feels more like a native app than this does. Maybe with tweaks to the various settings it’s possible to make it fit in more? I don’t know, but the defaults definitely don’t feel anywhere close to a native UI, which doesn’t bode well for that being possible IMO.
The collaboration tools look amazing!