Zed, a collaborative code editor, is now open source
zed.dev
zed.dev
- 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/
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 ;)
emacsclient -ca ''
alias emacs="emacsclient -ca ''"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:
(setq gc-cons-threshold (* 1024 1024 1024))
(setq gcmh-high-cons-threshold (* 1024 1024 1024))
(setq gcmh-idle-delay-factor 20)
(setq jit-lock-defer-time 0.05)
(setq read-process-output-max (* 1024 1024))
(setq package-native-compile t)
(defun my-minibuffer-setup-hook ()
(setq gc-cons-threshold most-positive-fixnum))
(defun my-minibuffer-exit-hook ()
(setq gc-cons-threshold (* 32 1024 1024)))
(add-hook 'minibuffer-setup-hook #'my-minibuffer-setup-hook)
(add-hook 'minibuffer-exit-hook #'my-minibuffer-exit-hook)
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 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)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.
Please share how.
;; 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."))
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
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
Interesting choice on licenses.
—-
I’m been super happy with Zed, my main requests (and I’ve sent in this feedback to them or contributed to existing GitHub Issues)
a. Window Size & Position doesn’t persist after closing Zed.
b. I constantly run into Language Server errors
c. Alabaster use to work as a theme, doesn’t anymore. Would be great if you could import VSCode themes into Zed
All above has tickets open.
----
Hope these small things get addressed because I truly love the elegant UI design of Zed
For those who haven't used Zed, it's the first GUI editor I've used in 25-years of development that wasn't distracting.
It's hard to describe how much more focused I am when not distracted with a Christmas tree scene of icons, menus, colors, etc. like you see in other editors.
Zed is very calming, due to its focus on not having distractions. Give it a try if you haven't.
As you say the interface is elegant and distraction free by default, no twiddling required to get a happy place.
So far I've only used it for my personal projects and don't yet have full muscle memory, but weirdly even the keyboard shortcuts seem more intuitive.
Zed is made by the Atom guy and the Tree Sitter guy. Atom was MIT licensed. I wouldn't be surprised if he's thinking the MIT license is the path to VS-Zed.
I love jetbrains because it’s so feature rich and helps me a ton but god damn it’s slow.
pwritev
pwrite
putenv
popen
pipe
path
P_ALL
P_PID
pread
pardir
P_PGID
P_WAIT
P_ALL
path
pread
pardir
P_WAIT
[etc]
Is pyright just giving Zed all the possibilities and it's up to Zed to rank them? I don't know the details of editor/LSP integration. lsp-whatever in emacs ranks these choices in a reasonable order.
I tried it out today, and in all fairness it is a very attractive and pleasant-to-use editor, but it felt like it was missing a lot of the little details. Things like suggestion order, or being able to open terminals side-by-side, or showing quickly where all the type errors are in my project or even a single file.
The collaboration tools sounds really neat, but unless I can convince colleagues to use it with me, I don't have anyone to collaborate with! For that, the little details are hugely important.
That said, it looks and feels wonderful, it's a very elegant tool.
https://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.
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
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.
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.
Editor's main purpose is to edit, and i don't think that stuffing anything else in the basic box without user asking for it is necessary. You can always pick a plugin if you need AI or collaboration or suddenly hundred species of messenger is not enough and it MUST be inside you editor instead of a usual swipe to an adjacent screen.
For most code work that’s probably not a situation to optimise for, but I often work on large markup documents.
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.
I personally don't like for my editor to send out any kind of external requests at all, and this is actually what keeps me on vim as my main editor. I also don't like limited login options
It would be cool to have a version that's just a stripped down Zed, and if need be you can install the extra stuff as plugins.
It disappeared, though, because the author (Phil Murray) disappeared and we didn't have a license to continue with it when Zortech was bought by Symantec.
It's too bad, it was a nice editor. I never was able to find out what happened to Phil. He was an excellent programmer, and an all around pleasure to work with.
P.S. For the first 5 minutes I thought Zed was developed by Meta... please change that blue :D
P.S.S: it's incredibly fast, and already has rust-analyzer included.
Knowing Nathan has been one of the major catalysts for me to improve the art of software craftsmanship. Sometimes you meet amazing people in life & I count Nathan as Amazing in many ways.
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.
I’m curious, do you really use your own languages for day to day development?
Image of Zed Mono for the similarly-curious: https://twitter.com/devongovett/status/1672307153699471360
[0] https://zed.dev/docs/adding-new-languages#lsp
Maybe if they are embedding dozens of language servers and runtimes it could bloat the binary, but I assumed the extensions and language servers would be downloaded on demand.
But a rust binary by itself shouldn’t be that large. LSP is just a simple json protocol, so parsing it doesn’t require hundreds of MB.
size /Applications/Zed.app/Contents/MacOS/zed
__TEXT __DATA __OBJC others dec hex
120979456 475136 0 4336828416 4458283008 109bc0000 zed (for
architecture x86_64)
117587968 458752 0 4336680960 4454727680 10985c000 zed (for
architecture arm64)
Helix devs, for instance, lean towards a Scheme-like implementation. [1]
[1]: https://github.com/helix-editor/helix/discussions/3806#discu...
Also, no option to disable all the collaboration and AI features leaves a sour taste for me. Hopefully, they'd improve on this later.
On the flip side, even if you believe that, there's an argument to be made that if you live in the West then the Russians/Chinese care way less about you than the Five Eyes.
It’s not that it’s non-western, it’s just that the countries I don’t trust are mostly dictatorships or something very close to it.
There aren't many countries that would qualify (Sweden fails because of the Snowden case) and I suspect your country is not one of those. What country are you from?
It's all about risk assessment, risk analysis, scenarios, probabilities, threat vectors, worst/probable/best cases of cost/benefit, etc.
What are the chances that Putin wants to get to you? How probable is it? Does he have better options than through seeing your browsing history? What happens if he actually gets it - what's the worst that can happen?
It's really all a big nonsense about nothing. You are most probably just an ordinary human, just like me. We are not even worthy of such an attention. Be realistic and know your position, role and pecking order in the world order. Be a cog and live peacefully. :-)
[0] https://www.rferl.org/a/russia-yandex-government-control/321...
[1] https://fortune.com/2022/11/25/yandex-leaves-russia-ukraine-...
As someone living in the west, I'm disappointed by our governments' hypocrisy over the massacre in Palestine while supporting Ukraine's right to resisting an invading force. Our governments' support of the massacre in Palestine (even dealing out death to peaceful resistance, as we can see by the bombing of Yemen when its people merely made economic trade inconvenient to protest the massacre) made me think the people in charge of western countries are no better and probably even worse than dictatorships such as China and Russia. (Western governments are just better to their own citizens apparently.)
A very telling sign is a list of Western countries that participate in the Yemen war, but want to keep it a secret from their citizens. Yes, they fully know that what they are doing is wrong. No, they don't want to stop doing the evil, they only want for people not to know.
This is a pattern. Remember illegal CIA prisons all around the world, torturing people?
Democracy often means that bad deeps must be better camouflaged/hidden, not that thr actions and people doing the deciding are inherently better.
1. I live in the EU and I would worry much more about my country/Union spying on me than foreigners.
2. In the same token I trust Yandex much more than Google. And yes, I am competent enough to make that assessment. The same goes with using the world's best antivirus in Kaspersky vs. using something weaker from Five-Eyeish+block.
3. Yandex Browser is technically good. But the main killer feature for me is having the address bar on the bottom of my screen. This should just be a common-sense default for mobile browsers, yet it is't.
It has all kinds of interesting features like automatically translating (and voicing) youtube videos.
Address on the bottom of the screen is a total killer.
I wish we had a proper API to interact with copilot but it seem that pulling everyone else except the dedicated VIM and JetBrains users into VSCode land seems to be more in their interest.
Microsoft doesn't care if you use copilot with VSCode or not. Copilot is a paid product the more support the better for them.
I bet Microsoft doesn't care if you use VSCode or not. It's not a paid product.
Given that the founders and several employees are former GitHub employees, I have to imagine they know how to do this integration in a proper & officially allowed way.
[0] https://github.com/zed-industries/zed/pull/2924/files#diff-e...
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.
Any plans/timeline for Linux support?
I'm glad Zed exists and hope it succeeds. I'm rooting for the team and hope they can put Microsoft's editor down the way Microsoft put Atom down.
With that being said-- I won't be using it. I've been using Vim for ~15 years and I've tried every editor and IDE under the sun. I just can't use anything else.
Their sin was using coffeescript and having one of the most unresponsive editors.
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.
So my laptop will be roasting hot constantly?
Weird choice, most programmers will never even look at this editor.
It's likely to be the case for the "bubble" of the Zed authors.
So it is not done yet is it? One platform is apparently not the goal for them.
Stay tuned for that. 0: https://zed.dev/roadmap
Anecdotally, Mac has become very popular at my workplace, with a growing number of developers choosing Mac for their primary device. We mostly target Linux, so regardless of workstation we're usually remoting into a Linux box or running some VM/Docker setup locally. When I can work on projects locally without a VM, the interactions on Mac feel a lot more natural compared to Windows.
I don't think I would switch back to a Windows machine any time soon, although if I was offered a Linux laptop I'd be very tempted.
If the Silicon Valley is just a bubble, then the two bubbles I live in (life-long FOSS/Linux guy, but also deep into the hosting/transit/non-eyeball end of the Internet), every single Mac owner I know does not run OSX, but only wanted it for the physical build itself; they either run Windows because of job reasons, or they run Linux because they like to get shit done.
Everyone else I know is slowly joining #TeamFramework. Having made what seems to be the best Ryzen laptop on the market is certainly turning heads, and congrats for pulling it off.
How do you validate this claim? The country demographic in the survey shows that USA makes up only 21% of responses.
https://survey.stackoverflow.co/2023/#section-key-territorie...
If a lot of people self-select themselves to align with techbro culture, techbro culture is mainly in the Silicon Valley but not only there, and they think, for example, owning a Mac is how you signal belonging to that group (as in, Macs are a modern day Veblen good), then people who think they are (or wish they were) part of the techbro culture, no matter their location, will buy Macs.
So, the claim being given by people quoting the SO survey is: SO survey responders are not mainly made up of people who self-identify as techbros or have had their purchasing decisions (such as buying a Mac) greatly influenced by techbro culture.
I do not know of a way to argue that position. You can state that, literally, techbros live outside of the US, which is obviously true without quoting this survey; it however, does not mean the Silicon Valley doesn't act as an echo chamber, and doesn't have great effect on the tech industry worldwide.
What I would more likely want to see is, of that 21% of America, how many live in either the Silicon Valley or the Seattle/Redmond region. As in, how many are hailing from the Chicago or New York or Dallas metros, or non-metro regions entirely.
I'm guessing that, still, many would have responded that they live in either the SV or the northwest, greatly more-so than elsewhere in the US.
Lapce is another text editor written in Rust but it does not support native IME yet.
My only worry is that the collaboration features won't be used much, as they require most of the team to use Zed.
FEATURE REQUEST :)
Would it be possible to have option+click+drag create multiple cursors where you drag and not a selection with cursor at the end? Basically, the behaviour that Sublime Text has—Sublime Text's multiple cursors are, frankly, awesome.
I have found shift+option+drag to create a rectangle, but no way to create vertical lines of cursors through lines of text, and my favourite—drag down to the right of your code to put cursors at the end of every line. I use that all the time: scrape to the right hit ctrl+a to get to the start of a line, cut out and replace text, ctrl+e to the end, add more text etc. Really useful for turning data into code.
Option+click+drag is one of the most useful features of Sublime Text and my muscle memory is stuck to it — to the point where I keep Sublime Text around purely for the feature (well, this, the fantastic sort/permute lines options, and the live-highlight of regex searches that give you instant feedback of whether your regex is working correctly). Sublime Text is where I do all my data formatting, and where I test every regex before using it in my code.
> Open input.rs at the end of line 21 in rust-lang/regex. Type z 10 times, measure how long it takes for each z to display since hitting the z key.
Could someone clarify what that means? My interpretation of that was to go to https://github.com/rust-lang/regex/blob/master/regex-cli/arg... and start typing 'z' at the end of line 21, but that doesn't seem to make any sense. I guess that repo got refactored and those instructions are out of date?
Which is straightforward, but also depends a lot on how each editor is configured for Rust support and what functionality you are actually getting in that time.
Jetbrain are the main player and their products are paid. I am finding a jetbrain alternative that is free
oh, sorry, you asked for an IDE and not an operating system... /s
seriously, budget a day or two for the ergonomics and a week for wrangling plugins, but some of the most productive developers in the world use emacs and they never need to worry about vendor issues, porting issues, not having a GUI, support for some weird file type, ability to create some funky type of macro, etc.
Admittedly, I was using Spacemacs which probably has way more packages than a bespoke emacs configuration, but you must understand if people get turned off when they ask you how to use an editor and your answer is "first, spend a few weeks setting it up and understand how each of your many packages works".
> How do emacs people deal with this
The same way anybody working with any package system does, by pinning ancient versions and/or just never updating all packages, at least for packages that aren't so widely used that they pretty much are never broken
2. git add .emacs.d/elpa
3. Don't click update all the time.
Stockholm syndrome.
Is it just about the installation format?
That's an outrageously false statement. If it were true, you'd rarely need plugins.
> I wonder what you'd consider an IDE nowadays.
The definition of an IDE hasn't changed in at least 20 years. INTEGRATED development environment.
If I install a C++ IDE, I have everything I need out of the box, and the experience is (usually) consistent across all features.
If I want to do C++ in Vim, I need to install about 10 plugins (to begin with) [1], which will result in a disjointed experience (each plugin has different authors with different visions) where things break randomly and I don't know why. Speaking from experience, unfortunately.
Yes, you can make it work and you can get used to it, but it's just a text editor that you try to coax into doing what you want by using plugins.
Whereas the IDE will give you a language-specific tool out of the box, without any significant effort or inconvenience on your part. And the overall experience is better because the IDE "just works" most of the time.
[1] https://stackoverflow.com/questions/4237817/configuring-vim-...
They have a IDE called Visual Studio and it is different from VSCode
I'll stick with vs code for now...
pros:
* god damn this is fast... vscode feels so bloated by comparison. * lsp integration works great. loaded up a rust project I have and it has good support for autocompletion
bad: what keeps me from using it as my daily driver for now
* no support for integrated debugger. I use rustrover for rust dev sepcifically because its so easy to set debugger stuff. * daily workflow inolves entering a docker container or sshing into a remote server to edit code. I don't see anywhere in zed where I can do this.
bottom line: I see a lot of potential here. I'd love to use this when I'm just editing some rust code and I need zero distractions but the lack of ssh remote makes this a no-go for all of my paid work at the moment.
Also there's a wiki-editor (like Tomboy[2]) called "Zim"[3].
[1] https://github.com/xi-editor/xi-editor [2] https://en.wikipedia.org/wiki/Tomboy_(software) [*3] https://zim-wiki.org/
> Extensively fuzz tested for stability > Performance and power mean nothing without reliability. That's why we've subjected Zed's critical code paths to randomized tests that help us find and fix rare edge cases. By creating controlled chaos in development, we achieve stability in production.
How effective is this approach? Does it catch many issues that would not otherwise have been caught through a more risk-based approach? Conversely, does it tend to catch any significant issues?
Locate the little arrow in the top right, click it and then select "Theme".
Now use your arrow keys to change the theme and see for yourself. :)
At least these days we order the themes by dark then light... Themes used to be grouped by name, so you would get rainbow flashbanged moving down the list!
Such functionality would be wildly useful for both remote development and pairing, dev containers etc.
Instead I'll have to stick with VS Code remote develop + live share, of which the latter feels like a monkey patched afterthought.
1. Whenever I open a new window it fills the full height and width of my screen.
2. I just have no faith in a product which hand waves how it's going to make money.
For that matter, why does an open source product need to make money in the first place?
Well, even ignoring the central servers which are required for all of Zed’s collaboration features, I’m not personally interested in maintaining my own persona fork of Zed
So that means I need to “have faith” that someone, whether a paid team of developers or an unpaid group of volunteers, will continue developing, or at least maintaining the project.
Or that it gets abandoned in a state that I can keep using it indefinitely, I guess.
> For that matter, why does an open source product need to make money in the first place?
That’s a fine question in general, but in the announcement they pretty clearly say that they are hoping to make money with unspecified future subscription services, not that they don’t need to make money
But overwhelming positive experiences here, that I read, people being happy with using it made me try it out.
It really feels different and better. Can't say why and what it is. But first impression is very positive, even the theme, I didn't feel the need to change it.
To commemorate, I am running `brew install --cask zed` right now! :^)
"copilot": {
"disabled_globs": [
".env"
]
}
I don't see a way to disable all the collaboration features, but it does look pretty difficult to do it by mistake. You have to add collaborators explicitly.
"features": {
"copilot": false
}I think the next evolution is also combining the collaborative code editing with a virtualized environment. Where it builds and deploys remotely or runs the code for test and validation.
It's on the roadmap for 2024
Somebody please tell me what to use. No "depends on what you wanna do". Just which one.
Thank you
It doesn't have a vim mode if there is no macro support. Plain and simple.
How does Zed make money here?
f.e.,
> Zed Channels is one example of such a service. It's free for anyone today, but we intend to begin charging for private use after a beta period of experimentation. Providing server-side compute to power AI features is another monetization scheme we're seeing getting traction.
Edit: hell, I've wanted to check remote ssh in vscodium now to know what I'm missing, and it looks like they basically contain MS DRM and are only compatible with official vscode. License is also proprietary[1] and makes it impossible to use it with vscodium or other OSS projects. Yikes.
[1]: https://github.com/VSCodium/vscodium/wiki/Extensions-Compati...
not correct at all
edit:
It's not even on the landing page, or even on the about page! The landing page has an entire section, "Work with code on any machine"!
This is worse than bad.
I vaguely remember them being on the Rust podcast and I believe they said that they want multiplatform support but they first need to nail it on one platform before they go for the next.
Mac uses a very different graphic stack.
> Work with code on any machine > When you join a teammate's project, you can navigate and edit as if the code is on your local machine. Open any file, type with low latency, and interact with language servers. It all works seamlessly, whether you're working with someone at the next desk or on a different continent.
I'm curious what part of that indicates that it means any operating system? It is clearly talking about treating remote machines as local machines. Yes, words have actual meanings but they also have context in which they are said or printed.
Here's an interesting perspective: https://chat.openai.com/share/6ac010c4-dc4c-43ec-8b34-fc68a2...
I'm not trying to assume or criticize their intentions. I'm criticizing their unintentional mistake.
I think part of it is that apps that are designed to be multi-platform don't tend to use macOS screenshots because maxOS is a minority of their users.
This is referring to remote editing support.
Platform support is in their FAQ, but I agree it should be a bit clearer on the homepage. Perhaps the download button should say "Download for MacOS" or similar.
I do think your comment here is unnecessarily rude.
> This is referring to remote editing support.
I agree with the OP, I thought it meant Zed was cross platform or something.
Yeah, OP said the page is really bad. But IMO we should be able to express negative opinions on things we think suck about technical content without being forced to couch our language in euphemisms for fear of being rude, especially on a site like HN.
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please don't post shallow dismissals, especially of other people's work.
Expressing negative opinions is fine. But perhaps you should have a fear of being rude. We are a community, and there's plenty of other people reading these comments. I value kindness and being constructive, neither of which the comment I replied to appear to express.
And the feedback was constructive (and easily actionable): be upfront about the very limited platform support, don't waste people's time.
There are just packages for OSX for now... you know open source means you can build your own now, and that may be exactly why they release?
I understand why they would choose to implement Zed using those tools, but the sacrifice is platform compatibility. I'm not bothered at all with the fact that this is MacOS exclusive. I just want to know before I go try to download it!
Mac developer is a proxy for the user type Zed is probably aiming to sell service: Western, wealthy, senior. Whileas Windows users are everyone and their uncle. Scaling to large userbase does not make sense if they are not going to pay for your product.
A WINE like project for macOS software would be great
https://en.wikipedia.org/wiki/Darling_(software)
Easy to implement and capitalizes on something the market is highly interested in at the moment.
Given the concentration of developers who use Macs, and the accelerating interest in LLM-assisted coding, this makes a lot of sense to me.
And while it may be true that AI is a craze, this is also a very real and useful feature grounded in a solid use case that has high impact on its users unlike some of the crazes of the past that were purely built on hype.
Maybe I am in a different bubble/country, but most professional developers and hobbyist hackers I know have either ThinkPads or Framework laptops running Linux or sometimes Windows, if they have to.
I do think there are bubbles though. Macs are popular in SV, and there’s a very healthy portion of the developer community focused on this user base.
So not really a good Argument that MacOS is used more...
The argument is not that macOS is used more. The argument is that macOS is prevalent enough that it makes sense to focus on it as a market.
fairly certain this is a silicon valley thing, the vast majority uses Windows for development and I wouldn't be surprised if macOS and linux are pretty even these days
In that sense, the “concentration” is in the SV region, and may have been a bad choice of word by me when thinking about the broader ecosystem.
With that said, macOS enjoys ~33% share in the latest Stack Overflow developer survey [0], and I think this illustrates the point somewhat. This is a healthy enough portion of the market to focus on, especially in the case of implementing low hanging fruit.
The explain it in the 6th question on https://zed.dev/faq
You should have a focus when you first build a product. You shouldn't be holding up your product progress because you don't support every platform.
This is the reason why you see a lot of apps support iOS before they release an Android app.
It better to build a good working app for one platform than to not build one at all because you are spending all your time supporting as many platform as possible.
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.
Claimed insertion latency for a keystroke: - zed 58ms - subl 75ms - vscode 97ms - clion 83ms
60 Hz displays refresh once every ~16.6ms. 58ms to insert a character is ~3.5 frames. My laptop can do 120 Hz, and other monitors can even do 300 Hz.
Yeah, it's a lot faster than the other editors, but 58ms seems really slow - definitely not "next display refresh". All of them seem really slow.
Wow, the numbers are entirely unexpected. I want to see the latency when you have no display server, having booted directly to a shell.
I imagine modern competitive twitch-reflex videogames (fps, fighting) must have far less input latency - 100ms must be totally unacceptable. Suppose that's the power of a GPU.
The good-ish news is that as the frame rate goes up, compositor latency goes down, as it's usually an integer multiple of frame refresh time.
I'm also interested in influencing the design of next gen systems to reduce compositor latency, but I'm apparently pretty much alone in that interest.
Zed Contributor License and Feedback Agreement Welcome to our Contributor License and Feedback Agreement! Here's a quick breakdown of what's inside:
You (the contributor) are entering into an agreement with Zed Industries, Inc. You're giving Zed permission to use and share your contributions (like original works or modifications). You assure us that the contributions are truly your own and you have the legal right to share them. You're not required to support your contributions but you're welcome to if you wish. If you ever notice an error or change in the details you've given us, you agree to let us know. In short, this agreement covers the terms for your valuable contributions to Zed's projects.
Legally binding section follows: By submitting a Contribution, use of the Solution or any components related thereto (as such is further defined in Zed’s End User License Agreement located here: https://zed.dev/eula) or as enabled pursuant to your use of Zed’s collaboration tools offered therein, you hereby accept and agree to the terms and conditions set forth in this Contributor License and Feedback Agreement (the “Agreement”) for Your present and future Contributions submitted to Zed Industries, Inc. (“Company”). Except for the license granted herein to Company and recipients of software distributed or made available by Company, You reserve all right, title, and interest in and to Your Contributions.
1. Definitions.
“Contributor”, "You", and "Your" shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with Company. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
"Contribution" shall mean Feedback (as defined below), any original work of authorship, and any modifications or additions to an existing work, that is intentionally submitted by You to Company for inclusion in, or documentation of, any of the products owned or managed by Company (the "Work"). For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to Company or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking or collaboration systems that are managed by, or on behalf of, Company for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as "Not a Contribution."
“Feedback” means suggestions, comments, improvements, software code / snippets or other information submitted to, shared with or otherwise made available to Zed or its contributors with respect to, or in connection with the use or interaction with, the Work, Zed Network Based Service or Editor technology (as defined by Zed and as further described within Zed’s End User License Agreement located at https://zed.dev/eula).
2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to Company, and to recipients of software distributed by Company related hereto, a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute, Your Contributions and such derivative works (the “Contributor License Grant”). Further, to the extent that You participate in any livestream or other collaborative feedback generating session offered by Company, you hereby consent to use of any content shared by you in connection therewith in accordance with the foregoing Contributor License Grant.
3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to Company and to recipients of software distributed by Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
4. You represent that you are legally entitled to grant the above licenses, including but not limited to any video content shared or recorded as related to collaboration with Zed and the Zed community. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to Company, or that your employer has executed a separate Corporate CLA with Company.
5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
7. Should You wish to submit work that is not Your original creation, You may submit it to Company separately from any Contribution, identifying the complete details of its source (e.g., attribution) and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work prior to submitting it to Zed or the Zed community.
8. You agree to notify Company of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
Sorry about that!
I am a Sublime Text addict, but hate how slow development is and how resistant they are to adding more dev-focused features. I would happily sign a CLA if it meant I could modify the code myself, even if I end up paying to use my own code.
Giving the owner permission to sell my contribution (which is likely very minor compared to the rest of the project) gives me added peace of mind since I know that the project is (or can be) sustainable.
A rug pull is always bad, but it's not fair to assume that that's what will happen (unless you know something we don't).
And besides, even if it does happen, that's what forks are for. This project is licensed with GPL and AGPL.
The only purpose of a CLA like this is to provide for a future where the software can be made non-free again.
Public domain is closer to “equally entitled”.
Whereas the copyright holder has broader rights.
So a licensed user is not “equally entitled”.
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