[HN Gopher] We Have to Start Over: From Atom to Zed
___________________________________________________________________
We Have to Start Over: From Atom to Zed
Author : tosh
Score : 262 points
Date : 2024-02-17 10:45 UTC (12 hours ago)
(HTM) web link (zed.dev)
(TXT) w3m dump (zed.dev)
| benbristow wrote:
| Doesn't work on Windows or Linux. Remind me when it does.
| practicalrs wrote:
| I asked Thorsten about Windows support today, he said "Zed, you
| mean? After Linux, I'd say.". So there is some plan :)
| sapiogram wrote:
| > So there is some plan :)
|
| How does that follow from the rest of your comment?
| mananaysiempre wrote:
| Logically it doesn't, but in actual good-faith
| communication people usually follow Grice's relevance
| maxim[1]: the points they mention are relevant to the
| conversation and the point they're making. Thus, if neither
| Linux nor Windows support are planned, and the question is
| about Windows support, saying that Windows will come after
| Linux would be (vacuously) true, but the mention of Linux
| would be irrelevant.
|
| (Notably, communication coming out or through legal counsel
| cannot be assumed to be good-faith, the premise of the
| court system being that the best we can achieve is two bad-
| faith adversaries and a neutral arbiter. But that's not
| what we are dealing with here.)
|
| Pedantry aside, I think I remember one of the developers
| saying they do plan on Linux support at some point in one
| of the previous Zed threads here. There were also some
| "small team" and "laser-focused" and "best possible
| experience" in that comment, but they did say outright they
| were planning on it. Though plans change, I think that's
| the best we could hope for at this point, as I doubt even
| they themselves know more about their future.
|
| [1] https://en.wikipedia.org/wiki/Cooperative_principle
| misternugget wrote:
| Hey! I'm the mentioned Thorsten. Linux _is_ actively
| being developed. Here 's a PR from 2 days ago that shows
| file-opening in Linux starting to work:
| https://github.com/zed-industries/zed/pull/7852
|
| And so far Linux support has been a big community effort.
| I think more community member contributed to Linux
| support than Zed teammates. Very cool to see.
|
| So: Linux is in the works. Windows will probably happen
| after that, or if someone in the community wants to
| emulate what the Linux users are doing and start before
| that.
| kvark wrote:
| Windows support is happening locally on individuals
| machines. We'll start upstreaming things up.
| airstrike wrote:
| What a beautiful comment. We should make it the MOTD for
| perpetuity.
| tiffanyh wrote:
| SIMD
|
| I wonder if Zed uses SIMD, to read in text from a file or write
| out text to the display.
|
| Mitchell recently wrote about how he got a massive reduction in
| latency, by implementing SIMD in his terminal app (which is
| analogist to an editor)
|
| https://mitchellh.com/writing/ghostty-devlog-006
|
| https://hachyderm.io/@mitchellh/111919642467789362
| ben-schaaf wrote:
| memcpy, strchr, etc. use SIMD. The rust HashMap uses SIMD. LLVM
| can and will auto-vectorize. So yes - of course Zed - "uses
| SIMD", but it's not a tool you can throw at everything to make
| it faster.
| taminka wrote:
| despite what the article claims, clang and gcc are acc very
| good at vectorising code, and intel, arm, etc have entire teams
| dedicated to improving vectorisation in modern compilers
| tiffanyh wrote:
| How do you explain the before/after speed improvement then?
| taminka wrote:
| i'm not saying that manually writing simd assembly or
| intrinsics is useless, it's very often necessary, i'm just
| disagreeing w/ the statement
|
| > Unfortunately, compilers are notoriously bad at
| autovectorization and with the exception of relatively
| trivial loops, compilers rarely autovectorize effectively.
|
| from the article
| instagary wrote:
| I tried Zed, and it felt similar to VSCode. I know there are
| multiplayer features that are better than live share, but on the
| surface, I needed convincing to switch.
|
| I would be more inclined to use Zed if it could displace XCode.
| It pains me to use it from deleting derived data or cleaning the
| build folder to random crashes.
|
| Contrasting the DX to Android Studio, it's night and day. I
| always wanted an Android studio-like experience for iOS
| development.
| pm wrote:
| Xcode and Android Studio have plenty of warts. What is it about
| Android Studio's experience that you find lacking in Xcode?
| instagary wrote:
| Part of me thinks it could be related to our project using
| CocoaPods. I've always appreciated how nicely Gradle worked
| to install dependencies, and the DX always lacked in Xcode.
| SPM works similarly, but I have yet to try it on a medium-
| sized codebase. So, my frustration could be related to
| CocoaPods.
|
| Apart from package managers, I like the auto-import features
| for frameworks in Android Studio. As well as the "fix it" UX,
| which is similar to VSCodes. Having an integrated terminal is
| something Xcode still lacks, and maybe a better UX than a
| Plist to configure projects; I know XcodeGen/Tuist and other
| tools exist, but something built-in would be nice for fast
| project config.
| jwells89 wrote:
| From personal experience, SPM is much smoother in
| moderately complex projects. Gradle (and to a lesser
| extent, Android Studio) drives me a special kind of crazy,
| especially when a project has sat for a while and Gradle
| updates have accumulated and Gradle version compatibility
| of dependencies has diverged.
|
| This is somewhat exacerbated by the need to import so many
| libraries in Android projects. My Mac/iOS projects have
| between a fourth and sixth as many dependencies as their
| Android counterparts.
|
| CocoaPods though... ugh. Horrible. Was thrilled to part
| ways with it several years ago.
| mitemte wrote:
| AppCode was more or less Android Studio for iOS. Both are based
| on IntelliJ. It's a shame AppCode was recently discontinued.
| torlok wrote:
| Had a look at the About page, and the live coding feature does
| sound useful. I'm sure the guys are excited; it's a fun project.
| You get to write algorithms, optimise performance, and do GPU
| programming. But who needs another text editor that will probably
| never reach feature parity with Vim and a terminal multiplexer.
| peoplefromibiza wrote:
| zed is actually very fast though
| v3ss0n wrote:
| Only works on Mac Big no no
| egze wrote:
| I actually prefer Mac only apps. It usually means the
| experience is way more polished.
| loloquwowndueo wrote:
| Unless you don't own a Mac.
| ivancho wrote:
| Even more so then. Simplify, simplify, simplify!
| littlestymaar wrote:
| Mac-only apps come with additional security benefits on
| Windows and Linux too: there's no safer software than the
| software you cannot run.
| sofixa wrote:
| Or even worse, you own a Mac (say, through work), but
| aren't entirely in the Apple ecosystem and don't want to
| relearn everything and fight muscle memory every time you
| switch devices.
| jeffhuys wrote:
| Remap the keys.
| loloquwowndueo wrote:
| Most people who say "all editors have vim keybindings
| just use that" miss the fact that bindings or not, a lot
| of vim's functionality is just not available on other
| editors.
| sofixa wrote:
| I have (but or course Apple make it hard to do so you
| need third party software). But that doesn't help with
| special mac only software that has it's own style, like
| Arc or Zed.
| Keyframe wrote:
| compared to their non-mac versions?
| kstrauser wrote:
| I think they mean compared to cross-platform apps that
| feel equally weird on every system.
|
| There's some talk in the Mac world about "Mac-assed Mac
| apps". I use BBEdit as my main editor because it _feels
| right_. The default shortcuts are like every other Mac
| app. You can use standard Mac tools like AppleScript to
| automate it. It uses the same fonts, widgets, and menu
| systems as everything else. It's made for that
| environment and it shows in a million ways.
|
| VSCode is a marvel of engineering and I love that it
| exists. It also feels uncanny-valley "off" on my Mac in
| ways that make my brain itch, so I don't use it. Same
| with Obsidian: it's a brilliant app, but it bugs me. It's
| not bad in any way, it's just not the right choice _for
| me_.
| noSyncCloud wrote:
| Thanks for saving my time. Topic hidden.
| 0x6c6f6c wrote:
| Cross-platform support is in development. You might miss
| the announcement that actually matters to you
| Zambyte wrote:
| Am I wrong in thinking that "topic hidden" means this
| specific post, and that future posts related to Zed (such
| as a cross platform announcement) would still show up for
| them...?
| timeon wrote:
| For now.
| dist-epoch wrote:
| So? It's a code editor.
|
| Have you ever seen a serious programmer which is not on a
| Mac?
| __MatrixMan__ wrote:
| One of the people I admire for their programming skill
| works on a raspberry pi. I use my work MacBook through
| ssh because I prefer Sway to MacOS's window manager. We
| are many and varied.
| jkogara wrote:
| Troll often?
| cdelsolar wrote:
| Lol
| kvark wrote:
| You can already build and run it in Linux, even type things
| in and have dialogs! Linux and Windows are coming.
| smarkov wrote:
| This might be one of those things like monitor refresh rate
| where you can only really tell the difference if you've
| experienced the better version for a while, but I haven't
| ever felt slowed down by the speed of VS Code.
| madeofpalk wrote:
| Every now and then I switch back to Apple's Terminal app,
| and I'm blown away at how much faster it is at just typing
| than iTerm it is, and how much nicer that is.
| bbkane wrote:
| I switched to iTerm2 a few years ago due to blurry fonts
| on zoom with Terminal.app . Wonder if that's still a
| problem?
|
| A few months ago I switched to WezTerm and, after some
| config wrestling, I've been very happy using it
| (https://github.com/bbkane/dotfiles/tree/master/wezterm).
| snet0 wrote:
| I do think it's something like that. Things can quickly get
| to the speed that feels "fast enough" that they don't feel
| subjectively slow, but can still be sped up by a couple
| orders of magnitude. If you Ctrl-F something and it takes a
| few hundred ms, you probably don't feel like it was slow,
| but in reality the "speed-of-light" for this operation was
| probably orders of magnitude faster than it happened on
| your device. Once you experience something close to the
| theoretical speed, it's really hard to go back to something
| you thought was perfectly fine before. _And_ you start
| noticing that everything feels slower than it "should"..
|
| I think of something like grep, where if I tried to grep a
| large hierarchy it'd be really slow and I'd sorta reason to
| myself "well yeah it's a lot of files in a large tree, of
| course it'll be slow!". Then I installed ripgrep and
| suddenly what I thought was a reasonable speed was shown to
| be unreasonably slow!
| peoplefromibiza wrote:
| it is actually faster and snappier to use on a beefy M2
| max, on the same hardware zed starts up in half the time.
| the difference is very noticeable. of course it is much
| less configurable and doesn't work with a lot of things VS
| Code can do easily.
|
| edit: see this comment for a much better explanation than
| mine of what I originally meant
| https://news.ycombinator.com/item?id=39409763
| ncruces wrote:
| Startup would have to be terrible for me to bother.
|
| VS Code starts in under a couple of seconds, and I have
| it open all day long; once open, other windows open even
| faster than that.
|
| If it took any longer than a couple of seconds, I'd start
| blaming the extensions other editors won't have.
| cmiller1 wrote:
| In a perfect world startup times would be
| indistinguishable from instantaneous.
| ncruces wrote:
| And for an image previewer I'd care.
|
| If I'm opening a codebase with thousands of files, I
| don't mind to wait a couple of seconds, as long as it's
| responsive afterwards.
| peoplefromibiza wrote:
| > Startup would have to be terrible for me to bother.
|
| that's just the first noticeable difference.
|
| but there have been instances lately where opening,
| editing and saving the file took me less time with zed
| than just open it in VS Code and waiting for it to be
| ready for inputs
|
| > VS Code starts in under a couple of seconds
|
| I am talking about relative speed differences. Imagine
| you open the same code base and the editor is ready in
| half a second. going back to the "slower" one would be
| unbearable.
|
| now admittedly zed is no way near to the extensibility of
| VS Code so it is probably doing less and that's where
| probably much of the speed difference comes from, but it
| can't really be overlooked once you experienced it.
| satvikpendem wrote:
| I have. I have some huge Markdown documents I've needed to
| load and VSCode cannot render them without becoming super
| slow. In contrast, vim gets it done.
| madeofpalk wrote:
| I would guess most developers do _not_ use vim. Pretending that
| vim is the universally loved editor that every developer has
| agreed upon using seems pretty disconnected from the real
| world.
|
| VS Code came up out of nowhere pretty recently, and is used by
| a lot of people, so that shows that there is (or was, but still
| post-vim) opportunity for a new editor. Whether Zed is able to
| gain momentum to cater for the long-tail that other developers
| do remains to be seen, but I'm pretty keen to see more products
| trying to compete for users.
| foobarian wrote:
| I feel like these classic editors are good to know just for
| general education like writing cursive. If you end up on some
| barebones system you will know how to edit a config file and
| exit. But for day-to-day it's all IDEs nowadays.
| eropple wrote:
| The line between "IDE" and "text editor" has blurred to the
| point where I'm not sure they're super useful terms
| anymore. When I used vim up till about 2019, I had it
| configured with all the toys to the point where it wasn't
| all that far off of where my VSCode setup is today.
|
| Also, you know, insert Emacs joke here assuming if you
| still have enough RAM to post, etc.
| kstrauser wrote:
| I don't believe there's a useful distinction, at least
| for more advanced editors. For instance, I'm not aware of
| anything you can do in, say, PyCharm that you can't do in
| Emacs or Vim. I don't mean that in a curmudgeonly way
| like "nothing _I_ care about, because we don't need those
| fancy features to write a pageful of Fortran on my 1997
| laptop". I mean, I don't know of a single feature of any
| kind that doesn't exist on essentially all modern
| editors.
| lelanthran wrote:
| > I mean, I don't know of a single feature of any kind
| that doesn't exist on essentially all modern editors.
|
| All composed commands. Like Repeat. As in `repeat the
| following command 5 times`.
|
| Like `d5` in Vim (delete 5lines).
|
| Or y30 (Copy 30 lines).
|
| Or `V?^func` (select text from current cursor position to
| the beginning of the function).
|
| None of those are memorised commands. They're simply one
| command composed with another.
|
| _Composability_ is the real killer feature in Vim. Even
| in Emacs, I don 't get the same ease of composability as
| I do in Vim.
| Jtsummers wrote:
| In emacs your repeat commands are C-u <number> <other
| command>. Your selection would be C-space C-s func M-b.
|
| M-b causes it to go back to the beginning of the word and
| search ends, you can still adjust the selection with
| other movements. It's not as tight as V?<regex> but it's
| still composable.
|
| Or you use evil mode and get those vi-style bindings in
| the editor.
|
| EDIT: Actually, playing around with your `V?` command
| doesn't it select that entire line rather than to that
| pattern? So the emacs equivalent would actually be:
| C-space C-M-s ^func C-e
| kstrauser wrote:
| Well, ok. I'm specifically talking about what might count
| as an IDE feature. Vim and Emacs can run in a terminal,
| but that's not a defining characteristic of an IDR. More
| like, everything can do interactive debugging, and syntax
| highlighting, and code completion, edit-time error
| flagging, etc. etc.
| dingnuts wrote:
| It's even blurrier when you realize how many people are
| using LSP. Emacs with elgot is literally just a different
| UI in front of the same IDE tooling as VSCode.
|
| The editor wars are over and everyone won because of
| separation of concerns. Yay!
| dingnuts wrote:
| VSCode came out of nowhere and took the market share
| previously held by Atom and Sublime Text 2
|
| The folks I know who use Emacs or vim (including me) are by
| and large still using those tools since before Atom and
| Sublime got popular. We just have LSP, now, like VSCode does.
| jeremyjh wrote:
| I'm primarily developing Elixir and Javascript and a few
| years ago I switched from Emacs/Spacemacs to VS Code. What
| pushed me over the edge were projects like VSpaceCode
| (basically replicating Spacemacs keybinding and menu
| system) and edamagit (replicating Magit). I've tried Zed
| and I'm quite optimistic about it, but so far not willing
| to put the work in to replicate enough of my setup.
| jemmyw wrote:
| I moved from vim to vscode. The main driver was an easier
| time writing extensions.
|
| I've tried to switch to neovim twice since and gave up. Lua
| is nice and I did get into that the first time. Crashing
| and errors were rife though. The second time, which was
| very recently, it seemed like everything had changed again,
| all completely new plugins etc. And I struggled to do some
| basic stuff, I guess I've just forgotten the more in-depth
| file/window management. So it goes.
| abetusk wrote:
| I found a SO poll from 2021 result listing percentages of
| respondents IDEs [0]. There's overlap, so developers can use
| more than one, but Visual Studio Code is at 71%, Visual
| Studio at 33%, Notepad++ at 30% and vim in in 5th place at
| 24% (IntelliJ is at 29%).
|
| [0] https://insights.stackoverflow.com/survey/2021#most-
| popular-...
| samatman wrote:
| Whether or not a large number of people use vim has no
| bearing on whether or not Zed will reach feature parity with
| it.
| rhdunn wrote:
| I use vim to edit git commit messages and other git related
| tasks as I'm most comfortable/used to working with the git
| cli (muscle memory, etc.).
|
| I also use either vim or nano when viewing/editing files on
| the command line (either msys2 wsl, or headless linux).
|
| Re: IDEs, I mainly use IntelliJ, with VSCode being used for a
| few things.
| jmull wrote:
| I can't think of a nice way to express what I think of vim, but
| I think your general point is apt.
|
| Some pretty full-featured editors already exist that people are
| happy with or, perhaps, have at least gotten used to. Where
| does a new editor fit in?
|
| It's neat that it's "multiplayer" but that's an edge case.
|
| I'm also not convinced by the business model. Do people really
| want channels, calls and chat integrated with their code
| editor? Personally, I have an almost visceral negative reaction
| to the idea but maybe that's just me.
| ParetoOptimal wrote:
| Email in emacs is useful because workflow automation can be
| done based on emails I'm reading.
|
| Chat is similar.
| hresvelgr wrote:
| > But who needs another text editor that will probably never
| reach feature parity with Vim and a terminal multiplexer.
|
| Feature parity with Vim is not meaningful in my opinion. LSP
| evened the playing field enough for all editors to the point
| where you can daily drive anything and be no less productive
| than most.
|
| Use whatever you like and helps you get the job done. That
| includes Vim too, but I'm getting sick and tired of people
| acting like using Vim is some kind of irreplaceable boon.
| Becoming a better thinker will make you an exponentially better
| programmer than any tool.
| torlok wrote:
| Vim is just an example. My point was that code at the end of
| the day is just text, and there's only so many features you
| need to be able to write/compile/edit efficiently in 99.9% of
| the cases. Any new power tools for text editing will end up
| taking more time to learn and remember than be of use.
| __MatrixMan__ wrote:
| I'm not so sure. The fact that were editing the code as
| text and not as mutations and annotations on its syntax
| tree has always struck me as a sign that we're still in the
| stone ages when it comes to expressing ourselves precisely
| to a computer.
| skydhash wrote:
| The basic model of computation is the turing maching, and
| it's a symbol manipulating one. So editing text is at the
| core of what computing is. You could go a step higher to
| edit tokens and that's what VIM does, albeit imperfectly
| due to tokens not being a finite set.
| __MatrixMan__ wrote:
| I'm not sure what you mean by "tokens not being a finite
| set". I suppose there's the theoretical issue of token
| length being potentially unbounded, but whatever problems
| your editor has with that, your lexer will likely also
| have. For any finite length file, there is a finite
| number of tokens, and once you parse it, you've got a
| much smaller list of symbols plus a convenient address
| for each one. I don't think it's a practical issue.
|
| Vim's understanding of tokens makes some reasonable
| assumptions, but unless you've configured the textobjects
| plugin to talk to a properly configured language server,
| you're working on vim's presumed tokenization and not a
| tokenization that's native to whatever the underlying
| language is. Helix tries to bundle this in by default,
| but it still doesn't feel like a first class citizen.
|
| As for turning machines, not since the 80's have the
| tokens that appear in our editors been the tokens that
| are manipulated by our processors. There are typically a
| myriad of bytecode translations or compiler optimizations
| or parser hijinks between what you're editing and what
| you're running. It's the AST that matters to the code
| author, and the AST is a tree, not a string.
|
| We need to get to the point where you can directly
| annotate on a function parameter:
|
| > this function is slow when this parameter is > 100
|
| ...such that the annotation sticks to that parameter,
| however the viewer has chosen to render the text.
|
| The best we can do at present is to sprinkle some text
| nearby leave the problem of deciding which parameter and
| which function are referenced an exercise for the reader.
| This then necessitates that we preserve the way the text
| appears, which prevents us from presenting it differently
| based on the view context (e.g. maybe the reader prefers
| different units, timezones, or a language which flows
| their text differently than the author).
| giancarlostoro wrote:
| In my opinion I wish more editors would become a face to Neovim
| which can run in a headless mode, allowing you to not have to
| emulate VIM at all, but take full advantage of it and all its
| plugins. It still kills me JetBrians chooses to maintain what
| VIM users call an awful plugin that simulates VIM, when they
| could just implement a Neovim front-end natively into their
| IDE, giving them the edge of "we fully support Neovim and all
| it brings" which is a much bigger selling point than, we have a
| VIM-like plugin.
| satvikpendem wrote:
| The VSCode-Neovim extension does this for VSCode, I use it
| over the VSCode vim extension which is just an emulator.
| lelanthran wrote:
| I did not know this. My google/brace/ddg foo is failing me.
| Do you have a link to the full reference on how one would use
| headless neovim to provide a full headless vim with a GUI
| wrapped around it?
|
| I'm thinking it would be nice if my Lazarus IDE supported Vim
| commands.
| nixpulvis wrote:
| Great interview!
|
| Love how much thought is being put into what you "gold-plate".
| I've always felt that my best work comes around on round two (or
| three or four...).
|
| Curious what you are planning for the ability to script the
| configuration? I haven't played with zed much yet; is it possible
| today? Would something like Neon [1] help bridge the gap from
| VSCode and old Atom users?
|
| [1]: https://github.com/neon-bindings/neon
| scop wrote:
| > This second is the most dangerous system a man ever designs.
| When he does his third and later ones, his prior experiences
| will confirm each other as to the general characteristics of
| such systems, and their differences will identify those parts
| of his experience that are particular and not generalizable.
| The general tendency is to over-design the second system, using
| all the ideas and frills that were cautiously sidetracked on
| the first one.
|
| - Brooks, Mythical Man Month
|
| It is always interesting to see v2. I have witnessed cases
| where they are catastrophic due to feature overload but also
| cases where they are phenomenal because they are streamlined
| and lean.
|
| I also wonder, with all the tooling available now at least in
| the space of web apps, if this quote notion of danger applies
| as much to v1s as I have seen v1s remarkably bloated these
| days. I often have to purposefully seek out tools that do
| _less_.
| p1esk wrote:
| _help bridge the gap from VSCode and old Atom users_
|
| I went from Atom to Pycharm to Vscode. Both transitions were
| fairly easy. Though I've never had any complex configurations.
| MR4D wrote:
| Fantastic interview where you really get into the mind and
| mindset of the developers for how they approach development from
| many different angles. Highly recommended.
|
| I only have one disagreement with them. . .
|
| > the perfect name for a text editor in Zig is already taken: Zed
|
| No, it's "Zag". ;)
| Terretta wrote:
| > _I only have one disagreement with them. . ._
|
| > > _the perfect name for a text editor in Zig is already
| taken: Zed_
|
| > _No, it's "Zag". ;)_
|
| Except that `zed` contains `ed`, precursor to `ex`, `vi`, and
| `edlin` yet still around:
|
| _`ed` is a line editor for Unix and Unix-like operating
| systems. It was one of the first parts of the Unix operating
| system that was developed, in August 1969. It remains part of
| the POSIX and Open Group standards for Unix-based operating
| systems, alongside the more sophisticated full-screen editor
| `vi`._
|
| https://en.wikipedia.org/wiki/Ed_(text_editor)
|
| While `ag` (the silver searcher) is fantastic, Zed's more about
| editing code than searching code:
|
| https://geoff.greer.fm/ag/
| monkmartinez wrote:
| Except that "Zag" would be at least 3x awesomer[0] as defined
| by things that are awesomer.
|
| [0]https://en.wiktionary.org/wiki/awesomer
| euroderf wrote:
| ed just had a release and nowhere can I find release notes.
|
| This is depressing, considering that ed is the linchpin of
| the contemporary I.T. environment.
| svat wrote:
| Assuming you mean GNU ed (which is the one that has had a
| recent release): https://fossies.org/linux/ed/ChangeLog
| (seems to be a web version of the file
| `ed-1.20.1/ChangeLog` within the ed release itself).
| cjk wrote:
| I only wish they'd realized it was time to start over before
| unleashing the cancer that is Electron upon the world.
| paxys wrote:
| I wish developers would break out of the silicon valley bubble
| and realize that the majority of their potential userbase -
| including technical users - are on Windows and Linux. Heck that's
| the entire reason Atom (and them VS Code) got popular. No one
| cares about the nanoseconds of performance you are able to
| optimize. Working across all my devices and development
| environments (including the web) is table stakes for all software
| today.
| projektfu wrote:
| They do care about latency, and I credit these developers for
| having a goal to minimize it. VS Code isn't bad but when
| regular Visual Studio changed its design like 10 years ago,
| latency and lag went through the roof.
|
| However, the tech stack itself isn't the solution to latency.
| Doing an unbounded operation before responding to input will
| cause it, so will overusing memory and/or cache.
| smoldesu wrote:
| You're right, and it's weird to hear them dunk on Atom when it
| had so many de-facto features Zed still lacks. They're very
| proud of their technical stack and their performance, but it
| feels more like they're defending the cathedral to discredit
| the bazaar.
|
| It's their call, but I feel like I've seen this story play out
| the same way you describe hundreds of times. I'll never forget
| when the warp.dev people came to HN looking for feedback and
| got torn to tatters by the community. A single-platform POC
| editor is cool, but not really a functional replacement (or
| even comparison) to what Atom did and the community it
| garnered. I'm glad they're making what they want, but they're
| absolutely trapped in bubble-vision afaict.
| digdigdag wrote:
| Before anyone jumps on a new text editor band wagon, just a note
| on the license they have you agree to in using it:
|
| "Customer Data consisting of User content created while using the
| Solution is classified as "User Content". User Content is
| transmitted from Your environment only if You collaborate with
| other Zed users by electing to share a project in the Editor.
|
| [...]Zed's access to such User Content is limited to debugging
| and making improvements to the Solution."
|
| No commentary from me. Come to your own conclusions.
| __jonas wrote:
| I would like some commentary from you, sounds very reasonable
| to me, I don't understand what the problem is.
|
| Of course if you choose to share your project with others for
| collaboration, the content of that project is transmitted from
| your machine, what else would you expect? How would it work
| otherwise?
| makeitdouble wrote:
| I didn't get it at first, but as I read it the last "Zed" is
| not the editor but the company.
|
| Basically the Zed company also gets access to the code you're
| sharing with other users.
| dullcrisp wrote:
| In other words, "when you use our servers your data will be
| on our servers but we'll only access it when we're
| debugging our servers."
| mountainriver wrote:
| "And improving our solution" so full access
| wrasee wrote:
| "And when we suffer a data breach (sorry about that)".
| wrasee wrote:
| Exactly. So two people at work share a private session,
| then all user content of that session is directly
| accessible to Zed Industries.
|
| Is that right? If I understand that correctly I think
| that's going to be an instant no for a lot of people.
| keb_ wrote:
| It'd be more appealing if user content was e2e encrypted
| during sessions.
| shp0ngle wrote:
| This actually looks very reasonable...?
| mixmastamyk wrote:
| It's not unreasonable.
|
| The thing is every time you load company proprietary code
| and/or sensitive data you better make sure you don't hit the
| share button as well.
|
| Not the end of the world but also something we didn't have to
| think about until recently. That pushing a button (other than
| delete) could potentially get you fired.
| shubhamjain wrote:
| I used Zed for a while. The biggest performance improvements I
| noticed, compared to VS Code, were in start-up times and the
| opening of files. Sure, Zed feels snappy in those areas, but I
| feel VS Code is simply not that bad speed-wise when it comes to
| everyday coding. Especially, in the era of M1 Macs. Zed may win
| the battle in the longer term, but I feel slow performance has to
| truly annoy the fuck out of the user to convince them to make the
| switch. Right now, I am sticking with VS Code.
| bihla wrote:
| For our team, VS Code is reaching that point. The Macbooks
| can't keep up with VS Code's decay.
|
| Unfortunately Zed lacks good defaults (like a way to change
| tabs without the mouse) and certain vs code features like
| snippets. Makes it difficult to transition a team which has
| been dependent on Vscode and which has absolutely no interest
| in spending our days configuring tools
| dewey wrote:
| Are you running a lot of extensions or giant file sizes or
| how are the computers not keeping up with VS Code?
| satvikpendem wrote:
| I've witnessed both scenarios, yes. In contrast, vim simply
| works.
| mountainriver wrote:
| The ecosystem around VScode is so hard to beat. I found their
| AI features far more limited than what I have available in vsc.
|
| Community usually wins
| the_gipsy wrote:
| > But the goal I've always had is a lightweight editor that is
| minimal that I love using that feels like a text editor, but has
| the power of an IDE when needed, without all of the slowness in
| the experience and kind of heaviness in the UI, but still
| powerful. That was very early on what I wanted. And for it to be
| extensible.
|
| Sorry for being _that guy_ , but vim. Nvim specifically.
| 127 wrote:
| For those wanting a text editor/light IDE for Linux, Kate is
| surprisingly good.
| srini_p wrote:
| Yes, it is my go to editor on Linux. I like the default color
| scheme of this editor very much. And, we can customize it with
| Javascript scripts.
| noodlesUK wrote:
| I tried out the editor because of this post: it looks very
| promising. Unfortunately I can't use it because it doesn't have
| support for remote hosts/devcontiners. That feature of VScode is
| critical to my workflow, as I don't actually want to program on a
| Mac host, but rather use my Mac as a portal to the VMs and
| containers I actually code on. It massively helps with
| segmentation of my projects and improves my security posture (by
| not having a development environment or dependencies on my actual
| host machine).
| FredPret wrote:
| I love this about VSCode. I wish Pycharm could easily do this
| without sending the code away for processing.
| dieortin wrote:
| It can, there is a remote workflow similar to the one from
| VSCode. Search for "jetbrains gateway"
| 8organicbits wrote:
| I use development virtual machines to segment projects and
| clients also although I just run my editor in each VM. What's
| the benefit of the vscode remote hosts/dev containers over a
| normal remote session?
| campbel wrote:
| In my experience its mostly the input lag when dealing with
| the remote environment. I'm quite sensitive to delays in
| editor input, so I prefer something native. If you aren't
| sensitive or your remote connection is fast enough for your
| preferences, I don't think there are many other advantages.
| satvikpendem wrote:
| GPU acceleration is not always guaranteed on the VMs, as well
| as input lag.
| noodlesUK wrote:
| I find that the experience doing this is essentially
| unbearable due to graphics problems on retina displays, input
| lag and the like. I also figure that the kind of person who
| wants an editor which is designed to paint as fast as
| possible probably wouldn't want to have a whole VM and
| spice/similar client sitting between them and the editor.
| xnyan wrote:
| > I just run my editor in each VM
|
| In addition to lag and a poor visual experience as others
| have mentioned, there's the issue of two (or more) operating
| systems with two separate shells/UIs. When using VMs or a
| VDI/remote desktop the cognitive overhead of remembering
| which OS shell I'm in for the purposes of keyboard shortcuts,
| clipboard, switching between programs and etc impacts my
| productivity significantly.
|
| VSCode (or any other editor with similar features) shell is
| great because it completely separates the editor environment
| from the dev environment. I can run as many instances of
| VSCode as I want each with their isolated dev environment of
| the target host, but all managed by one shell, one window
| manager and one clipboard.
| mixmastamyk wrote:
| sshfs solves most of these problems and I've found it good
| enough. Better than switching to a partly proprietary editor
| anyway.
| tormeh wrote:
| Lapce supports this, if you're keen on trying new editors.
| giancarlostoro wrote:
| There was an editor I forgot the name might of been Omnivim,
| which was coded in ReasonML, but compiled natively to a UI, and
| supported VS Code plugins, which is still wild to me.
|
| Anyway, development kind of died off on it, it had insane
| potential in my eyes.
|
| Hopefully Zed can achieve a similar feat (more likely targetting
| VS Code plugins?) or some other rich plugin ecosystem.
| raphinou wrote:
| It was onivim2. Iirc it was a one-man show, and stopped when
| funding dried up. I also hoped to see a a lot from it. Maybe
| the dev took too much work on his plate, with an unproven
| language with limited libraries?
|
| https://github.com/onivim/oni2
| satvikpendem wrote:
| ReasonML is simply OCaml, I wouldn't call that unproven, but
| it does have limited libraries compared to JS or Rust.
| srini_p wrote:
| It has 50% less memory footprint than VS Code on startup, I will
| take it.
| ldelossa wrote:
| Super cool project, which really means nothing when its MacOS
| only :laugh:
| charlie0 wrote:
| Do we really need another IDE?
| Brajeshwar wrote:
| Recently, my faithful Sublime Text journey kind of ended, and I
| did not want to tinker/fix it. I have been using it since its
| first year of release.
|
| So, I had to decide on an IDE to live for the next few decades or
| for as long as I needed one. The final battle was between Emacs
| and Vim. I had played around with both in my prior developer
| life. I took time to read up, play around, and realize I'm not
| living in an IDE (Emacs), so I ended up with MacVim. I set it up
| enough to my liking.
|
| Just as I was getting around, a recent release of Zed surfaced on
| Hacker News. This is my go-to IDE for now. I still fire up MacVim
| for quick edits and to keep learning in case I need to settle
| down on it.
|
| Disclaimer: I'm not a regular developer no more.
| KORraN wrote:
| What are the reasons that you have decided to drop ST?
| blovescoffee wrote:
| I've been using ST for 10+ years. I pulled a copy and
| installed some extensions recently. Most extensions I want
| have multi-year gaps since last updated. ST crushes VS Code
| performance wise but the DX I'm used to with Code is much
| better than in ST because of the community.
| niyyou wrote:
| Sad they do not allow to use a custom OpenAI host address, so one
| can use a local LLM instead (https://ollama.com/blog/openai-
| compatibility).
| miki123211 wrote:
| Their custom UI framework might be all fun and games for now, but
| that will probably change once they realize they need to
| implement accessibility. Doing this in a custom framework without
| sacrificing performance won't be easy and is going to require
| lots of messy, per-platform work. It's not like it's optional for
| them either. It would be for a simple editor that you can just
| decide not to use, but they're positioning Zed as a collaboration
| tool, so making sure that everybody on a given dev team can use
| it is going to be crucial.
|
| I wish developers finally learned this lesson. As a screen reader
| user, I'm sick of all these "modern" tools written in Rust (and
| yes, it's nearly always Rust) where Voice Over just sees an empty
| window. It's far easier to dig yourself out of the trap of no
| accessibility if all you need to do is to slap a few aria labels
| on your buttons and sort out some focus issues than when you need
| to expose every single control to every single OS.
|
| At least there's AccessKit[1] now, which might make the work a
| bit easier, though I'm not sure how suitable it is for something
| as big as an editor.
|
| [1] https://accesskit.dev/
| Jtsummers wrote:
| Here's their only blurb on accessibility:
|
| > Currently, many of Zed's themes are largely inaccessible. We
| are working on a new accessible theme system, which will launch
| with Zed 1.0
|
| > A11y (accessibility) in Zed will be a long project. Likely
| lasting far beyond 1.0. Due to GPUI being written from the
| ground up we don't have access to the same a11y features that
| Swift, Web-based apps or [insert other language] does.
|
| > Making Zed accessible will be a joint effort between things
| on the Zed side, and building out features in GPUI.
|
| > For now, you can join this discussion to talk further about
| a11y in Zed: Accessibility (a11y) in Zed [links to:
| https://github.com/zed-industries/zed/pull/1297]
|
| And that link is useless, it goes to a Github issue about back
| and forward buttons.
|
| https://zed.dev/docs/themes
|
| https://github.com/zed-industries/zed/pull/1297 - the link they
| use that's supposed to be for accessibility discussions. It
| appears it's supposed to be a link to this:
| https://github.com/zed-industries/zed/discussions/6576
|
| So they've thought about it, but they haven't actually done it
| yet.
| sangnoir wrote:
| > So they've thought about it, but they haven't actually done
| it yet.
|
| In my experience, a11y shouldn't be an afterthought but
| baked-in from the beginning. Doing the latter results in
| hacky, harder-to-maintain code.
| notso411 wrote:
| Why bother with accessibility. If a disabled wants to use an
| IDE, use a different one??
| mplewis wrote:
| Accessibility helps all users, not just disabled users.
| pimlottc wrote:
| Which is to say, we are all (temporarily, situationally,
| eventually) disabled in some way
| fanf2 wrote:
| I have most commonly heard this phrased as, we are all
| temporarily able-bodied.
| tonis2 wrote:
| Which accessibility features are you most commonly using ?
| Just wondering, what are the most used accessibility
| features, that new GUI-s don't have.
| mikojan wrote:
| Focus and focus management working as expected
| sangnoir wrote:
| It can take an instant to become disabled: there is no
| permanent and distinct set of "disabled and "not-disabled"
| people.
| andrewflnr wrote:
| Not to defend GP, but if I suddenly went blind, I really
| don't know if it would take longer to learn how to use my
| existing tools with a screen reader or to learn new tools
| better designed for it. It would be a completely new and
| foreign workflow either way.
| kevingadd wrote:
| I'll take this seriously since lots of people probably wonder
| this even if they don't bother to ask it.
|
| Disability isn't a permanent state that you start with. It's
| something that can happen to you 5 years into your career, or
| 15. It can also be _temporary_ - you break your leg and now
| you need crutches, a cane or a wheelchair until you heal, for
| example.
|
| Accessibility also helps people who you wouldn't
| traditionally classify as disabled: Designing UI to be usable
| one-handed is obviously good for people who have one hand,
| but some people may be _temporarily_ or _situationally_ one-
| handed. Not just because they broke an arm and it 's in the
| cast, but perhaps they have to hold a baby in one arm, or
| their other hand is holding a grocery bag, or they're lying
| in bed on their side.
|
| Closed captions in multimedia software or content are
| obviously helpful for the deaf, but people who are in a loud
| nightclub or on a loud construction site could also benefit
| from captions, even if their ears work fine.
|
| So, ultimately: Why should someone who's used to using a
| given editor have to switch any time their circumstances
| change? The developers of the editor could just put the
| effort in to begin with.
| markisus wrote:
| I'm guessing this was downvoted for being rude, but I think
| there is a valid question here. It looks like Zed is putting
| a lot of work into minimizing the latency between a key being
| typed and feedback being displayed on a visual interface
| which is easily parsed by a sighted user.
|
| If a programmer is using audio for feedback, then there is
| probably be some impedance mismatch by translating a visual
| interface into an audio description. Shouldn't there be much
| better audio encoding of the document? There would also be
| many more wasted cycles pushing around pixels, which the
| programmer will never see. An editor made specifically for
| visually impaired programmers, unencumbered by the
| constraints of a visual representation, would be able to
| explore the solution space much better than Zed.
| Szpadel wrote:
| I'm not surprised that most of rust guis are not a11y friendly,
| there is no established gui library yet, none of them I would
| call mature yet
|
| Not long ago there weren't any gui libraries that wouldn't be
| just binding to existing C framework or was in proof of concept
| state of lifecycle
|
| I'm sure this situation will improve in the future and I
| understand frustration of someone that rely on a11y features,
| but you need to understand that everyone first will try to
| achieve solid gui library before will start adding accessable
| functionality
| yoyohello13 wrote:
| System76 is making headway getting a11y accessibility for
| Cosmic Desktop. They are doing a lot of good work in the Rust
| gui space.
| Szpadel wrote:
| Agree, I think they might shape first mainstream rust gui
| library.
|
| They are doing amazing job with whole desktop environment.
| I'm yet to check first hand their work, but so far looks
| very promising
| CharlesW wrote:
| > _I wish developers finally learned this lesson._
|
| From a product perspective, re-inventing the wheel for
| something that -- at best, many years from now -- will be at
| parity with native presentation layers in terms of performance,
| a11y support, user experience, etc. is normally considered a
| risky move. Many startups have failed in part from pouring
| resources into shiny non-differentiators.
|
| The only examples of successful products that use non-native
| UIs either (1) leverage web technologies or mature frameworks
| like Qt, or (2) are Blender (age 30). Apple did this with
| iTunes, but iTunes felt unpleasant on Windows, and people used
| iTunes for Windows in spite of this. I understand the appeal of
| creating frameworks like GPUI, but the article doesn't explain
| the relationship to the problem Zed is trying to solve.
| miki123211 wrote:
| There's also Zoom, which apparently uses an internal,
| heavily-modified fork of some Chinese UI framework on Windows
| (and QT on everything else). They did go the extra mile and
| add accessibility support though, their American clients,
| particularly the ones in government, healthcare and
| education, didn't really give them any other option.
|
| There's also Google Docs, which uses weird tricks instead of
| rendering straight to DOM. They didn't even bother
| implementing accessibility in that layer, something which
| would probably have been impossible back then. Instead, they
| offer an accessibility mode and mark their entire UI as
| hidden to assistive technologies. When the accessibility mode
| is on, all speech is generated by a micro screen reader
| implemented in Google Docs directly, and the generated
| messages are sent as text to be spoken by your real screen
| reader. This is an ugly hack that doesn't really support
| braille displays very well, so they later implemented yet
| another layer of ugly hacks that retrofits the document on
| top of an actual DOM.
|
| Your point still stands though, these are exceptions that
| prove the rule.
| pmarreck wrote:
| Honest question out of curiosity-
|
| Are there possibly AI-based solutions possible that can add
| assistance at a more generic level that doesn't require
| software that has "deep" knowledge of the window architecture
| (and the actual text in it etc.)? My understanding is that this
| is how tech like VoiceOver works- it knows the actual window
| definition and all the elements of it at a programmatic level
| and can take advantage of that.
|
| I'm not asking if they're already available (although that
| would be a nice option), but for projects like this that wanted
| the speed of rendering on the GPU (at the possible cost of, as
| you said, VoiceOver seeing an "empty window"), it would be at
| least a fallback position.
|
| (So does this mean that ALL content that renders through the
| GPU, such as games, are inaccessible to you? If so, I'm
| sorry...)
|
| Not sure if this might help you but I have an Apple shortcut
| defined on my iPhone called "GPT Explains" that is activated by
| a double-tap on the back of the phone (which you can assign, as
| you probably know, in Accessibility settings)- it takes a
| screenshot, ships it off to OpenAI and returns with a
| description of what it's seeing, any to-English translation of
| non-English text, and any counterarguments to any claims made
| in a meme, etc. (yeah, the prompt for this is kinda wicked,
| lol). If this is helpful to you, I can give you a link after I
| remove my OpenAI key (you'd have to provide your own).
|
| EDIT: I made a copy of it without the API key:
| https://www.icloud.com/shortcuts/0d063c6810d74a35a017e5a5f69...
| miki123211 wrote:
| iOS already has such a feature, but it's obviously not 100%
| accurate, not real time, and not great for battery life.
|
| It's good enough if you have to click a broken "I accept your
| terms and conditions" checkbox, but nowhere near good enough
| to daily drive your phone with. In other words, a band-aid
| solution for when everything else fails, mostly for
| situations where the app you're trying to use is mostly
| usable, but has an accessibility barrier preventing you from
| carrying out a crucial step somewhere.
|
| There's also vocr on Mac (and equivalent solutions on
| Windows), which recently got some AI features, but it doesn't
| even recognize control types (a very basic feature of any
| screen reader), just text. Again, good enough to get you
| through most installers where all you're doing is clicking
| "next" ten times, probably good enough to get you through the
| first-run experience in a VM that doesn't yet have a screen
| reader installed, at one tenth the speed of a sighted person,
| but that's about it.
| intalentive wrote:
| The part about just using the underlying primitives instead of
| relying on a 3rd party's abstraction layer really resonated with
| me. As often as not I find myself fighting with the abstraction
| and having to go down a layer, where there is much greater
| freedom.
|
| >I don't know about zero cost -- every abstraction has a cost, I
| guess
|
| Part of the cost Rust incurs is the compile time. But thanks to
| LLVM it seems you can in general have zero-cost abstractions, if
| we mean high level syntax with low level performance. Feels like
| a golden age of language design atm.
|
| Anyway, the "let's do it right, and do it ourselves" philosophy
| is attractive and I'll be downloading Zed to check it out.
| briandw wrote:
| I really love native apps, but I'm stuck using VS code for now.
| It just kills me to see how much power goes to blinking the
| cursor in VS code. I tried Zed for a bit but couldn't make it
| work. I loved that its so light weight and fast. Looking my all
| my VS code processes it 3GB vs Zeds 300MB. 1/10 the ram is a
| meaningful difference. However I really need the Jupyter Notebook
| support that VS code provides. I'm also too used to doing remote
| dev on a Ubuntu box from my mac and VS code works great for that.
| I hope they stick with it long enough to get to supporting my
| workflow.
| briandw wrote:
| Looks like the Notebook request has been open for over a year.
| https://github.com/zed-industries/zed/issues/5273 So according
| to the Lindy effect https://en.wikipedia.org/wiki/Lindy_effect,
| it'll be more than a year before we see anything.
| a_wild_dandan wrote:
| I guess that I'm lucky. I presently have multiple VS Code
| projects open (local & remote), and a Notebook running, and
| rarely break ~650MB -- less than 1% of my Macbook's memory.
| Maybe everyone has more extensions on than I do or something.
| jazzyjackson wrote:
| As a lowly web developer I must not know what i'm missing, can
| anyone explain what the issue is with an array being a list of
| references? Why is there a chase going on, is someone trying to
| get away?
|
| > JavaScript is... You think you have an array of objects, but
| you really have an array of pointers to objects. So every single
| time you're walking over that, you're chasing it down.
| taspeotis wrote:
| Pointer chasing, bad for cache locality.
| jazzyjackson wrote:
| ah, that closes the loop for me, thanks
| qwertox wrote:
| I think it refers to the fact that you can't just compute an
| offset from element 0 to get to an element N, like you could if
| you'd have an array of structs or classes. Assume a struct uses
| up 128 bytes, then you can get to element N by using a pointer
| of N * 128 and you'd be positioned directly at the memory
| location of that struct. - Edit: cache locality like sibling
| comment mentions sounds more convincing.
| losvedir wrote:
| I don't use Zed, but I noticed Jose Valim using it when he was
| live streaming a coding session. I mostly use VSCode, but one
| feature he used in Zed was really compelling: he did a "Find
| All", which was similar to VSCode in that it opened a results
| pane with snippets from all the files that matched, but _then_ he
| was able to edit the snippets _directly_ from there, and was able
| to use multi-cursor editing and all the other usual niceties.
| That was pretty neat and impressive to me, since in VSCode you
| have to actually click the search result to open the file, and
| then edit it there. It wasn 't quite enough to make me switch,
| but I've been thinking about it from time to time whenever VSCode
| annoys me.
| czottmann wrote:
| This sounds like it could be very useful. Does it work like
| this VSCode extension, "Search Editor: Apply Changes"?
|
| https://marketplace.visualstudio.com/items?itemName=jakearl....
| losvedir wrote:
| Mmm, -ish. I searched for an extension in VSCode when I saw
| it in Zed, and that extension came up. But it looks like you
| still have to open the editor tab to save it and stuff. It
| was much more streamlined in Zed. You just made the change
| right there, and I think if you hit "save" on the search
| results it would save to all the files that you touched.
| hprotagonist wrote:
| emacs has had occur and multi-occur since the 80s that can do
| this. it's amazing.
|
| more recently, interfaces to tools like ripgrep also have the
| ability to have an editable mode, super handy for refactoring.
|
| (and of course you can edit file names in bulk, too ..)
|
| https://www.masteringemacs.org/article/searching-buffers-occ...
|
| https://rgel.readthedocs.io/en/latest/
|
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Wd...
| difflens wrote:
| Hmm maybe I don't understand fully, but can't you do this in
| VSCode by doing a `Find And Replace All`? (Cmd + Shift + F on
| Mac)
| fatboy wrote:
| In VSCode if you do super-shift-f for find-in-project, at the
| top of the results pane, just right of where it's marked "x
| results in y files" there's a link button titled "Open in
| editor" which I believe does what you're describing. I'd
| actually forgotten about it until I read your comment so I'll
| start using it again now.
| losvedir wrote:
| I don't seem to have that. There's nothing to the right of my
| "x results in y files" summary. Maybe you have an extension
| installed?
| quickthrower2 wrote:
| That is neat. It would avoid the need to craft regex in many
| case.
|
| One of my favourite tricks is multi cursor, edit and use end of
| line or next word shortcuts to make bulk edits.
|
| Doing that across files would be cool!
| brigadier132 wrote:
| Jetbrains ides already do this.
|
| It's absurd but one of the primary reasons I use Jetbrains over
| vscode is because i can search for a directory and open it in
| the navigation pane.
| coolgoose wrote:
| One thing I don't get, and I hope I didn't miss an obvious
| comment, is that for all the complains about elektron and js
| being slow, vscode was and still is faster than atom.
___________________________________________________________________
(page generated 2024-02-17 23:00 UTC)