I think linux + osx combined is probably developer majority. I'm assuming most Windows development is .NET or Unity based. Over the past nine years, I've worked primarily with Node, Ruby, and a smidgen of Java and no employer has issued Windows machine. It's in sharp contrast with the start of my career where I was in VB6 and C# where I only worked with Windows environments. Could be confirmation bias, though.
Windows is a great platform for developing any language or platform, not just .Net. Personally I think it blows macOS and its dated tools out of the water in any category
Stackoverflow found that Linux and macOS is the slight majority for professional use and the minority for personal use with developers (with the caveat that the total professional use of all categories is >100%)
Just curious what tools are you missing on MacOS or Linux that are found on Windows?
I have been on MacOS the last 8 years or so but before that was all Windows and Linux. I prefer MacOS now but curious what I am missing. My colleagues that are using Windows machines all use WSL with dev containers so really just using Linux under the hood.
My experience is that pretty much everything is cross platform these days. I don’t do .Net or game dev though. Just Go, Java and some NodeJS these days.
Yeah, but with Windows GUI along with fractional scaling, device, and etc support haha. I've developed on both bare Linux and for years in Linux VMs. Saying Windows+WSL is "really just linux under the hood" does this setup a massive disservice. It makes me smile every time I type WSL into the terminal lol.
Yeah Linux desktop environments are a bit of a mess but OP specifically called out MacOS as well. Once you add Rectangle it is a solid DE in my opinion. Also it is Unix/linux compatible so kind of the same beast with good GUI/hardware and *nix terminal.
Was just curious what Windows only tools I am missing out on.
I agree. Long time Linux engineer who prefers Windows to OSX as a desktop OS. Currently use a Windows workstation with WSL and VSCode as a daily driver. I feel this currently gets me the best of both worlds(Windows/Linux).
"We will let you know when windows support is under development. The Zed team isn't taking feedback on when we start on windows support, nor why we didn't start with windows.
The amount of people on each platform isn't relevant, as it starts with the base assumption that more people = better to the Zed team. Growth driven development unlikely to lead to a resilient, high quality product long term."
Haha, well they will get lots of feedback they don't want to take.
A company like Jetbrains can do this to an extent due to existing products fueling long term R&D efforts before they bare fruit. Interested to see how this outlook holds up as the runway burns and investor pressure increases from that cool 12.5m they raised last year.
From what I can find, the used OS of software developers is 61% windows, 46% Mac so this argument has no weight on the considerations the team should make Å— it’s essentially a toss up.
Even if it weren’t a toss up and significantly more devs used windows, deciding to target windows based solely on OS market share is one of the worst things a small dev team with finite resources could do. It’s just not a compelling argument at all.
It is, but barely (windows is @ 61%, macOS is at 46% based on the numbers I found). And even if we ignore that, number of potential users is far from the only factor you’d consider when choosing the first platform to target for a new project. And then, ignoring that as well, just because an OS has more potential users in total, that doesn’t mean it has more potential users of your editor.
There’s lots of reasons to not choose windows as a first release platform, and it being ‘the most common development platform’ isn’t a compelling one, especially for a small team with finite resources.
These days that's a lot less of a concern than it used to be. It is a lot of up-front work to facade e.g. Metal, Vulkan (and even D3D12) but it's much much much easier than back in OpenGL vs D3D9/10 days.
Most of the general concepts are more or less the same across them all these days. The "shapes" of the APIs are very similar.
A texture is a texture is a texture. Same for a vertex/index/uniform buffer, vertex/fragment/compute shaders (notably not geometry, but you can just use compute), etc.
I'm not in the graphics world at all, but I read this lively discussion last week (post [0], discussion [1]) that made me think the situation was pretty messy. Is it maybe not as bad as that makes it appear?
I'd recommend wgpu. It should be a fairly easy migration from Metal, as Apple has been actively involved in the design, and there are similar concerns for developer experience (unlike, say, Vulkan).
Unfortunately, graphics is in many ways the easy part. Really excellent integration with system menus, preferences, keyboard, input method editing, all have more variation across platforms and a still-evolving story of solid Rust abstractions. Lately, we've decided to try joining forces with the winit project to see if we can get those problems solved well.
“Please don’t do it like a 4x4 truck, do it proper, like a bicycle” — there is some overlap between those things, but for people who are actually making full use of the former, the latter is not a useful suggestion
I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
More generally, targeting another project's complete featureset is often a great way to get mired down in the wrong details. Unless you can afford to do a proper cleanroom -- then, you'll be able to at least match the performance and useful abstractions used in the original.
> I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
Remote SSH + Dev Containers and their seamless integration (even stacking one on the other) are the only features that keep me using VS Code. I would love to see the full implementation of these in an editor as fast and light weight as Zed.
How exactly are these features present in your workflow? I honestly struggle to think of when I'd ever use this.
Fwiw, I do a lot of infrastructure-as-code, full stack, and systems programming.
I usually have a split screen (editor | terminal) or two terminals on the side, and exec into a container, or use devenv.sh.
If I _really_ need to modify files in the container as I dev and a "make" doesn't cut it, I usually just run podman with a -v mount. Similarly for remote machines w/ sshfs, though I try not to.
Devcontainers are amazing for getting a consistent environment set up on multiple computers on multiple operating systems. I was in this situation recently with a new colleague who was using a very locked-down Windows computer, and it was really convenient for the "you must install" list to be Docker and VSCode only. It's definitely not ideal - it adds overhead on Windows and Mac, there's occasional networking issues, and I don't have all the creature comforts of my usual shell - but it's very convenient for what it is.
Similarly, editing code in-place over SSH rather than rsyncing back and forwards is very useful for certain types of embedded development. I worked for a while on sensor systems where a lot of the logic was handled by a Python webserver that couldn't really run without access to the sensor data it was using. Developing entirely locally was therefore difficult, but developing on the machine was also painful because it didn't have the right tools. So we'd work locally, and then copy the Python files over every so often and restart the server. At the time, I don't think VSCode's remote stuff was working as well, but I believe now it's a lot better and could have handled that situation well - edit everything in-place, run it immediately, but still have the power of you local development machine available to you.
> I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
Wha...? This is a killer feature. I'll put up with a lot of crap to use it. That doesn't mean I wouldn't switch to something nicer in other ways if it also offered this killer feature.
It's hard for me to understand why there are IDEs under active development not trying to offer this feature. It is so much better an experience to have the network split into the proper place: between the UI and the heavy computation. Having the UI too far away undoes whatever responsiveness work has been done and more. Having the heavy computation too near means it's hard to develop and test the far environment, take advantage of its compute, etc.
> the people who make "full use" of vsc-over-ssh are satisfied with vscode,
almost all my coding these days is over vsc-ssh. if zed supported sshing into a remote host and into a docker container as seamlessly as I can in vscode, Id switch immediately. The performance of the ui in zed is so much better. I'm a bit sad I can't switch with its current feature set.
The former is bad design, it has no gradual fallback and works in a terrifying way. It pulls binaries from MS servers and runs a headless vscode instance on the remote machine.
You are dead in the water if you target a machine/architecture it doesnt support.
You want to target FreeBSD? Linux on POWER or RISC-V? An old (ARMV6-TDMI) Raspberry Pi? Sorry, no remote work for you.
I'd very much prefer something that works seamlessly in 95% of the use cases and makes me do some work or look for an alternative for the remaining 5%, than something that makes me do work in 100% of the cases.
Bikes likewise have advantages that 4x4s lack. If you mean to imply everyone ought to be satisfied with the 4x4, and not ask for a bicycle: no. We can have both.
I don't think I would like that. I haven't been impressed with the experience of running GUI apps within WSL. Weird window controls/resizing, compositing, and font rendering issues would be a hard blocker from using this as probably the second most important app on my computer.
Hey! Thank you for this cool editor! However, has it been written with cross-platform support in mind? Otherwise, porting from mac to linux could be rather painful and time-consuming... Will there be an ETA for us linux users? I saw it on the roadmap [0] but without an ETA.
Their UI framework is also rendering via the GPU, so it's more likely they'd wrap it in a GTK/Qt/whatever window and then just render accordingly. You don't need GNUStep for it since there's little "mac"-isms you need to cover.
Speaking of Linux, are there any other editors we can use today? I tried to look for one recently but couldn't find anything. (edit: I mean collaborative editors)
Looking for collaborative editors in particular. Two people editing at once, on different computers. Each person has their own copy of the file, on disk.
Authoring Latex documents. I want a non-browser alternative to Overleaf. When the paper is close to done, me and my colleague are on voice call, editing the same file. But we both want to be able to compile it to PDF, to be able to see the figures.
I was particularly looking for collaborative editing; two people editing the same file at once and each has a local copy of the file so they can run the code. Perhaps one could use a normal editor for this if there were some underlying command-line tool and/or plugin to do the actual file synchronization. Do you know of any?
Precisely, I'm looking for collaborative editors. Thanks for the suggestion, I hadn't seen this one.
Unfortunately, it seems that this plugin only shares the editor window and does not keep a local copy of the files. I was wishing for something that would let both sides run & compile the code during the editing session, without having to stop for git push.
https://github.com/MicrosoftDocs/live-share/issues/3524
Jetbrains allows both users to execute / debug but it’s all on the host machine.
What you’re talking about sounds like you should do an rsync script that watches file changes, but seems like a good way to constantly be breaking the other persons workflow.
git solves these problems- feels like the right tool. But maybe I’m missing something about your workflow
Gobby is mostly dead but still works. Win/Linux; macOS builds have gotten harder now that it's been about 3 years since the last release: https://gobby.github.io/
EDIT: It's apparently on Macports as of quite recently, though the port health for recent macOS releases looks bad.
Worth noting that, like many immediate mode UIs, it seems to not integrate with OS accessibility infrastructure at all. That means any UI built with it will be a black box to anyone who needs accessibility tools like VoiceOver, text magnification, or semantic navigation.
It should be. There's AccessKit integration in egui (the most prominent Rust immediate mode GUI implementation) now, thanks to Matt Campbell's work. I would welcome GPUI and Zed adopting that, and I'm sure Matt can offer help in getting it integrated.
Zed developer here, I've actually looked at how to implement AccessKit in Zed, though I couldn't find a quick way of jumping into it beyond 'read the egui PR' at the time. If anyone wants to take a stab at it I'd love to help out and make it happen :)
Hi, lead AccessKit developer here. Sorry I haven't written much documentation yet. For now, the best way to learn how to use it is indeed to study the egui PR.
It is, Flutter (which also draws all the UI on a canvas) already does that - it’s called AccessibilityBridge. The way it works is they hook into the native accessibility system and create virtual accessibility nodes with the same size and coordinates where the “widgets” are drawn.
I think it’d be useful to create some common AccessibilityBridge-like library since more and more UI frameworks are taking the same approach as Flutter and GPUI.
we absolutely want to make accessibility work – hopefully open source will give us a bit more wiggle room to have folks help us figure some of it out as well.
The benefit as a viewer is you can drive navigation on your own without asking the presenter to go to a certain spot. So the presenter can be discussing a problem or a function, and you can investigate/gather context without interrupting them, among other things.
I personally can't live without it, and am almost annoyed when folks aren't using VSCode/have no way of doing a live share. Screen share sucks.
For example, in vscode if the sharer start a http-service the port can be port forwarded through the session so anyone in the session can interact with the service.
Maybe I'm opening the lid to the industry's best-kept secret, but every team I've worked on used SSH with a shared tmux session for pairing. There are probably more complex tools that cover every use case, but I never encountered much demand for one.
This looks really cool, but I have a suspicion my employer would be against external connections. Any distant plans in the future for an enterprise/onprem license?
I only joined Zed, the company, a week ago, so take this with a grain of salt, but:
I've never really used real-time sharing (tried VS Code's Live mode and other apps) for longer than just 1-2 attempts, but at Zed things are different somehow. Everybody is constantly available in a channel and people just hop in or out. In the last 7 days I spent 3-5hrs every day pairing with others, using Zed's live mode. No video, only audio and sharing code in Zed (no video was weird at first, but now I think I'm starting to get used to it?)
IMHO it's a combination of culture and technology, but when the mix of that is right it really feels game-changing.
That may depend on what you're trying to do. If you are figuring out something tricky, then lots of quiet head down time is what you need. Every interruption hurts when you are concentrating.
However, a lot of the time is just figuring out how to glue together multiple systems. Being able to pull in various people to interface little bits is priceless. There is no flow here, only collaboration.
I think what’s nice is that it’s frictionless. If I can just click a button to see someone’s editor, then there’s no dance with sharing screen, I can open files I need to see, etc.
With standard sharing you always end up trying to direct people to do things instead of just showing them.
Honestly, it's pretty cool in my experience; in VSCode everyone gets their own "client-side navigation" so while you are typing something, your coworker can go look up a function for you in another file, etc. Even though they exist in "your" instance, they still get Go To Definition, Find References, type-on-hover, etc.
Realistically though it doesn't replace every instance of screen sharing, for me. It's also cultural to some extent I guess. For things like debugging or being intro'd to a new codebase, I think it's great, though.
As a senior engineer, it really helps when helping junior engineers. When I'm on a call and we're sharing screens it gets really annoying having to tell them "no, go up. Go up, all the way up, the button at the top. THE TOP"
This. The worst thing is that I get mad at them for not doing what I want them to, faster, when the tooling and my crooked explanations are at fault, not them. Not that I mention that out loud, but sometimes I feel ashamed for those feelings.
Having real time collaboration that works so seamlessly as Zed apparently does would really get me to consider switching IDEs!
I'm using VNC for coworking/mentoring sessions and it works very well for us (it's lower latency, higher frame rate, sharper picture than typical screen sharing, and allows both/all sides to interact with the session and use the mouse pointer to point to things). We're using Linux on both the server and client side. There's a full desktop on the remote side, to fully interact with that (to have key bindings go to the server instead of the local desktop) the client needs to be made full screen. Latency isn't really an issue even between central US and Europe.
I've automated the set up of a Debian server for the purpose using[1]. There are some details on how to run it and how to set up the client side here[2] (probably slightly outdated). Feel free to mail me about it.
You can share terminals in live share and even share servers etc. I’ve had no issues and I’ve built multiple teams that are very collaborative at this point. Dozens of engineers
I've greatly enjoyed pair (and trio) programming with friends using it (vscode's version of this) on side projects. For the most part I'm not sold that pair programming is an efficient way to program, but it's a nice social way to program.
If you're going to do it, especially remotely, it's really nice to have your editor support it instead of just using screen sharing.
I've never really pair programmed - I've worked on joint projects, of course, but collaboration occurs over discord/github. I'm intrigued - what does this actually consist of? Does one person write one function and another write the next while you chat about what needs to be done?
We tend to work on one 'thing' at a time. Sometimes that means we're both/all on the same few lines of code writing a new function - at which point one person is usually doing all or nearly all the typing. If you then need to go define a constant somewhere else in the code or something the other person does that so you don't have to pause. Other times one thing involves code in various places because you're doing something like changing what arguments a function takes, or fixing compiler warnings, and we do spread out and handle instances of the thing we're fixing as we come across them.
Lines of code per second it's closer to one person than the 2 or 3 people involved, but the quality of those lines definitely improves a bit as people spot each-others mistakes/less than optimal choices. (Edit: But I'd emphasize we're doing this for fun, not to maximize productivity)
ime, real time sharing works best when there’s shared context. otherwise it’s essentially an artist rendering a public performance in the presence of an audience. unless you derive some joy from watching people code it could get frustrating real fast.
It is such a game changer for me. Pair programming or multi pair programming if you will, suddenly has 0 barriers. Including others in your session with no overhead changes things completely. Before I would rarely include others in my processes because it cost too much. Now I'll do it whenever... Switched from sublime and got my coworkers macs just to be able to use zed and work in this way.
It is extremely important it works fast and fluid, and zed is the only one I've tried that nails it. There are still a few things that needs tweaking wrt. undo history, but I'm sure they'll get that to feel intuitive in the end.
When a person tells another person "you need to do X" or "I did Y and it didn't work on my machine", they sometimes ignore important details due to their own curse of knowledge. That's when I need a shared terminal/editor so that both parties know exactly what is happening.
I don't frequently share terminal/editor but occasionally need to do so, maybe a handful times a year. Most of times when I tell a new colleague "hey, connect to my tmux socket by running this command / opening this link", they were amazed and thought it was magical. I am not a Zed user but it's always welcome to see people making effort to make pair programming easier for everyone.
Now, I don't know how I would feel if one day my colleague send me a sharing session link that can only be opened by a particular editor.
It sounds nice in theory but I've noticed I cannot focus when somebody else is looking over my shoulder. It could be useful as a way to occasionally show somebody around the code base though.
I think it's mainly the intensity of the sessions. You've got someone on the other end of a call so you don't really chill and take it easy. Creates some urgency to get the thing done and you're just a bit fried by the end.
Tangent: I wish we could standardize real-time code sharing the same way we have with LSPs. It is sad that if you want to pair-program, both have to be using the same editor. It really makes more sense to have one standard format so that one person can use VSCode and another can use Vim or Zed. If you want to make it standard practice you have to enforce everyone to use the same editor, which sucks.
Already at work some people have complained that I don't use VSCode for code-sharing.
With Neovims headless capabilities, I am hoping for the day every major IDE and editor has first party support as a front-end for Neovim, and then any Neovim plugin just becomes universal across all IDEs and editors. Which... you can make Neovim plugins in almost any language, I've seen bindings for "lesser popular" languages.
I'm not even a vim guy, but if JetBrains finally adds front-end support for Neovim, I might just become a de-facto VIM guy. Instead of emulating vim like they do, they could just literally support Neovim as a back-end. I'm still surprised nobody at JetBrains has put in effort into this.
Yet another front-end I think needs it. I am looking at both Sublime and JetBrains because I use both. Notepad from Windows by Microsoft will support Neovim before both at this point (I was shocked to find that it supports tabs, and lets me keep unsaved files open just like ST).
Real time document editing and sync is actually a tall order. To make it editor/tool agnostic you'd need some kind of overlay fs + first/third party support in the various editors (as most editors don't hot reload file changes; they expect the files they have open not to be changing underfoot).
After almost a decade it never got off the ground. And while it might address the core problem (collaborative editing), that still leaves the ecosystem problem: fuse mounts, first/third party adoption in the editor or via extensions/plugins. Arguably that's drawing the rest of the f*** owl.
Yeah I don't know what work is involved to build something like it, but not having it def. leaves the editor ecosystem in a vulnerable position for monopolistic practices.
I remember listening to a changelog episode about zed ages ago. I liked what I heard about but that fact it's not for Linux just now and I don't have any friends to code with means I'd likely not use it.
Zed developers, if you read this, please get inspired by Cursors "Fix it" button that you can click on any error. It simply starts a new chat with the code context and error message, suggesting possible fixes.
I'm currently learning Rust and this is such a powerup that I honestly wouldn't know how to learn anything without.
> 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.
https://zed.dev/
Seems like that ship has sailed. Maybe it's a plugin already or could be in the future, but that's not on GP's suggestion.
This made me chuckle. Then at the same time I find it disheartening that privacy is currently seen as an enthusiast position rather than the default. I really dont mind the idea of these anti-privacy things being included as long as I have an option to turn them off before running Zed for the first time.
To use them you’d need to already have a copilot subscription, and the GPT-4 thing apparently requires you to deliberately invoke a command. I’d say it’s pretty safe by default.
I’d say the ship is in port but ready to sail. Before this does anything you have to provide your own API key. So it’s off by default. It’s just the button that is there.
Beyond "is it on by default" (due to data privacy concerns) whether something belongs in a "core" editor or in a plugin is a whole separate can of worms - moreso if the core editor starts shipping plugins. There is someone who reads that agreeing it means the editor should be just a plugin store and if you want font hinting, syntax coloring, tabs, terminals, smooth scrolling, and so on then download them yourself. At the same time there is someone who reads that agreeing it means the editor should have anything possible related to working with text but if you want to play a video while you code the plugin system should allow you to do that in a pane. Neither are really right or wrong about what should be a plugin, it's really a matter of what the tool wants to optimize for out of the box.
if you're a developer and dependent on mac you're probably building "the next big saas" in "the next big tech company" which will fail in few years.
a developer tool should be available on ALL platforms and specially Linux, if a tool is not available in linux no one will adapt it no matter how shiny it is.
"Ah yes Linux , the classic developer os"
it's not available on WINDOWS and on LINUX.
which is like THE MOST USED PLATFORMS ON THE PLANET.
You apple fanboys try to find excuses for everyone
What a weird statement. It's beautiful! You don't need comments, just read the code. No need to litter code with ambiguous language. The only place a comment fits is if the purpose is not clear from the code.
Emacs is great many things, but fast it is not. Nativecomp improved some stuff a bit and there has been other improvements lately too, but ultimately the core of emacs is built for flexibility, not for perf.
A lot of things, from limited keybinding support due to terminal limits, unergonomic extension language, very poor default setup, lacking good GUI, poor multicursor support, lack of core Zed's feature - collaboration
Those features are a worse substitute for that awesome generic UI mechanism called immediate visual feedback (for the same reason Helix's visual-first mode, which unfortunately neovim also lacks, is better)
The polite thing to do if you have a feature you think would make a FOSS project better is to submit a feature request first. If the maintainers decide they won’t support your feature quickly enough or at all, then fork it. GP did the right thing here
I'm generally a big fan of zed and have been using it for 60%ish of my dev time for 6 months or so. A couple of nice things to note:
- It really is remarkably responsive,and makes one really notice how UNresponsive everything else is. I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising. VSCode never felt slow on my macs until I started using Zed.
- They seem reasonably responsive to feedback. There was some contention around how search/replace was initially implemented, and the current builds have something much more usable IMO. I'm not sure how much that was driven by community feedback, but the changes were great.
- The debug syntax tree mode is a really neat feature that I think demonstrates how much more advanced zed is under the hood than older editors that are doing syntax highlighting via regex.
There are a few downsides that I'm hoping get addressed soon:
- The collaboration workflow/security isn't very clear to me. You sign in via github (no other option???), there are 'contacts' (I guess these are github usernames?), and 'channels' (where do these live? on zed's servers?). I would really like to know if I can self-host the chat server and use a company oauth provider rather than github. If the diffs being passed around are going through zed's servers, that may be a showstopper for the company I work for as well. If they're p2p and encrypted, maybe not.
- I would love to see ollama integration. This + continue is the only reason why I spend any amount of time in vscode now. There's an issue for it here: https://github.com/zed-industries/zed/issues/4424
I’m still using Sublime for the references. Without fail I can load up any version of an application including older rails apps sub 3 and it instantly has context. I can easily jump to definitions and even on hover will show me where they are being used. In the context of foos.bars.baz I could easily infer where bars is defined. Seems to work across languages, doesn’t matter if it’s js, ruby, in an erb file it just works. Not to mention the flavor of vim feels great.
VSCode complains and I’ve got to hardcode an alternative absolute path gemfile for Shopify’s LSP to work. It also feels clunkier, even on powerful machines.
If Zed can give parity with Sublime on the references (I just tried and it did not seem to find any references when clearly bars was there) might be an interesting change. Considering it’s open source now I’d happily switch as it does seems super quick.
I might also be old-man yells at cloud and the copilot integration doesn’t appear important yet, but current sublime support is pretty poor for it and seems like that’ll be a thing more and more.
I switched _to_ VSCode because Sublime was occasionally so slow at times that it was unusable. It was very fast 95% of the time, but then I'd `git pull` on a very big repo and my machine would become unresponsive while Sublime did...something.
I think on Linux at least it freezes due to watching too many files using inotify to update its sidebar. I wish there was an option to disable that. Same thing happens with Sublime Merge. It’s unusable on giant repos.
Sublime Text 4166 has some major improvements in that area, previously ST would check every file in the side bar for changes in order to update its index but this is now done incrementally.
This is very strange to me, because I have always used Sublime Text for super-giant corporate repos, and always found it snappy compared to vscode. Wonder if it was a specific usecase or something...
Every little while, I try to make vscode my main editor, because I enjoy all the features. I always switch back to Sublime just because VSCode's slowness bugs me.
Haven't really tried Zed in earnest yet, though, because of no custom LSP support.
That’s where I landed after v14 with LSP support came out. It’s so nimble! And extensions with shell scripts and CLI programs is right in my wheelhouse.
Not in 15ish years and at the time I think I had a 5400rpm hd, so that probably limited any perception of sublime being noticeably faster than other editors I was using (geany, kate). I don't doubt that sublime is faster than vscode today, but the vscode ecosystem is a pretty nice place to be and probably worth trading some speed for, especially on a nice mac where the trade off is probably small. Zed might be even better however.
Or vim, I suppose. It's remarkable how slow VSCode actually is, but I still use it because I hate configuring vim and packages always break when upgrading, it's honestly worse than npm.
Updating vim packages can be a nightmare if you don't vet your plugins and generally install stuff "just in case I want to try it out later". If you aren't using a plugin with any regularity, delete it.
I don't know what vscode's plugin architecture is like but I imagine it's just that Vim's is extremely powerful and, you know, with great power comes great responsibility and all that. Unfortunately, many vim plugin authors are not responsible, or don't realize they aren't being so.
> older editors that are doing syntax highlighting via regex.
I mean, Emacs, which can probably be considered the oldest code editor at this point, got built-in tree-sitter (which is what Zed uses under the hood) support in the last release. So it's not really related to editors being new or old
It's not just tree-sitter that makes zed feel snappy.
If you're using a reasonably fast language-server, which rust-analyzer apparently is (I didn't know this using vscode), the autocomplete & intentions feel instantaneous.
I think the team has learned a lot from previous editor implementations (they were the core team of atom that was notoriously slow), and so they've had an opportunity to do a lot of stuff right.
FWIW they also are the team that originally wrote tree-sitter.
The quickness feels more like it's in the core of the editor. I was shocked how much it impacted the editing experience when I tried it in early beta.
> If you're using a reasonably fast language-server, which rust-analyzer apparently is (I didn't know this using vscode)
Some more anecdata to back this up: initial workspace load in VScode I can watch RA tick through its progress. Clean and boot up Zed and the same process is so fast that it’s almost unbelievable.
I've been impressed with the C++ clangd language server snappiness in Zed compared to both CLion (my old favorite) and Emacs (apple of my eye for 2.5 yrs).
I always thought the major slowness was coming from clangd itself, so I'm surprised and impressed to see that Zed appears to be quicker on this front. I might be using Zed as a 'second opinion' editor because of this.
However, now I'm used to the infinite customizability and coziness of Emacs, it's going to be hard for me to move across to Zed permanently.
As I understand, tree-sitter implementation in Emacs is currently more like a foundation for development / adoption by plugins, it's not really usable as-is today.
Emacs already had tree-sitter before 29, just not built in. You can do syntax highlighting[1] and structured editing with it.[2] What is missing for it to be usable in your view?
Your understanding is outdated/incorrect. Already a number of major modes have corresponding ts modes and I use them daily. This includes C++, Rust, Python, yaml, toml, json, Java, typescript, dockerfile and cmake.
True not every major mode has treesitter in the official release but I’d hardly call the above “not usable”
I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot.
But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.
There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck: I think it’s a front runner there. But I can’t imagine switching my main axe up with a holy shit moment a lot crazier than tree-sitter in 2024 and not having the render loop be in JS.
I mentioned it above but I’m flattered by your interest (and remember your username as someone serious): my old dots were ok and are floating around but we’re putting together a multi-editor curated setup for good defaults and an emphasis on good, available-weight models as first-class citizens.
It’s a 404 until I get to an RC, but aiming for March 1st on “hyper-modern.ai” for all MIT on emacs, nvim, and vscode.
How do you get a reasonably fancy Emacs to start up/open files quickly? Every time I try to get into EMacs after adding a few packages it becomes painfully slow to open a file for editing. Then I try to understand Emacs server, then I fail / give up and go back to vim.
Emacs server is quite straightforward. M-x server-start in a running emacs, then emacsclient <filename>. emacsclient -c if you want to open the file in a new window, or emacsclient -t if you want to open it in your current terminal. C-x # when you're done editing the file.
I've been using emacs as my main editor for years now and don't find the startup speed to be an issue - to the point I've never bothered with emacsclient:
I was about to answer "Use emacsclient", but then I realized you can't be bothered to configure it. For me, putting "(server-start)" into .emacs was always enough, but YMMV.
1.4 seconds for 100 packages, half of which are on probation? My (and soon `HYPER//MODERN`'s) package set is under heavy construction, I'll be sad if I don't get it under 300ms including loading and rendering a logo at 6k from a cold disk which that was.
Rust is a perfectly good language for writing tight code, but those `emacs` inner loops have been tuned by hard-ass pros for 30+ years in straight C, which is plenty fast too. Even the best Rust code doesn't have that kind of tuning in.
With no intention to push back on Emacs being highly optimized, age of an application is not an accurate proxy for level of performance. If it were, grep would be faster than ripgrep. New software can apply optimisations discovered over the previous 40 years, and leverage architectural designs with different assumptions, like the GC limits in Emacs discussed elsewhere in the comments. Older applications can apply those same optimizations, but it's not a given that they will, and changing their architecture can be daunting, for sometimes unknown benefits.
The way the other guy said. Then it breaks enough times, you give up, and switch to Helix. Nothing snappier out there (vanilla Vim included) and it comes with all the goodies you'd install 100 packages for (DAP, LSP, treesitter, sane default configs for dozens of languages)
To each their own, but for a hardcore Emacs user (wrote a number od my own plugins) that actually tried and couldn't seriously adopt VSCode for more than a few months, Helix was such a nice surprise + change of pace. Worth giving it a shot if you're caught in that gap.
Is there something that approximates org-mode outlining? I don't need all the other stuff org-mode does, but just the simple outliner functionality combined with all the other Emacs stuff is my golden handcuffs.
Not that I'm aware of just yet, unfortunately, so might be a good reason to stick around. For me the switch coincided with jumping on the zettelkasten train and I haven't looked back since. I miss some org mode fratures but constantly `org-refile`-ing I can do without.
It is a great sentence, and that holy shit moment is coming: when JS gains all the expressivity of tree-sitter and uses it to render code more beautifully than it has ever been rendered before.
People are asking what settings would be useful to tweak. Check out the following:
- gcmh -package and gcmh-mode and/or gc-cons-threshold variable (former should take over the latter)
- read-process-output-max
- jit-lock-defer-time
- package-native-compile
Doom Emacs sets gcmh in its initialization so tweaking that might not be needed there. You may still want to touch gcmh-high-cons-threshold and gcmh-idle-delay-factor. Here are mine currently:
I've done nothing scientific to check out if these help at all, though, so take them with salt. With and without these, emacs seems quite sluggish at least on a Macbook, in certain modes. On Linux things seem to be a bit better.
The thing about gc-cons-threshold is that, too low a value and it will collect garbage too frequently. While a high value will drastically reduce frequency, but then GC pause will be big and you will likely feel whole system freeze and stutter when it happens. For me, 1GB is too high because I sorta notice the pause, I set it to 32MB but completely disable GC when minibuffer is active:
Anyway, I also have these in my init (I nicked these from Doom which I don't use but they have done a lot of work to dive deep into these things, mostly around what improves start up but the following might help in general):
;; if you don't use RTL ever, this could improve perf
(setq-default bidi-display-reordering 'left-to-right
bidi-paragraph-direction 'left-to-right
bidi-inhibit-bpa t)
;; improves terminal emulator (vterm/eat) throughput
(setq read-process-output-max (* 2 1024 1024)
process-adaptive-read-buffering nil)
(setq fast-but-imprecise-scrolling t
redisplay-skip-fontification-on-input t
inhibit-compacting-font-caches t)
(setq idle-update-delay 1.0)
Most examples you'll see of `straight.el`/`use-package` configurations will have some version of: `(use-package something-cool :ensure t :config ...`. The `:ensure t` clause will cause it to fall back on `package-install` in the event it's not bolted into your local Cargo-style-own-the-world-and-dont-break repo mirror. Disks are big, it's like the right default now.
But if you've got a package that's mis-specified in terms of where on `github` or wherever that `striaght` is supposed to find it, you can find it tapping `elpa.org` on the shoulder at a time when the UI thread is also doing blocking network IO.
The `Messages` and/or `straight` buffers will have warnings about this, so it's fixable to find the offending package and it'll stay fixed, but in fairness what you're describing is possible.
Both @darthrupert and @natyrys on the thread have said most of what I know. It's a little machine dependent to get the true sweet spot, but raising it from the like, megabyte (slight hyperbole) or whatever that it defaults to is the 80/20.
i got annoyed by emacs gc pauses and just disabled the gc completely (i think). haven't noticed any downsides so far. i'm in emacs all day...
;; don't garbage collect based on cons count
(setq gc-cons-threshold 10000000000)
(defun garbage-collect (&rest args)
(message "trying to garbage collect. probably you want to quit emacs."))
something i love about emacs is everything is implemented in the same abstraction (of a "buffer of text"). so i can manipulate and move around an embedded terminal in the same way as a normal file, etc.
playing briefly with Zed it seemed like the terminal was a totally different "thing" than a normal file; i couldn't run the same text selection operations, couldn't split the window vertically or horizontally, etc. to me that loses a ton of the benefit of having a terminal in the editor in the first place.
still, it's a very interesting project. i have a very love/hate relationship with emacs, so i'm always interested in alternatives...
(setq gc-cons-threshold (\* 100 1024 1024) ;; GC sometime after allocating 100Mb
read-process-output-max (\* 1024 1024)
company-idle-delay 0.0 ;; company completions should be fast
company-minimum-prefix-length 1
lsp-idle-delay 0.1) ;; clangd is fast
(run-with-idle-timer 2 t (lambda () (garbage-collect))) ;; Trigger a GC after 5s of idle time
This is something of a hack of course, but it works & memory is cheap. You might want to push the GC threshold back down after emacs startup - a GC that fires early is a GC that does less work per invocation & is therefore less likely to cause perceptible stutter.
The, uh, GNU folks, are a little conservative in some ways that surprise the mainstream developers. But there are always flags for it. Well, except stupid-ass dynamic-linking of `glibc`.
> are a little conservative in some ways that surprise the mainstream developers
Conservative is one thing, but having the default be something that's detrimental to 99.999% of your users in 99.95% of situations feels like bad defaults/design, not being conservative. My worthless 2 eurocents :-)
Most language modes have a `foo-ts-mode` now that uses `tree-sitter` to get a perfect* AST in the absence of errors, and almost always the most reasonable one in the presence of errors. `tree-sitter` is amazing, a real feat.
It ships with 29 and it's work to find `brew` or `apt` or `nix` or anything giving you less than 29.1 these days.
Have you tried a recent version? 29.1 is dramatically more accurate on everything from syntax highlighting to indention than VSCode (IMHO, they're probably either using or working on using `tree-sitter` too, those are serious people) or JetBrains stuff (they're working on their vscode clone more than IntelliJ these days).
I only use `nvim` for commit messages and stuff the last few years, but AFAIK it has all the `tree-sitter` stuff too.
If it's the sloppy naming of `c-basic-offset-this` vs. `py-indent-that` or whatever (I don't even remember), try a good baseline distro like Doom and tweak from there.
>>But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.
That explains my whole experience with Emacs. More time is spent in making Emacs awesome than actually doing my work.
> There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck
Basically AstroNvim or Doom Emacs. Not a huge fan of Doom Emacs but AstroNvim got me to drop my main editors (Sublime + Atom) and I basically only use AstroNvim.
One enormous advantage of Nvim is that I can run it anywhere. I run it on a Linux machine, a Mac, and a Tablet (w/ Termux) extremely easy (just clone my dotfiles, install nvim, and that's it).
I use this extension: https://continue.dev/ their docs are pretty good, but it's also evolving pretty rapidly. For example, you no longer need to run the continue server yourself, it's entirely self contained in the vs code extension. I believe the docs still refer to how to run it manually.
I work for a pretty conservative company re: GAI, and the ollama + continue combo made it through legal.
VSCode has always felt incredibly slow to me, even compared to e.g. pycharm. , which I have always assumed of be otherwise roughly comparable. VSC’s lag in basic code inspection and linting became so annoying I had to switch off it. We’re not talking seconds, but maybe tenths of second lag, for everything at all times. I understand plenty of people love VSC, but honestly I have never been able to share that enthusiasm.
Yep. For some reason, suddenly, vscode became painfully slow on my decently spec'd machine; 3 to 7 seconds per keystroke just to analyse the file to show intellisense tooltips.
Yes, that was in seconds per keystroke.
The irony is that I moved from neovim to vscode because setting up intellisense in (neo)vim was always a hassle and never worked quite well. Pylance seemed too attractive not to give it a spin.
Now the lag has as mysteriously diminished, but still vscode is very far from being as snappy as (n)vim.
Ive been wanting a syntax-tree-viewer for months, to help me learn functional languages where figuring out what is even going on syntax-wise in the exmaples provided by tutorials keeps being an issue for me.
Does anyone know of a way to see a syntax tree for any given snippet of code for any given language? I'd try Zed, but I'll have to wait for Linux support.
I am not sure what debug syntax tree mode does in Zed, but if it's about tree-sitter generated syntax tree, you can see that in Neovim or Emacs (assuming you have major-mode/grammar loaded):
>>I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising.
I really envy people who can sense passage of time between intervals of 5 milliseconds and 500 milliseconds.
My sensibility begins over a second. And to be honest even that is least of my issues. Same with start up time, I restart the IDE only once in a few days. I thinking spending a second or two extra for it is any where in the ball park of what I would call wasting time.
This is really exciting. I currently use Sublime Text 4, and coupled with SublimeLSP, it does almost everything I need. What's missing is good debugger support and UI integration. What's the story like for Zed on that front? I briefly scanned the homepage and did not see mention of a debugger.
This is very nice, I hope we have a windows version soon. And this might encourage Sublime Text to do the same, it's one of the most responsive editor for now, let's see.
640 comments
[ 4.0 ms ] story [ 388 ms ] threadhttps://survey.stackoverflow.co/2023/#section-most-popular-t...
Stackoverflow found that Linux and macOS is the slight majority for professional use and the minority for personal use with developers (with the caveat that the total professional use of all categories is >100%)
I have been on MacOS the last 8 years or so but before that was all Windows and Linux. I prefer MacOS now but curious what I am missing. My colleagues that are using Windows machines all use WSL with dev containers so really just using Linux under the hood.
My experience is that pretty much everything is cross platform these days. I don’t do .Net or game dev though. Just Go, Java and some NodeJS these days.
Yeah, but with Windows GUI along with fractional scaling, device, and etc support haha. I've developed on both bare Linux and for years in Linux VMs. Saying Windows+WSL is "really just linux under the hood" does this setup a massive disservice. It makes me smile every time I type WSL into the terminal lol.
Was just curious what Windows only tools I am missing out on.
"We will let you know when windows support is under development. The Zed team isn't taking feedback on when we start on windows support, nor why we didn't start with windows.
The amount of people on each platform isn't relevant, as it starts with the base assumption that more people = better to the Zed team. Growth driven development unlikely to lead to a resilient, high quality product long term."
A company like Jetbrains can do this to an extent due to existing products fueling long term R&D efforts before they bare fruit. Interested to see how this outlook holds up as the runway burns and investor pressure increases from that cool 12.5m they raised last year.
Even if it weren’t a toss up and significantly more devs used windows, deciding to target windows based solely on OS market share is one of the worst things a small dev team with finite resources could do. It’s just not a compelling argument at all.
About 80% of the developers at my company do the same. Only a few are happy with just Windows.
So, I would prefer if they prioritize Linux and leave Windows as the last one.
There’s lots of reasons to not choose windows as a first release platform, and it being ‘the most common development platform’ isn’t a compelling one, especially for a small team with finite resources.
These days that's a lot less of a concern than it used to be. It is a lot of up-front work to facade e.g. Metal, Vulkan (and even D3D12) but it's much much much easier than back in OpenGL vs D3D9/10 days.
Most of the general concepts are more or less the same across them all these days. The "shapes" of the APIs are very similar.
A texture is a texture is a texture. Same for a vertex/index/uniform buffer, vertex/fragment/compute shaders (notably not geometry, but you can just use compute), etc.
[0] https://www.carette.xyz/posts/we_are_doomed/
[1] https://news.ycombinator.com/item?id=38994780
Unfortunately, graphics is in many ways the easy part. Really excellent integration with system menus, preferences, keyboard, input method editing, all have more variation across platforms and a still-evolving story of solid Rust abstractions. Lately, we've decided to try joining forces with the winit project to see if we can get those problems solved well.
Did you have to build it from source?
Do it proper like emacs tramp so it will connect to any platforms/architectures.
More generally, targeting another project's complete featureset is often a great way to get mired down in the wrong details. Unless you can afford to do a proper cleanroom -- then, you'll be able to at least match the performance and useful abstractions used in the original.
Remote SSH + Dev Containers and their seamless integration (even stacking one on the other) are the only features that keep me using VS Code. I would love to see the full implementation of these in an editor as fast and light weight as Zed.
Fwiw, I do a lot of infrastructure-as-code, full stack, and systems programming.
I usually have a split screen (editor | terminal) or two terminals on the side, and exec into a container, or use devenv.sh.
If I _really_ need to modify files in the container as I dev and a "make" doesn't cut it, I usually just run podman with a -v mount. Similarly for remote machines w/ sshfs, though I try not to.
Similarly, editing code in-place over SSH rather than rsyncing back and forwards is very useful for certain types of embedded development. I worked for a while on sensor systems where a lot of the logic was handled by a Python webserver that couldn't really run without access to the sensor data it was using. Developing entirely locally was therefore difficult, but developing on the machine was also painful because it didn't have the right tools. So we'd work locally, and then copy the Python files over every so often and restart the server. At the time, I don't think VSCode's remote stuff was working as well, but I believe now it's a lot better and could have handled that situation well - edit everything in-place, run it immediately, but still have the power of you local development machine available to you.
Wha...? This is a killer feature. I'll put up with a lot of crap to use it. That doesn't mean I wouldn't switch to something nicer in other ways if it also offered this killer feature.
It's hard for me to understand why there are IDEs under active development not trying to offer this feature. It is so much better an experience to have the network split into the proper place: between the UI and the heavy computation. Having the UI too far away undoes whatever responsiveness work has been done and more. Having the heavy computation too near means it's hard to develop and test the far environment, take advantage of its compute, etc.
almost all my coding these days is over vsc-ssh. if zed supported sshing into a remote host and into a docker container as seamlessly as I can in vscode, Id switch immediately. The performance of the ui in zed is so much better. I'm a bit sad I can't switch with its current feature set.
You want to target FreeBSD? Linux on POWER or RISC-V? An old (ARMV6-TDMI) Raspberry Pi? Sorry, no remote work for you.
They are not an apple and pears comparison...
so, my strong suspicion is that porting gpui is the long pole, since it is apparently just going to do its own gui toolkit
[0] https://zed.dev/roadmap
Nope, it's using Apple's proprietary Metal API.
Their UI framework is also rendering via the GPU, so it's more likely they'd wrap it in a GTK/Qt/whatever window and then just render accordingly. You don't need GNUStep for it since there's little "mac"-isms you need to cover.
https://helix-editor.com/
See also the list of ways of doing collaborative editing in emacs: https://www.emacswiki.org/emacs/CollaborativeEditing
There's a whole list here: https://wiki.archlinux.org/title/List_of_applications/Docume...
Anyway, the VSCode plugin ecosystem is probably your best bet there: https://code.visualstudio.com/learn/collaboration/live-share
Unfortunately, it seems that this plugin only shares the editor window and does not keep a local copy of the files. I was wishing for something that would let both sides run & compile the code during the editing session, without having to stop for git push. https://github.com/MicrosoftDocs/live-share/issues/3524
What you’re talking about sounds like you should do an rsync script that watches file changes, but seems like a good way to constantly be breaking the other persons workflow.
git solves these problems- feels like the right tool. But maybe I’m missing something about your workflow
EDIT: It's apparently on Macports as of quite recently, though the port health for recent macOS releases looks bad.
Hopefully that's fixable :/
It is, Flutter (which also draws all the UI on a canvas) already does that - it’s called AccessibilityBridge. The way it works is they hook into the native accessibility system and create virtual accessibility nodes with the same size and coordinates where the “widgets” are drawn. I think it’d be useful to create some common AccessibilityBridge-like library since more and more UI frameworks are taking the same approach as Flutter and GPUI.
I personally can't live without it, and am almost annoyed when folks aren't using VSCode/have no way of doing a live share. Screen share sucks.
For example, in vscode if the sharer start a http-service the port can be port forwarded through the session so anyone in the session can interact with the service.
Pretty neat and useful!
Anyone can interact with common team servers.
It is one of those things that developer advocates love to show at conferences.
Though you'll have to sign the CLA first :)
I've never really used real-time sharing (tried VS Code's Live mode and other apps) for longer than just 1-2 attempts, but at Zed things are different somehow. Everybody is constantly available in a channel and people just hop in or out. In the last 7 days I spent 3-5hrs every day pairing with others, using Zed's live mode. No video, only audio and sharing code in Zed (no video was weird at first, but now I think I'm starting to get used to it?)
IMHO it's a combination of culture and technology, but when the mix of that is right it really feels game-changing.
This sounds remarkably inefficient?
However, a lot of the time is just figuring out how to glue together multiple systems. Being able to pull in various people to interface little bits is priceless. There is no flow here, only collaboration.
With standard sharing you always end up trying to direct people to do things instead of just showing them.
Realistically though it doesn't replace every instance of screen sharing, for me. It's also cultural to some extent I guess. For things like debugging or being intro'd to a new codebase, I think it's great, though.
Having real time collaboration that works so seamlessly as Zed apparently does would really get me to consider switching IDEs!
I've automated the set up of a Debian server for the purpose using[1]. There are some details on how to run it and how to set up the client side here[2] (probably slightly outdated). Feel free to mail me about it.
[1] https://github.com/pflanze/chjize [2] https://github.com/pflanze/chjize/blob/master/client-side-to...
If you're going to do it, especially remotely, it's really nice to have your editor support it instead of just using screen sharing.
Lines of code per second it's closer to one person than the 2 or 3 people involved, but the quality of those lines definitely improves a bit as people spot each-others mistakes/less than optimal choices. (Edit: But I'd emphasize we're doing this for fun, not to maximize productivity)
Like being in a rally car :)
It is extremely important it works fast and fluid, and zed is the only one I've tried that nails it. There are still a few things that needs tweaking wrt. undo history, but I'm sure they'll get that to feel intuitive in the end.
I don't frequently share terminal/editor but occasionally need to do so, maybe a handful times a year. Most of times when I tell a new colleague "hey, connect to my tmux socket by running this command / opening this link", they were amazed and thought it was magical. I am not a Zed user but it's always welcome to see people making effort to make pair programming easier for everyone.
Now, I don't know how I would feel if one day my colleague send me a sharing session link that can only be opened by a particular editor.
Every typo, every goofy idea (which clearly would not work), etc. all laid bare to see in realtime.
Pair programming was the main reason I left a company after management rolled it out to every team.
We should probably do it more often than we do, but there is a real fatigue after an hour or two.
Already at work some people have complained that I don't use VSCode for code-sharing.
I'm not even a vim guy, but if JetBrains finally adds front-end support for Neovim, I might just become a de-facto VIM guy. Instead of emulating vim like they do, they could just literally support Neovim as a back-end. I'm still surprised nobody at JetBrains has put in effort into this.
After almost a decade it never got off the ground. And while it might address the core problem (collaborative editing), that still leaves the ecosystem problem: fuse mounts, first/third party adoption in the editor or via extensions/plugins. Arguably that's drawing the rest of the f*** owl.
https://floobits.com/
To commemorate, I am running `brew install --cask zed` right now! :^)
I'm currently learning Rust and this is such a powerup that I honestly wouldn't know how to learn anything without.
If people want this just let it be a plugin.
Seems like that ship has sailed. Maybe it's a plugin already or could be in the future, but that's not on GP's suggestion.
What? Who is it for then?
Jokes aside, the US is notoriously dominated by Apple, but it's not the same worldwide.
a developer tool should be available on ALL platforms and specially Linux, if a tool is not available in linux no one will adapt it no matter how shiny it is.
Visual Studio is widely considered one of the best IDEs out there today.
Personally, I use Linux for my work on Linux, what IDE varies depending on my work. JetBrains, VSCode, neovim. But I've used other eco-systems.
I still miss Genera. That thing was amazing.
[0] https://www.youtube.com/watch?v=KMU0tzLwhbE
There are some that does exactly as I mention by mentioning things not in the code like:
```
// Non-generic part of edit, hoisted out to avoid blowing up LLVM IR.
```
Most of the others it does have are even unnecessary. Like this one.
```
/// Returns enclosing bracket ranges containing the given range or returns None if the range is not contained in a single excerpt
pub fn enclosing_bracket_ranges<'a, T: ToOffset>(
```
The description is literally in the function name.
Also this tweet touches on a similar issue - https://twitter.com/transmutrix/status/1750563200708309466
Lapce is another text editor written in Rust but it does not support native IME yet.
- It really is remarkably responsive,and makes one really notice how UNresponsive everything else is. I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising. VSCode never felt slow on my macs until I started using Zed.
- They seem reasonably responsive to feedback. There was some contention around how search/replace was initially implemented, and the current builds have something much more usable IMO. I'm not sure how much that was driven by community feedback, but the changes were great.
- The debug syntax tree mode is a really neat feature that I think demonstrates how much more advanced zed is under the hood than older editors that are doing syntax highlighting via regex.
There are a few downsides that I'm hoping get addressed soon:
- The collaboration workflow/security isn't very clear to me. You sign in via github (no other option???), there are 'contacts' (I guess these are github usernames?), and 'channels' (where do these live? on zed's servers?). I would really like to know if I can self-host the chat server and use a company oauth provider rather than github. If the diffs being passed around are going through zed's servers, that may be a showstopper for the company I work for as well. If they're p2p and encrypted, maybe not.
- I would love to see ollama integration. This + continue is the only reason why I spend any amount of time in vscode now. There's an issue for it here: https://github.com/zed-industries/zed/issues/4424
I guess you haven't used Sublime Text before?
That and self updating in ways that broke my most important plugin.
VSCode complains and I’ve got to hardcode an alternative absolute path gemfile for Shopify’s LSP to work. It also feels clunkier, even on powerful machines.
If Zed can give parity with Sublime on the references (I just tried and it did not seem to find any references when clearly bars was there) might be an interesting change. Considering it’s open source now I’d happily switch as it does seems super quick.
I might also be old-man yells at cloud and the copilot integration doesn’t appear important yet, but current sublime support is pretty poor for it and seems like that’ll be a thing more and more.
Every little while, I try to make vscode my main editor, because I enjoy all the features. I always switch back to Sublime just because VSCode's slowness bugs me.
Haven't really tried Zed in earnest yet, though, because of no custom LSP support.
I mean, Emacs, which can probably be considered the oldest code editor at this point, got built-in tree-sitter (which is what Zed uses under the hood) support in the last release. So it's not really related to editors being new or old
If you're using a reasonably fast language-server, which rust-analyzer apparently is (I didn't know this using vscode), the autocomplete & intentions feel instantaneous.
I think the team has learned a lot from previous editor implementations (they were the core team of atom that was notoriously slow), and so they've had an opportunity to do a lot of stuff right.
FWIW they also are the team that originally wrote tree-sitter.
The quickness feels more like it's in the core of the editor. I was shocked how much it impacted the editing experience when I tried it in early beta.
Some more anecdata to back this up: initial workspace load in VScode I can watch RA tick through its progress. Clean and boot up Zed and the same process is so fast that it’s almost unbelievable.
I always thought the major slowness was coming from clangd itself, so I'm surprised and impressed to see that Zed appears to be quicker on this front. I might be using Zed as a 'second opinion' editor because of this.
However, now I'm used to the infinite customizability and coziness of Emacs, it's going to be hard for me to move across to Zed permanently.
[1] https://emacs-tree-sitter.github.io/syntax-highlighting/
[2] https://github.com/meain/evil-textobj-tree-sitter
I use python-ts-mode, rust-ts-mode, c++-ts-mode, bash-ts-mode and a few more right now and they work well.
You can write your own modes with it also, but I have not yet looked too deeply into this.
It's definitely usable today in emacs-29, but not every language has a tree-sitter mode yet.
Whoops my tab was outdated and I didn't see that others already replied.
But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode.
There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck: I think it’s a front runner there. But I can’t imagine switching my main axe up with a holy shit moment a lot crazier than tree-sitter in 2024 and not having the render loop be in JS.
It’s a 404 until I get to an RC, but aiming for March 1st on “hyper-modern.ai” for all MIT on emacs, nvim, and vscode.
At least that’s how I worked with my vim tmux sessions ;)
It starts up with ~77 packages in half a second.
This is my config.
https://gitlab.com/ideasman42/dotfiles/-/tree/main/.config/e...
This is going MIT as part of a bigger project in about a month (think Lucid s/C++/modern models/).
If I inline attribution you mind if I borrow this or that?
1.4 seconds for 100 packages, half of which are on probation? My (and soon `HYPER//MODERN`'s) package set is under heavy construction, I'll be sad if I don't get it under 300ms including loading and rendering a logo at 6k from a cold disk which that was.
Rust is a perfectly good language for writing tight code, but those `emacs` inner loops have been tuned by hard-ass pros for 30+ years in straight C, which is plenty fast too. Even the best Rust code doesn't have that kind of tuning in.
`emacs` is fucking fast.
I mean, it's not slow per se, but compared to vim it's noticeably slower so I can't deal with it.
To each their own, but for a hardcore Emacs user (wrote a number od my own plugins) that actually tried and couldn't seriously adopt VSCode for more than a few months, Helix was such a nice surprise + change of pace. Worth giving it a shot if you're caught in that gap.
Congratulations for winning HN sentence of the year before the end of January.
(Spoiler: https://github.com/bablr-lang/)
- gcmh -package and gcmh-mode and/or gc-cons-threshold variable (former should take over the latter)
- read-process-output-max
- jit-lock-defer-time
- package-native-compile
Doom Emacs sets gcmh in its initialization so tweaking that might not be needed there. You may still want to touch gcmh-high-cons-threshold and gcmh-idle-delay-factor. Here are mine currently:
I've done nothing scientific to check out if these help at all, though, so take them with salt. With and without these, emacs seems quite sluggish at least on a Macbook, in certain modes. On Linux things seem to be a bit better.https://old.reddit.com/r/emacs/comments/bg85qm/garbage_colle...
Here is an interesting optimisation that was merged in master, but didn't make the cut for 29 in time. I thought it improved snappiness:
https://tdodge.consulting/blog/living-the-emacs-garbage-coll...
---
Anyway, I also have these in my init (I nicked these from Doom which I don't use but they have done a lot of work to dive deep into these things, mostly around what improves start up but the following might help in general):
If I do inline attribution you mind if I borrow that under MIT?
Most examples you'll see of `straight.el`/`use-package` configurations will have some version of: `(use-package something-cool :ensure t :config ...`. The `:ensure t` clause will cause it to fall back on `package-install` in the event it's not bolted into your local Cargo-style-own-the-world-and-dont-break repo mirror. Disks are big, it's like the right default now.
But if you've got a package that's mis-specified in terms of where on `github` or wherever that `striaght` is supposed to find it, you can find it tapping `elpa.org` on the shoulder at a time when the UI thread is also doing blocking network IO.
The `Messages` and/or `straight` buffers will have warnings about this, so it's fixable to find the offending package and it'll stay fixed, but in fairness what you're describing is possible.
1: https://github.com/progfolio/elpaca
Please share how.
playing briefly with Zed it seemed like the terminal was a totally different "thing" than a normal file; i couldn't run the same text selection operations, couldn't split the window vertically or horizontally, etc. to me that loses a ton of the benefit of having a terminal in the editor in the first place.
still, it's a very interesting project. i have a very love/hate relationship with emacs, so i'm always interested in alternatives...
Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.
Conservative is one thing, but having the default be something that's detrimental to 99.999% of your users in 99.95% of situations feels like bad defaults/design, not being conservative. My worthless 2 eurocents :-)
It ships with 29 and it's work to find `brew` or `apt` or `nix` or anything giving you less than 29.1 these days.
Have you tried a recent version? 29.1 is dramatically more accurate on everything from syntax highlighting to indention than VSCode (IMHO, they're probably either using or working on using `tree-sitter` too, those are serious people) or JetBrains stuff (they're working on their vscode clone more than IntelliJ these days).
I only use `nvim` for commit messages and stuff the last few years, but AFAIK it has all the `tree-sitter` stuff too.
If it's the sloppy naming of `c-basic-offset-this` vs. `py-indent-that` or whatever (I don't even remember), try a good baseline distro like Doom and tweak from there.
That explains my whole experience with Emacs. More time is spent in making Emacs awesome than actually doing my work.
Basically AstroNvim or Doom Emacs. Not a huge fan of Doom Emacs but AstroNvim got me to drop my main editors (Sublime + Atom) and I basically only use AstroNvim.
One enormous advantage of Nvim is that I can run it anywhere. I run it on a Linux machine, a Mac, and a Tablet (w/ Termux) extremely easy (just clone my dotfiles, install nvim, and that's it).
I can't parse this sentence -- could you unpack it? Not being a dick, I really want to know what you mean.
I work for a pretty conservative company re: GAI, and the ollama + continue combo made it through legal.
Yes, that was in seconds per keystroke.
The irony is that I moved from neovim to vscode because setting up intellisense in (neo)vim was always a hassle and never worked quite well. Pylance seemed too attractive not to give it a spin.
Now the lag has as mysteriously diminished, but still vscode is very far from being as snappy as (n)vim.
1) In Neovim, do `:TSPlaygroundToggle`
2) In Emacs, do `M-x treesit-explore-mode`
I really envy people who can sense passage of time between intervals of 5 milliseconds and 500 milliseconds.
My sensibility begins over a second. And to be honest even that is least of my issues. Same with start up time, I restart the IDE only once in a few days. I thinking spending a second or two extra for it is any where in the ball park of what I would call wasting time.
It’s very early, but I’ve been building a “trigger command/script and have it output anywhere” project that you could use as a bandaid solution.
I added Ollama support (you can specify model in settings)
https://github.com/jasonjmcghee/plock
It works wherever you are