[HN Gopher] Zed on Linux Is Here
___________________________________________________________________
Zed on Linux Is Here
Author : 0xedb
Score : 404 points
Date : 2024-07-10 16:56 UTC (6 hours ago)
(HTM) web link (zed.dev)
(TXT) w3m dump (zed.dev)
| lbhdc wrote:
| Zed seems like its gotten a lot of buzz on HN, and its great to
| see new players in the space.
|
| For those who have used it, what are some of the killer features?
| threatofrain wrote:
| No killer features, just nice ergonomics and speed out of the
| box. I use it as my Vim replacement.
| renewiltord wrote:
| Do you use it for Rust? Does it do "Show usages" well when
| the usages are through a macro?
| nickorlow wrote:
| What motivated you to switch to it from vim?
| boomskats wrote:
| Do you find it to be faster than vim/neovim?
| vehemenz wrote:
| The Vim emulation is pretty far behind JetBrains, VSCode,
| and Sublime Text. I wouldn't compare it to Vim as a
| replacement at this point.
| choilive wrote:
| Its killer feature seems to be speed. Otherwise I dont see much
| of a reason to use it over VS Code.
| gavmor wrote:
| Have you had much success with VS Code's multiplayer
| extensions? I've found them buggy to the point of useless,
| but maybe things have improved. Zed, on the otherhand, is
| developed by people who understand pair programming, which is
| my priority.
| choilive wrote:
| No not much experience there since multiplayer editing has
| never really been a part of my personal workflow (mostly a
| lot of screensharing), but I can definitely see that being
| useful for people that use it regularly.
| cmiles74 wrote:
| Not the OP but I tried hard, looking for an easy pair
| programming solution. Worked decently a couple of times and
| inexplicably failed most of the time.
| gavmor wrote:
| This is why I'm excited to try Zed. I regularly "pair"
| via Pop, but keybindings and lag make it hard to switch
| seats, so we basically decide at the beginning of the
| session who is going to hog the keyboard, and that's a
| crippling dynamic.
| nequo wrote:
| Besides speed, the other killer feature that Zed focuses on is
| collaborative editing:
|
| https://zed.dev/docs/channels
| wolfadex wrote:
| For me the "killer feature" is a graphical editor (like VSCode
| or the Jet Brains editors) but with performance more like vim.
| I'm also very much enjoying the modal editing, which VSCode
| lacks.
| thesuperbigfrog wrote:
| >> I'm also very much enjoying the modal editing, which
| VSCode lacks.
|
| The VSCode Vim plugin works great:
|
| https://marketplace.visualstudio.com/items?itemName=vscodevi.
| ..
| wolfadex wrote:
| When I specified the modal editing I was referring to how
| the workspace search in Zed brings up each result in an
| editable "window" allowing me to make edits across my whole
| project from 1 tab. VSCode's workspace search feels much
| more limited in comparison.
| thesuperbigfrog wrote:
| That sounds like an interesting feature. Could you
| provide a link that gives more information about it? I am
| not finding it in the docs.
| wolfadex wrote:
| I'm not seeing it in the docs, maybe I should write up a
| little something on my editing experience!
|
| Also to correct my self, I think I mistakenly said
| `modal` when I should have said `buffer` earlier.
|
| So searching across the project brings up your results in
| multiple buffers, each about 5 lines (expandable to more)
| and you can do all of your normal editing within each/all
| of the buffers.
|
| If I happen to write something up, I'll try and remember
| to share it in this thread.
| thesuperbigfrog wrote:
| That is a unique feature. Most editors I have used use
| the search as a way to jump to buffer locations of the
| matches.
| mikaylamaki wrote:
| We call them 'multibuffers' :D
|
| https://zed.dev/features#multi-buffers
| unshavedyak wrote:
| Wait, Zed is a modal editor? All i've seen is that it has vim
| mode, which most editors have and i generally find it
| insufficient.
|
| Granted these days i still prefer Kakoune style modal editing
| (i use Helix, currently), so not sure i could move back to
| Vim style anyway. Nonetheless if Zed has real, first class
| support i'd be interested... but a second class compat layer
| is not sufficient in my view.
|
| How's it work for you?
|
| _edit_ : https://news.ycombinator.com/item?id=40929169 this
| post suggests it's lacking. Which is always the problem to me
| with emulation :/
| satvikpendem wrote:
| It's not a modal editor, it just has a modal (vim)
| emulation mode.
| Zambyte wrote:
| FWIW Emacs also fits that bill.
| wolfadex wrote:
| It does, though I found learning and setting it up to be
| more complicated. My preferred editor is one that's very
| simple to setup and use (e.g. Sublime, VSCode, Zed, nano).
| Emacs is cool, and maybe someday I'll get around to using
| it but so far it hasn't met my needs.
| Zambyte wrote:
| Fair enough, I have personally spent a decent chunk of
| time configuring my Emacs setup (though it has mostly
| stabilized at this point). You may be interested in
| checking out Doom Emacs[0] if you want to take a stab at
| it in the future. It sounds like it would be an out of
| the box experience closer to what you would want.
|
| [0] https://github.com/doomemacs/doomemacs
| drcongo wrote:
| I use it as my secondary editor (after Sublime) but could
| easily see myself switching in the not too distant future. It's
| incredibly fast, possibly even more so than Sublime, and really
| well designed. While the UI design of an editor is possibly not
| that important to a lot of people, I find it really matters to
| me for unknown brain reasons, I get anxious if I ever have to
| use VS Code as it has zero attention to design details.
|
| I'm really pleased for the Zed team on reaching this milestone.
| I think the only thing holding me back from it being my daily
| driver is the built-in Pyright (which I hate) and lack of Ruff
| support.
| pcthrowaway wrote:
| I haven't used Zed in the last year, but Zed's search across
| codebase display was _divine_. I don 't want to necessarily
| open the file when looking at search results to see additional
| context in the matching sections. Zed brings up a view with all
| the results where you can expand context, and IIRC even edit in
| the results panel without having to open the entire file.
|
| It's also collaboration-first, and unlike VS code, I believe
| the software behind collaboration mode is open source
| barrell wrote:
| For me, a couple things;
|
| - fast enough to compete with neovim. Idk if it's my previous
| interest in display engineering, but I substantially notice the
| speed
|
| - vim bindings.... Satisfactory. I don't struggle to navigate
| at all, feels pretty native to me. I can split panes every
| which way till Sunday
|
| - collaboration mode is pretty great
|
| - Ability to have your current pane magnified
|
| - Ability to set your terminal font size to a different font
| size than your editor (been looking for this for years in a
| terminal emulator)
|
| - Super clean and crisp ui. TBH it was too much ui when I first
| tried it, I stopped using it almost immediately. But I have it
| a second try and got used to it. It's still a lot more than vim
| but hey
|
| - Outline mode (pretty sweet)
|
| - Multi-file buffers (makes editing text across multiple files
| stupidly easy)
|
| - Cracked team. Awesome people, super transparent, just some
| sick engineers doing sick engineering
| jak2k wrote:
| Now they just need a flatpak...
| mikaylamaki wrote:
| We have a flatpak build! It's not on flathub yet though :)
|
| https://github.com/zed-industries/zed/blob/main/docs/src/dev...
| correct-horse wrote:
| I really don't have much to say, just wanted to thank you for
| officially releasing a Linux build, and supporting us at all.
| We, the silent majority, very much appreciate your work.
| Every release of every application brings out the moaners,
| this is to be expected. Thanks.
| insane_dreamer wrote:
| Awesome. Been looking for a next-gen Atom for coding. I use
| PyCharm most of the time, but sometimes its overkill with its
| eternal indexing ... :) So I often find myself bringing up
| SublimeText for working on individual files as opposed to a whole
| project.
| insane_dreamer wrote:
| At first I thought this might be a creation of Zed Shaw (whose
| Learn Ruby the Hard Way, was the best introduction to that
| language, back in the day; and Mongrel was great).
| romwell wrote:
| I can vouch for "Learn C The Hard Way" as well :)
| simonw wrote:
| Instead it's a creation of the team who built Atom, Tree-sitter
| and Electron. Pretty solid resume!
| insane_dreamer wrote:
| Absolutely.
| cassepipe wrote:
| vim mode in the json settings:
|
| "vim_mode": true,
| whalesalad wrote:
| Really dislike the one line installer. How is it installing?
| Flatpak? Adding an apt repo? Manual install?
|
| Fortunately docs go into better detail,
| https://zed.dev/docs/linux
|
| I'm on Debian anyway so who am I kidding expecting this to be in
| apt :D
| bscphil wrote:
| It's already in the Arch Linux repositories, which is pretty
| cool: https://archlinux.org/packages/extra/x86_64/zed/
| anotherhue wrote:
| Am I missing something? NixOS has had it since April
| https://github.com/NixOS/nixpkgs/commits/nixos-
| unstable/pkgs...
| bscphil wrote:
| Yeah apparently there have been working builds since at
| least January, that's when the PKGBUILD was created: https:
| //gitlab.archlinux.org/archlinux/packaging/packages/ze...
|
| It's been in the main repos since May.
| porphyra wrote:
| You can just read the script that you're curling rather than
| pipe it into sh directly. It seems like it just extracts the
| binary from a tar.gz and puts it into ~/.local.
| fao_ wrote:
| "reading a script" is actually a worse user experience on
| Linux than just using repositories or flatpak, though. It's
| pretty rude of software developers to put the onus on users
| to verify that they're not doing something outright malicious
| in terms of the installer.
| jfvinueza wrote:
| so you feel offended by this
| janalsncm wrote:
| Instead of pasting it in terminal, I opened a new tab and
| read it. There's maybe 200 lines, most of which aren't
| relevant to my platform. Didn't see anything unusual.
|
| I then proceeded to install tens of thousands of lines of
| code I didn't read onto my machine.
|
| My point? People really seem to be bike shedding this
| install script bit. If I was a malicious actor I wouldn't
| be hiding the bad parts in the install script.
| whalesalad wrote:
| 200 lines versus the actual install steps which is 1.
| wget the tarball, 2. extract the tarball to .local/bin,
| 3. done, or a few more steps to add the desktop file.
| shepherdjerred wrote:
| Are you not concerned with the software developers doing
| something outright malicious in the software itself?
| BanazirGalbasi wrote:
| Most repositories have some sort of vetting process as
| far as I'm aware. In the case of Zed, because it's open-
| source, it can be examined more completely, although I
| don't think it's expected for every update to be heavily
| scrutinized.
|
| In the end, at some point you either have to inspect
| every line of code yourself or trust others to have done
| it for you. Package managers fall into the latter
| category.
| deciduously wrote:
| Pipe the script to cat before you pipe it to sh and take a
| look. It's downloading an executable to ~/.local/bin. If that's
| not your preference, there are many other options for obtaining
| the software, via your distribution or manually. I feel the
| backlash to this pattern is pretty overblown. They're not
| attempting to hide anything, just make the common case
| convenient.
| whalesalad wrote:
| Sure, but that convenience will come to bite you later. What
| happens when you want to update it?
|
| Their full install docs is like 5 lines of code so it is much
| preferred to do it that way. Every distribution is different.
| The ideal install here would be to add a unique apt repo for
| zed and then it becomes part of my normal update process.
| Updating a binary in a directory is not the end of the
| world... but I would prefer to know that upfront versus
| needing to hunt down where it was placed in order to do the
| updates.
|
| edit its 4 lines. seeing this is much preferred to parsing a
| bash script that is intended to support all distributions:
| wget https://zed.dev/api/releases/stable/latest/zed-
| linux-x86_64.tar.gz mkdir -p ~/.local tar
| -xvf zed-linux-x86_64.tar.gz -C ~/.local ln -sf
| ~/.local/bin/zed ~/.local/zed.app/bin/zed
| pkage wrote:
| A lot of the backlash is around the tool downloading and
| running an arbitrary shell script which could contain
| anything, and overlooks the fact that that shell script then
| downloads an opaque binary which could also contain anything.
| If you're paranoid about security read the code and build it
| from source, otherwise curl | bash is trusting the authors
| just as much as any other method.
| cogman10 wrote:
| Probably the biggest problem with the `curl | sh` approach
| is it bypasses package maintainers. I agree it's really no
| different than if you compiled malicious code yourself (or
| pulled in a 3rd party bin repository). However, one of the
| functions of a package maintainer is finding/being notified
| of security issues.
|
| I'm thinking of the recent xz attack. Imagine how bad that
| would have been if xz was commonly installed via `curl |
| sh`.
|
| All this is to say `curl | sh` is probably fine if the org
| is reputable, however, you should be having second thoughts
| if this is a repo ran with a bus factor of 1.
| Levitating wrote:
| I think for most it's not a security issue but a system
| maintainence one. Where does the script install what?
| jtriangle wrote:
| Suggesting that users install software outside of official
| repos isn't more convenient than using a repo and standard
| package management tools. As soon as there's an update,
| you'll learn exactly why that is the case.
| deepsun wrote:
| Yep, it's the same as running random code with root
| permissions.
|
| Same as running random .exe from emails, but even without M$
| signature.
|
| Apt packages also have the root access, but official
| repositories at least have some paper trail and release
| process.
| abhinavk wrote:
| > Yep, it's the same as running random code with root
| permissions.
|
| It doesn't require root. You can read it before you run.
| whalesalad wrote:
| "reading before you run" eliminates all convenience of the
| one liner. Their linux docs are way better because it shows
| you exactly how to do it on a per-distribution basis. when
| it comes time to update the software I would prefer to know
| how exactly it is installed so that I can update it
| correctly.
| rad_gruchalski wrote:
| > when it comes time to update the software I would
| prefer to know how exactly it is installed so that I can
| update it correctly
|
| Then read the script you complain about.
| whalesalad wrote:
| Three months from now I won't remember using the script
| to install it. And the contents of the script could
| completely change. This is not a helpful take.
| rad_gruchalski wrote:
| This is not a helpful take _for you_. The same method
| works fine for me over the last decade. Taking notes
| helps, having some helper scripts helps. If one's
| invested in a technology, one finds a way to remember.
| ericjmorey wrote:
| You just described how the script is less convenient to
| meet the preferences of the commenter you replied to.
|
| A debian package relieves them of the overhead you
| describe by having a few people do the work for anyone
| else that uses the package.
| rad_gruchalski wrote:
| Debian packages are often old. Hence people found a way
| around.
|
| > You just described how the script is less convenient to
| meet the preferences of the commenter you replied to.
|
| Well... no. The person I reply to doesn't say anything
| about preferences. They want to know how to update the
| software, the script is the best reference.
| shrimp_emoji wrote:
| > _Debian packages are often old._
|
| What about AUR or Fedora packages? ;D
| rad_gruchalski wrote:
| No clue man. Don't use any of it.
| whalesalad wrote:
| I am glad to hear you have room in your life to tend to
| idiosyncracies like this.
| rad_gruchalski wrote:
| It's part of the job. That's one of the things I'm paid
| for.
| whalesalad wrote:
| Paid to screw around with your editor installation? Or
| paid to edit code.
| rad_gruchalski wrote:
| You know nothing about what I do. Keep editing code. You
| just grind on an infrastructure brought to you on a
| silver plate? Like an editor is the only thing we have
| fuck around with.
|
| That script for the editor is code, too...
| whalesalad wrote:
| I do it all brother. Infrastructure is the fun/easy part.
| fragmede wrote:
| I find organizing and saving files to disk is a great way
| to save things I won't remember. Maybe you could try
| that?
| deepsun wrote:
| I do it from time to time, but it's time-consuming
| (proper install scripts are long), defeating the whole
| goal of "one-line installer".
|
| With proper installers I never read it's install scripts.
| whalesalad wrote:
| I am less concerned about it being malicious and more
| concerned about it doing something I do not want re: how the
| software is installed. Installing software from the
| distributions package manager is always preferred to doing
| something manual. When it comes time to update the app, I
| would prefer to not have to do that in a roundabout way.
| abhinavk wrote:
| It's a basic download and extract script. Also creates
| directories as per XDG spec.
| igorguerrero wrote:
| I hope it gets packaged, on NixOS there's a package already on
| stable and unstable.
| figomore wrote:
| There is some support to flatpak already, see
| https://github.com/zed-industries/zed/blob/main/docs/src/dev...
| AndyKelley wrote:
| > To install Zed on most Linux distributions, run the shell
| script below.
|
| This is not an acceptable way to install anything on Linux. If
| you want to target Linux users you can't distribute with a shell
| script for installation.
|
| I get that the idea is to reduce friction to installation and
| trying it out, but most Linux users - the ones you want filing
| bug reports anyway - are ones who will do due diligence and
| inspect the shell script to see what kind of opinions it makes
| about how to install the software.
|
| For example, I see that the shell script downloads a tarball and
| unpacks it to `~/.local`, then tries to mess with my PATH
| variable.
|
| Well, my local directory is `~/local`. So that's not where I want
| it. Actually, I would want it in `~/local/zed`, isolated from the
| rest of the installations in there. Then the PATH variable stuff
| just creates junk files since I don't use zsh. So I end up having
| to figure out the URL to the tarball and install it myself.
|
| My point is that if you just listed the download link to the
| tarball, it would actually be closer to your own goal of reducing
| installation friction. The shell script is so much more friction
| because I have to read bash code instead of just clicking a
| download link.
| pkage wrote:
| This is a fairly common way to install tools on Linux.
| Tailscale, Homebrew, Pi-hole and many others offer
| installations in this way.
| AndyKelley wrote:
| The same criticisms apply to Tailscale, Homebrew, Pi-hole and
| all those others.
| usr942568903890 wrote:
| > The same criticisms apply to Tailscale
|
| No it doesn't.
|
| Tailscale's shell script is entirely optional and installs
| a distro/package manager specific package. It also doesn't
| mess with your PATH variable.
|
| They maintain packages for most popular distros as you can
| see here https://pkgs.tailscale.com/stable/.
|
| The sibling comments are just spreading misinformation
| because those people were too lazy to actually look
| anything up.
| lagniappe wrote:
| Not an argument.
| nicce wrote:
| While it is fairly common way, it does not mean that it is
| good way.
| hypeatei wrote:
| > you can't distribute with a shell script for installation
|
| Why not? It worked for me.
| drdaeman wrote:
| There are two schools of thought. One strives for
| correctness, even if that requires extra effort. Another is
| "anything goes as long as it somehow kind of works more than
| it doesn't."
|
| (Actually it's most probably a spectrum rather than a binary
| division, but I'm no philosopher or sociologist, so for
| example's sake I'll operate with this simplified model here.)
|
| The world en masse is generally preferring the latter
| (picking the easiest solutions, no matter how shitty they are
| - that's how we ended up with what we have today*), but among
| the engineers there are a significant number of people who
| believe that's how things should be.
|
| There are numerous issues with copying and pasting `curl |
| bash` invocations from random webpages: all sorts of
| potential security issues, the installed software (if it
| works) could be installed in a way different from how your
| OS/distribution does things (or from your personal
| preferences), leading to all sorts of future issues, etc etc.
| Someone probably has a good write-up on this already. But -
| yeah - on the other hand, it works for number of people.
|
| ___
|
| *) And, of course, the opinions if what we have today is
| "good progress" or "unbearable crap" also vary.
| RamRodification wrote:
| _> There are two schools of thought. One strives for
| correctness, even if that requires extra effort. Another is
| "anything goes as long as it somehow kind of works more
| than it doesn't."
|
| ...
|
| The world en masse is generally preferring the latter
| (picking the easiest solutions, no matter how shitty they
| are - that's how we ended up with what we have today_), but
| among the engineers there are a significant number of
| people who believe that's how things should be.*
|
| I often have trouble articulating this at work. I will
| steal this and use something like it when advocating for
| correctness as opposed to shitty short sighted solutions.
| Thanks
| TiredOfLife wrote:
| Here is .tar for correct way:
| https://zed.dev/api/releases/stable/latest/zed-
| linux-x86_64....
|
| And here is even more correct one:
| https://zed.dev/docs/development/linux
| correct-horse wrote:
| | among the engineers there are a significant number of
| people who believe that's how things should be
|
| There are close to zero people who tend to think like that
| among actual _engineers_. That 's why we have reliable
| transportation and bridges and skyscrapers that work for
| (soon to be) centuries. On the other hand, we have lots of
| them among self-professed "engineers" who have changed many
| monikers over the past couple of decades and will probably
| call themselves "gods" in a few more years down the line.
| drdaeman wrote:
| > There are close to zero people who tend to think like
| that among actual engineers.
|
| Oops. My apologies - I meant exactly that, that a
| significant number of engineers believe in correctness
| and sound approaches, but I had a brain fart writing that
| comment. It should've been "believe in the former".
|
| No idea about how many non-software engineers take
| various shortcuts, though. But I think there's a non-
| negligible number of electronics engineers who do so -
| I'm not an expert in that field, but it's not unheard of
| skipping coupling capacitors or using a resistor divider
| instead of a voltage regulator to cut down the costs
| (because that still works... until it doesn't, of
| course).
| kelnos wrote:
| Don't apologize; GP is being a pedant in order to pick a
| fight. The "real" definition of "engineer" doesn't
| matter; your post makes just as much sense if you'd
| instead used "software developers".
| correct-horse wrote:
| It might be a cheap word in the US, the precise
| definition matters in many countries.
| kelnos wrote:
| Can we please instead interpret people's comments in a
| charitable manner, as we can reasonably assume they were
| intended, not in the manner that allows us to pick
| pedantic fights with them?
| igorguerrero wrote:
| It's on NixOS and Arch I'm sure you just wait a little to get
| it on your Distro... I don't think they have bad intentions.
| nmstoker wrote:
| I agree they probably don't have bad intentions. But other
| options still seen better than the one liner.
|
| Even just as a two liner leaves people a copy of what they
| ran if something goes awry.
| odo1242 wrote:
| See https://zed.dev/docs/linux#other-ways-to-install-zed-on-
| linu... for distro packages.
| LocalGauge wrote:
| This also includes the link to the tar files, so, you dont
| need to read the bash file to download tar file. The ones who
| are interested in this issue will spot this page, anyways.
| Maybe, they can make it more convenient for visitors to check
| this page.
| vanviegen wrote:
| This comes across as rather entitled. They offer an easy
| installation path that works for most people. They also went
| out of their way to provide alternative installation methods
| and instructions [1]. All while gifting you and the world free
| and open source software.
|
| [1] https://zed.dev/docs/linux
| AndyKelley wrote:
| My interest is not in using this text editor as a consumer,
| but in guiding software development culture in general,
| particularly when it comes to installation of Linux
| applications.
|
| Some talks I have given on this topic:
|
| https://www.youtube.com/watch?v=pq1XqP4-qOo
|
| https://www.youtube.com/watch?v=CwXixVcliP0
|
| So, I think "entitled" is the wrong insult. "arrogant" would
| be more accurate.
| jayde2767 wrote:
| "Opinionated" is more appropriate. Ignorance often
| accompanies arrogance. Opinion, to me, at least contains a
| degree of knowledge.
| jarule wrote:
| You've dedicated your adult life to massaging ABIs and
| openly admit your "non-polished" solution is an idealistic
| holy grail, and yet you expect some text editor with a non-
| existent path to profitability to have hewn to your every
| private thought about Linux binary versatility, and that
| sir is bullshit.
| maxbrunsfeld wrote:
| As a point of clarification, the script does not edit your
| zshrc file, it just prints a suggested edit that you _may_ want
| to make to that file in order to add zed to your PATH.
| NormenKD wrote:
| They aren't happy with this, either:
|
| "[...]And of course, the journey isn't over yet-we'd love your
| help, particularly if you're excited about:
|
| - Helping bring Zed to your distro. Either by packaging Zed or
| by making Zed work the way it should in your environment (we
| know many people want to manage language servers by
| themselves).[...]"
|
| Give them a hand ;)
| https://zed.dev/docs/development/linux#notes-for-packaging-z...
| AndyKelley wrote:
| I sympathize with the situation that Zed developers are in.
| They are thinking of the user experience first and foremost,
| and when trying to distribute on Linux, faced with an
| overgrown, chaotic landscape that utterly fails to provide
| the basic needs of application developers, such as the
| ability to distribute a binary that has no dependencies on
| any one particular distribution and can open a window and
| interact with the graphics driver, or the ability to require
| permissions from the user to do certain things.
|
| I do think that my work contributes to help with this use
| case. Looking elsewhere on this thread I see that they are
| having problems fetching and running a nodejs binary
| successfully. Fortunately, nodejs is a piece of software that
| can be built and distributed statically. I have not packaged
| up this one in such a manner but I have done a proof of
| concept with CPython:
| https://github.com/allyourcodebase/cpython
|
| That said, if they want to allow users to install Zed through
| a system package manager, they will need to cooperate with
| the system and rely on system nodejs instead of trying to
| fetch it at runtime. Fetching and running software at runtime
| is fundamentally incompatible with the core mission of Linux
| distributions (curation, vetting, and compatibility patching
| of all software that is to be run on the system).
| logicprog wrote:
| > I sympathize with the situation that Zed developers are
| in. They are thinking of the user experience first and
| foremost, and when trying to distribute on Linux, faced
| with an overgrown, chaotic landscape that utterly fails to
| provide the basic needs of application developers, such as
| the ability to distribute a binary that has no dependencies
| on any one particular distribution and can open a window
| and interact with the graphics driver, or the ability to
| require permissions from the user to do certain things.
|
| But Linux _does_ provide a very simple and easy way to do
| this -- Flatpaks. They 're completely distro-independent,
| allow you to package up and distribute exactly the
| dependencies and environment your program needs to run with
| no distro maintainers fucking with it, allow you to request
| permission to talk to the graphics drivers and anything
| else you need, and you can build it and distribute it
| directly yourself without having to go through a million
| middlemen. It's pretty widely used and popular, and has
| made the silent majority of Linux users' lives much better,
| although there's a minority of grognards that complain
| endlessly about increased disk usage.
| doublepg23 wrote:
| The best part of Linux's single universal packaging
| system is there's three of them.
| logicprog wrote:
| Sure, but all of them are actually universal, so it
| doesn't matter which one you choose, unlike their being
| multiple regular package formats.
| doublepg23 wrote:
| It seems to me the most neutral one is AppImage. Flatpak
| being the favorite of "not-Ubuntu" people and Snap being
| only preferred by Ubuntu...but still having a huge user
| base due to their enormous market share.
| tjoff wrote:
| People don't prefer snap, they are forced into it.
| kelnos wrote:
| Maybe I'm just old-fashioned, but I don't like Flatpak
| (or Snap or AppImage). They still don't seem to have
| solved all the desktop integration issues. I do not like
| running apps that bundle their own dependencies, because
| I don't trust the app developers to be on top of security
| issues. I trust Debian maintainers (despite mistakes in
| the past) to keep my system's base libraries up to date
| and patched. Why would I trust some random developers of
| some random app to do the same?
| aidenn0 wrote:
| I have a shell script that will recursively copy and
| rewrite the rpaths of every shared-object that all elf
| files in a sub-directory reference to bundle it up. It
| obviously can't handle dlopen(), and ld-linux cannot be
| specified as a relative-path to the executable, but it
| works for many binaries.
|
| Of course that has the problem that vendoring always has;
| you have pinned every dependency, which is great for making
| the software work, but you miss out on security updates.
| charles_f wrote:
| Honestly, I still take that as an improvement over having to
| recompile it
| agilob wrote:
| >This is not an acceptable way to install anything on Linux.
|
| If you think this is not acceptable, check out what they did
| last week: https://news.ycombinator.com/item?id=40902826
| DEADMINCE wrote:
| > Well, my local directory is `~/local`. So that's not where I
| want it.
|
| You can just move it after. .local is different from local so
| there is no clash.
| janalsncm wrote:
| I disagree. I'm on Linux for my main installation and I know I
| can inspect the bash script if I want to.
|
| It's impossible to please everyone. Pipe to sh is simple,
| transparent, and easy to do. If reading through 200 lines of
| installation script is too much then reading through thousands
| of lines of Zed's code base will certainly be too much.
|
| They also list other ways of installing
| https://zed.dev/docs/linux
| deadbunny wrote:
| > Pipe to sh is simple, transparent
|
| Not so transparent[1]. Packages from a package repo are
| signed, usually with keys not stored on the same server so if
| someone nefarious breached a server they can easily replace a
| bash script, they can't re-sign and replace a package.
|
| Sure it's safe if you download the script then review it then
| install it, but hey, you reviewed it last time, it's probably
| unchanged, what's the harm of piping it directly to bash next
| time you need to get set
|
| https://web.archive.org/web/20240228190305/https://www.idont.
| ..
| the_duke wrote:
| > This is not an acceptable way to install anything on Linux
|
| You might want to tell the rest of the software world how
| unnacceptable it is, because a huge amount of software, and
| especially dev tooling, is installed in this exact way.
|
| It's especially hard for young or fast moving projects, most
| distro packaging just isn't very compatible with this velocity.
|
| I'm personally on NixOS , which usually makes it easy to always
| get the latest and greatest, but eg would I really want to add
| a third party apt repository for Zed, which introduces
| complications and also can make changes to my whole system,
| rather than just having zed install itself in a local user-
| owned directory? I don't want to end up with 15 different third
| party apt repositories... adding those actually provides a
| higher amount of trust than shell scripts that only run with
| user permissions.
|
| And there are similar considerations for most other distros.
| Arch is probably the only other one, next to nix, where it's
| quite easy to stay up to date.
|
| (zed is already an official Arch package, btw, and before that
| it already was in aur, and of course it is in nixpkgs already)
|
| It's not ideal, but whenever some pattern propagates across the
| ecosystem, there are probably valid reasons why.
| Palomides wrote:
| >I don't want to end up with 15 different third party apt
| repositories
|
| I would love to add 15 different third party apt
| repositories, I wish more projects used them, you're running
| whatever binary they give you anyway
|
| I guess this is just another example of how hard it is to
| please all linux users!
| correct-horse wrote:
| Almost 70% of the male population in my country smokes.
| Should I take up smoking because everybody else does it?
| logicprog wrote:
| My question is why they didn't just make a Flatpak. Then they
| and their users wouldn't need to go through any of this hassle
| and distro fragmentation at all. Even if they didn't want to
| publish it on Flathub, Flatpak supports single file packages
| people can directly install as well.
| insane_dreamer wrote:
| Because then you have a dozen other people who say "why
| didn't they just make a ___"
| logicprog wrote:
| But that's literally already true, and at least with
| Flatpak they'd only need to make a single package to
| support all distributions and system configurations,
| whereas what they're already doing is supporting 15
| different packaging systems and distributing a fragile
| install script that more people will have problems with. So
| this objection makes literally zero sense.
| figomore wrote:
| There is already some support to flatpak, but it's not
| distributed on flathub yet. You have to build by yourself
| https://github.com/zed-
| industries/zed/blob/main/docs/src/dev...
| logicprog wrote:
| Were they not aware of `flatpak build-bundle`? They could
| have just built it once and ran that command on the result
| and then put that on the archives of their repository and
| been done with it. It's not like a regular package build
| where there are different system conditions to keep an eye
| on. It would work no matter what.
| kelnos wrote:
| Flatpak is just yet another form of fragmentation though.
| usr942568903890 wrote:
| > My point is that if you just listed the download link to the
| tarball, it would actually be closer to your own goal of
| reducing installation friction. The shell script is so much
| more friction because I have to read bash code instead of just
| clicking a download link.
|
| It's there https://zed.dev/docs/linux#downloading-manually, it
| just doesn't show up as the default installation method.
| handsaway wrote:
| I tried zed for a few weeks because I'm generally sympathetic to
| the "use a native app" idea vs Electron. I generally liked it and
| its UX but:
|
| 1. VSCode is pretty damn fast to be honest. Very rarely is my
| slowdown in my work VSCode loading. Maybe I don't open very large
| files? Probably 5k lines of typescript at most.
|
| 2. Integration with the Typescript language server was just not
| as good as VSCode. I can't pin down exactly what was wrong but
| the autocompletions in particular felt much worse. I've never
| worked on a language server or editor so I don't know what's on
| zed/VSCode and what's on the TS language server.
|
| Eventually all the little inconveniences wore on me and I
| switched back to VSCode.
|
| I will probably try it again after a few more releases to see if
| it feels better.
| dijit wrote:
| Yeah, I agree about VSCode being sort of fast enough. Computers
| are getting faster and I'm on a M-series mac which makes web
| rendering much faster but still I feel like as far as electron
| apps go: VScode is basically the golden child.
|
| Slack & Teams on the other hand, ouch.
| yoyohello13 wrote:
| My only problem with VSCode is that it's owned by Microsoft.
| I'm willing to put up with some extra friction if it allows me
| to escape their ecosystem even a little bit.
|
| My general rule is if I can get at most of what I need from the
| open source version of something, I use it. Even if it's less
| user friendly.
| whalesalad wrote:
| but vscode _is_ open source:
| https://github.com/microsoft/vscode
|
| and there are third-party builds from the community that
| disable things like telemetry: https://vscodium.com/
| yoyohello13 wrote:
| Sorry, I should have been more specific and said FOSS.
| VSCode is still encumbered by the weight of a mega corp.
| It's like saying Chrome is open source. Sure it is, but it
| still exists to serve the corporation that owns it.
| TiredOfLife wrote:
| It's MIT licensed. So it's more FOSS than FOSS
| correct-horse wrote:
| It's free software in letter, but not in spirit. True
| free software doesn't lock out non-official builds for
| zero technical reasons.
| fragmede wrote:
| what about vscodium? for that reason, what was iceweasel?
| nicce wrote:
| There is some sort of vendor lock-in VSCode. It at least
| used to be extremely difficult to make GitHub Copilot to
| work with codium. There is something closed source in
| VSCode that makes the difference.
|
| It was so difficult to maintain, that I ended up
| switching to VSCode. So the "lock-in" worked.
| janice1999 wrote:
| vscodium and VSCode forks are legally prevented from
| using the normal VSCode extension site. They have their
| own: https://open-vsx.org/
|
| As far as I know Chrome forks are not blocked from using
| extensions from the Chrome Web Store.
| bigstrat2003 wrote:
| The software is free, the extension site is not. I agree
| that's a shitty practice by MS, but it doesn't somehow
| make VSCode not free software.
| o11c wrote:
| It isn't 1860 anymore, "the freedom to take freedom away"
| no longer counts.
| novagameco wrote:
| In what way is VSCode comparable to enslaving human
| beings?
| shrimp_emoji wrote:
| It uses indentured neural networks to write code for you.
| _You 're_ a neural network! You just have rights because
| you ain't digital (and way larger and possibly using
| quantum effects). Smh
| screcth wrote:
| The problem is that many parts of the ecosystem require
| that you use the official MS build.
|
| You can't connect to the Marketplace and some extensions
| outright can't be used with a custom build.
| vorticalbox wrote:
| You can however down the extension from the website and
| install it from the terminal.
|
| codium --install-extension {path to .vsix}
| KETHERCORTEX wrote:
| You are able to do so, but is it allowed by the website's
| terms of service? It may say that you are granted the
| license to extensions only with Microsoft builds of
| vscode.
|
| Microsoft isn't a stranger to distribution restrictions
| and software usage limitations. I remember uploading
| Visual C# Express 2010 (freely downloaded from
| Microsoft's website, without license keys) to a local
| file sharing website to ease the downloading for my local
| study group and got a letter from Microsoft's lawyer to
| take it down.
|
| After that our study group transitioned to Mono with
| Monodevelop.
| maccard wrote:
| If you're idealogically opposed to Microsoft's editor,
| that doesn't seem to be a problem to me.
| 0cf8612b2e1e wrote:
| You mean except for all of the good plugins. Or the ability
| to use a custom plugin store. Last I read, the open builds
| struggled with removing all of the MS telemetry and some
| may still be leaking.
| chx wrote:
| https://ghuntley.com/fracture/
| the_duke wrote:
| I think people just have very different tolerances for latency
| and slowness.
|
| I keep trying different editors (including VS Code), and I
| always end up going back to Neovim because everything else just
| feels sluggish, to the point where it annoys me so much I'm
| willing to put up with all the configuration burden of Neovim
| because of it.
|
| I tried out Zed and it actually feels fast enough for me to
| consider switching.
| whalesalad wrote:
| Sublime Text 3 is still one of my favorite editors. I use
| VSCode lately because of its excellent "Remote SSH"
| integration - but when it comes to latency sublime has it
| beat.
|
| Zed does not feel fast on my machine, which is a 13900K/128gb
| ram. It is running in xwayland though, so that could be part
| of the problem. It feels identical to vscode.
| correct-horse wrote:
| | It is running in xwayland though
|
| It definitely isn't on my system, and I did not touch the
| configs at all; are you sure about that?
| whalesalad wrote:
| Fairly positive due to blurry cursors, but I have no way
| to verify.
| ndiddy wrote:
| If you run xeyes and the eyes follow your cursor when
| it's above the application you want to test, it's running
| under xwayland. If they don't follow your cursor, the
| application is running under native Wayland.
| 369548684892826 wrote:
| finally a use for xeyes?
| ndiddy wrote:
| I don't use vanilla xeyes but I use the Window Maker
| dockapp version (https://bstern.org/wmeyes/) to make it
| easier to find my cursor on the screen.
| shrimp_emoji wrote:
| Ha. KDE 6 has something like if you jiggle the cursor a
| certain way, it temporarily grows larger.
|
| Better than Windows's function of "hide all my
| windows"...
| whalesalad wrote:
| I think every OS has this feature. Sometimes it is hidden
| in an accessibility menu and needs to be turned on.
| BrandoElFollito wrote:
| Pressing some key a few times in Windows highlights your
| cursor. I just can't remember what it was (Ctrl I think)
| jacekm wrote:
| Yup, Ctrl twice.
| lagniappe wrote:
| I always run xeyes in any net-enabled gui. iykyk.
| whalesalad wrote:
| Welp, looks like it is running native wayland yet the
| cursors are blurry. The only time I have ever experienced
| that is when an app is running under xwayland.
| executesorder66 wrote:
| If you run xlsclients it will list all applications
| running through xwayland.
|
| [0] https://archlinux.org/packages/extra/x86_64/xorg-
| xlsclients/
| whalesalad wrote:
| Oooh, thank you this is very convenient. Confirmed zed is
| not listed here.
| wheresmyshadow wrote:
| Sublime Text gang, raise up.
|
| I was always a fan of Sublime Text and I moved away from it
| once because VSC felt more "hassle-free". The extensions
| just worked, I didn't need to go through endless JSON files
| to configure things, I even uncluttered its interface but
| at the end of the day I returned to good old Sublime Text.
| Now with LSPs it requires way less tinkering with plugins.
| I only wish it had just a little bit more UI
| customizability for plugins to use (different panes etc).
| Maybe with Sublime Text 5 if that ever comes.
|
| Also about the speed: VSC is fast but in comparison...
| Sublime Text is just insta-fast.
| ElectronBadger wrote:
| I'm all for Sublime Text and Merge, my daily drivers for
| all kinds of writing..
| g8oz wrote:
| I feel the same way about Notepad++
| whalesalad wrote:
| notepad++ is a respectable editor but sublime defeats it
| at everything except price.
| ziml77 wrote:
| ST4 is my go-to for quickly viewing and editing
| individual files. It really is instant compared to VSC.
|
| I don't really run ST with any complex plugins though and
| leave cases where I want those for VSC. The ones I have
| installed right now are just extra syntax highlighting
| and Filter Lines (which I find very handy for
| progressively filtering down logs)
| whalesalad wrote:
| I still use ST for opening huge files. 9 times out of 10
| if a huge file cannot be opened in any other editor, I
| will open it in subl and it will be just fine.
| ilrwbwrkhv wrote:
| I have used Sublime Text my entire pro programming
| career. Before that I used emacs for a while.
|
| I love it and will not switch it for anything. It is
| maybe one of the best pieces of software ever made. A lot
| of the things such as multiple cursors, command palette
| etc where first popularized by ST.
|
| Today, I use it to write Rust, Go, web stuff and with LSP
| I get all the autocomplete I need. I also use Kitty as a
| separate terminal (never liked the terminal in editor
| thing).
|
| Things like Cmd-R and Cmd-Shift-R to show symbols in file
| and symbols in project work better, faster and more
| reliably than many LSP symbol completions.
| jwells89 wrote:
| Sublime's focused/minimalist UI is nice. VS Code sometimes
| feels like it tries to do too much.
|
| My ideal editor would probably be something like a
| variation on Sublime Text that's modeled more closely after
| TextMate while keeping the bits that make Sublime better
| (like the command palette).
| whalesalad wrote:
| Sublime is the better Textmate. What would you do to subl
| to make it more like mate? I used textmate for years and
| years before switching to ST and it was a drop-in
| replacement.
| jwells89 wrote:
| The two are pretty close, but between the two TextMate
| feels more like a golden era OS X desktop app thanks to
| several small differences and tiny Mac-isms, and I'd like
| Sublime to have that feel too.
| the_other wrote:
| I also feel TextMate had the nicer overall UX. When I
| first tried Sublime, TextMate had the better text
| rendering (IMO). Sublime has more features but still
| doesn't feel as slick somehow.
|
| I've recently returned to Sublime from VSC. I prefer
| VSC's UI for following links to definitons/references,
| but in most other ways I prefer Sublime's nimbleness.
| barnabee wrote:
| I use Helix and feel the same way. The pickers/fuzzy finder
| particularly have no equal for speed in any editor I've
| found. (Zed seems pretty fast but I didn't get on well enough
| with it to find out how it performs with more serious use.)
|
| fwiw I've also found the configuration overhead much lower
| with Helix than for pretty much any other editor I've
| seriously used.
| danielvaughn wrote:
| This makes me want to use Helix, because while I love the
| idea of a terminal editor, I'm not the kind of person to
| whittle away a day screwing around with my config files.
| zamalek wrote:
| Helix has been stalled for a few months, and there are
| issues that make it frustrating to use at times. For
| example, :Ex and friends have been relegated to the
| plugin system (the root cause of the stall, it hasn't
| been merged). I still prefer it to the config overhead of
| nvim (as well as the kakoune-style movements!), but the
| paper cuts have hit a threshold and I've started writing
| my own text editor (I'd probably use Zed, were it not for
| lack of kakoune movement support):
| https://youtu.be/Nzaba0bCMdo?si=00k0D6ZfOUF8OLME
| lytedev wrote:
| It's the main reason I switched from Neovim. I didn't
| want to maintain a thousand lines of Lua of stuff to have
| a good baseline editor. I only wanted to maintain my
| configuration idiosyncracies on top of an editor with
| good defaults. I think there are Neovim distributions
| that accomplish mostly the same thing, but then I fell in
| love with Helix's Kakoune-inspired differences.
|
| Give it a try! It's lovely.
| satvikpendem wrote:
| Zed is still quite a bit slower than Neovim in my experience.
| MrJohz wrote:
| Yeah, this was mostly my experience. The Zed editor was fast,
| but it just felt like it wasn't as good as other editors. For
| me, the version control integration was particularly poor - it
| shows some line information, but diffing, blame, committing,
| staging hunks, reviewing staged changes etc are all missing.
|
| There were a bunch of decisions that felt strange, although I
| can imagine getting used to them eventually. For example, ctrl-
| click (or jump to usages) on a definition that is used in
| multiple places opens up a new tab with a list of the results.
| In most other editors I've used, it's instead opened up a
| popover menu where I can quickly select which really I want to
| jump to. Opening those results in a new tab (and having that
| tab remain open after navigating to a result) feels like it
| clutters up my tabs with no benefit over a simple popover.
|
| Like you, I'll probably try again in a few releases' time, but
| right now the editor has so much friction that I'm not sure I
| actually save any time from the speed side of things.
| danielvaughn wrote:
| Yeah my experience has been that you aren't going to suffer
| performance problems with VSCode unless you have an incredibly
| large codebase. Past a certain point I'm sure Vim/NeoVim/Zed
| are probably much more performant, but the differences in
| smaller codebases is barely noticeable IME.
| sensanaty wrote:
| I don't use it as my main editor (I'm far too used to the
| Jetbrains editors to make the switch, they're just too smart),
| but it's the best one for CLI apps that use EDITOR, like git.
| It boots up basically instantly even when it hasn't been
| launched in a while and I can make my commit messages and
| immediately close stuff up at the speed of my thought.
| theoperagoer wrote:
| +1 for the Jetbrains gang.
| silisili wrote:
| A few weeks ago I had this giant json text blob to debug. I
| tried Gedit first, and it just fell over completely. Tried vim
| next, and it was for some reason extremely slow too, which
| surprised me.
|
| VSCode loaded it nearly immediately and didn't hang when moving
| around the file. I have my complaints about VSCode, but speed
| definitely isn't one of them.
| nicce wrote:
| Did you have some plugins in vim? It is very odd if it was
| slower in this scenario.
| silisili wrote:
| Not to my knowledge, outside of whatever Debian comes with.
| Keep in mind this was on a Chromebook - so it would have
| been running in a VM on a rather memory restricted system.
| That said, VSCode would have been running in the same
| parameters.
|
| Just found the file. 42MB on a single line. Takes 5 seconds
| to open in vim, and about 3 seconds for the right arrow to
| move the cursor one char over. Nothing like gedit, but
| slower than I expected.
| nicce wrote:
| Just curious, what of you do the same with bare neovim,
| for science?
| silisili wrote:
| Sure, just tried it. This is time to open, show the
| initial contents, then exit. nvim is much faster to
| cursor around, except when you hit the opening or closing
| of a json block it hangs a bit, so I'm guessing it has
| some kind of json plugin built in.
|
| $ time vim tt.json
|
| real 0m5.910s user 0m4.120s sys 0m0.343s
|
| $ time nvim tt.json
|
| real 0m2.894s user 0m1.372s sys 0m0.292s
| nicce wrote:
| I did some research and it seems that this particular
| slowness is due to single line file and if there is some
| syntax highlighting used with vim/neovim, it reads the
| line completely to do it correctly.
|
| VSCode reads only the visible content and does not load
| everything for that line. It tokenizes the first 20k
| chars of the line at maximum, defined by the
| "editor.maxTokenizationLineLength" setting.
| iso8859-1 wrote:
| Might want to try
| https://github.com/LunarVim/bigfile.nvim
| tschumacher wrote:
| I'm pretty sure this is syntax highlighting. It's a known
| issue to be slow for large files in Vim because it is
| synchronous. Try starting Vim with syntax highlighting
| off: vim -c 'syn off'
| silisili wrote:
| Yep that helps a ton, thanks. Now it behaves more like
| nvim, and cursors around much faster -
|
| $ time vim -c 'syn off' tt.json
|
| real 0m3.277s user 0m1.690s sys 0m0.349s
| tschumacher wrote:
| Interesting. I expected it to be near instant without
| syntax highlighting but it's still slow.
| davorak wrote:
| It is odd that it is slow. On my 2019 macbook pro
|
| edit
|
| new more realistic example: time vim -c 'syn off' <64
| MB>.txt vim -c 'syn off' <64 MB>.txt 0.41s user 0.20s
| system 32% cpu 1.848 total
|
| ---
|
| Here is my first, pre edit, example which is invalid. The
| file was a zip and my install of vim was not opening as
| text or binary
|
| % time vim -c 'syn off' <48 GB file> vim -c 'syn off' <48
| GB file> 0.03s user 0.03s system 2% cpu 2.380 total
| j1elo wrote:
| This makes sense. I recently learned that VSCode is
| clever enough to automatically disable some features
| (which includes syntax highlighting among I guess other
| things) when it detects that the file is too big
| according to some heuristics (like probably, length of
| the longest line, or maybe just total size of the file).
|
| So IMO I think vim is being "too dumb" here and should be
| able to adapt like VSCode does. But, meanwhile, if you
| want to test under equal conditions, you can disable
| VSCode's optimization by disabling this setting:
|
| _Editor: Large File Optimizations_
|
| Or directly in _settings.json_ :
| "editor.largeFileOptimizations": false
| maccard wrote:
| > But, meanwhile, if you want to test under equal
| conditions, you can disable VSCode's optimization by
| disabling this setting:
|
| Disabling the advantages of one application vs another is
| just kneecapping the superior editor IMO.
| crabbone wrote:
| > on a single line
|
| This makes a world of a difference when your editor is
| configured to wrap lines, or clip or w/e.
|
| You probably happened to have VSCode configured to do
| something that mitigates the problems of having an
| extremely long single line, while Vim was not configured
| to do that.
|
| In case you don't want to investigate the problem, but
| want to make a more "fair" comparison: use a language
| that you are comfortable with to format the file with
| linebreaks and indentation and then load it in different
| editors.
| maccard wrote:
| > You probably happened to have VSCode configured to do
| something that mitigates the problems of having an
| extremely long single line, while Vim was not configured
| to do that.
|
| Defaults matter.
| nicce wrote:
| For mainstream users. Particularly in the case of vim,
| the end-user is more likely the figure out that this is a
| configuration problem and can be adjusted.
| angra_mainyu wrote:
| For this kind of stuff Sublime has always been extremely
| good.
|
| But I still struggle to find a reason to not use neovim, it's
| replaced all my editors.
| satvikpendem wrote:
| Weird, I had the exact opposite experience. I had a large
| Markdown file I was editing and VSCode would simply hang or
| crash when opening it. Neovim on the other hand actually was
| able to navigate and edit just fine.
| ThinkBeat wrote:
| I believe VsCode has told me several times that the file i
| want to open is too big.
| j1elo wrote:
| I'm on the same camp, but in the end it turns out we were not
| putting it to the actual, real, hard-world test.
|
| VSCode is very fast for me, _when I open it in the morning and
| just starting my day_.
|
| But once I've opened the main project _and_ 7 support library
| 's projects, _and_ I 'm in a video-call on Chrome sharing my
| screen (which is something that eats CPU for breakfast), _and_
| I 'm live-debugging a difficult to reproduce scenario while
| changing code on the fly, _then_ the test conditions are really
| set up where differences between slow /heavy and
| fast/lightweight software can be noticed.
|
| Things like slowness in syntax highlighting, or jankyness when
| opening different files. Not to mention what happened when I
| wanted to show the step-by-step debugging of the software to my
| colleagues.
|
| In summary: our modern computer's sheer power are camouflaging
| poor software performance. The difference between using native
| and Electron apps, is a huge reduction in the upper limit of
| how many things you can do at the same time in your machine, or
| having a lower ceiling on how many heavy-load work tasks your
| system can be doing before it breaks.
| hamandcheese wrote:
| > I don't know what's on zed/VSCode and what's on the TS
| language server.
|
| Microsoft's latest embrace-extend-extinguish strategy is
| keeping just enough special sauce in (frequently closed-source)
| vscode extensions and out of the language servers. They do the
| same thing with Pyright/Pylance.
| IshKebab wrote:
| And the remote SSH and C++ extensions, though that actually
| has a good alternative in the Clangd extension.
|
| I'm kind of ok with it tbh. As a monetisation strategy it's
| not the worst, and I have no expectation that they just do
| all this for free.
| anonzzzies wrote:
| In the morning vscode is ok, come noon, it's the primary thing
| eating my battery and it's getting slower and slower; day end
| it's unusable. Sure, restart it, I know, but it's fairly
| terrible though.
| varispeed wrote:
| Okay, call me weird, but why our standards have fallen so low?
|
| VSCode may appear fast, but still has massive latency. The Zed
| website claims 97ms.
|
| I can feel it is laggy.
|
| Why can't we have response time under 1ms? Even 5ms would be a
| massive improvement.
|
| For me latency is a massive productivity killer as it feels
| like walking in a swamp and it always puts me off.
| whalesalad wrote:
| I agree with you -- but aiming for 1ms performance is pretty
| hard. That is 1/1000th of a second. Your keyboard probably
| has higher latency than that. Physics cannot be defeated in
| this regard.
| scblock wrote:
| A typical 60 Hz screen refresh is 16.7 ms
| jay_kyburz wrote:
| If you haven't tried a 144hz or even a 240hz gaming PC, you
| should. You can really feel the difference dragging things
| around the screen.
|
| (I'm not sure I would notice typing, but for dragging
| windows around I could never go back to 60fps.)
| bigstrat2003 wrote:
| Honestly I don't think that the problem with VSCode is speed,
| even. It's bloat. It uses gobs of RAM just to open up a few
| text files. I compared it to Sublime Text a while back and it
| was something like 500 MB (for Sublime) to 1-1.5 GB (VSCode).
| That's not acceptable in my view.
| llagerlof wrote:
| How to install/activate extensions? I saw that exists a directory
| called "extensions" in the repository.
| simlevesque wrote:
| There's an extension ui in the app.
|
| Ctrl + Shift + X or use the top right dropdown menu.
| unshavedyak wrote:
| I'll have to figure out how to get it on NixOS. Always the
| challenge with Nix lol.
| Zambyte wrote:
| https://search.nixos.org/packages?channel=24.05&show=zed-edi...
| unshavedyak wrote:
| Wait, added 2 months ago? This isn't new then, i take it?
| Interesting. Linux release announcement now i wonder?
|
| I expected this just was released today, so it definitely
| wouldn't be in Nixpkgs yet lol
| delichon wrote:
| For the last few months it has been available on Linux to
| build from source.
| riiii wrote:
| I don't know if it's just me but vscode feels like it isn't as
| fast as it used to be. The terminal also keeps getting messed up
| on Linux.
|
| Will definitely try one this out!
|
| Although the amount of plugins and community knowledge of vscode
| is immense.
| dabber21 wrote:
| neat! just installed it in podman, so far so good
| rareitem wrote:
| FYI, to launch Zed, run `'~/.local/bin/zed'`
| whalesalad wrote:
| If .local/bin is in your PATH you would be able to fire it up
| with just `zed`
| hi_dang_ wrote:
| Zed Shaw started a company called Zed Industries?
| ebrescia wrote:
| LOL no. The Zed founders are the guys who built Atom and
| Electron (and Treesitter): Nathan Sobo, Max Brunsfeld and
| Antonio Scandurra.
| DarkCrusader2 wrote:
| Does anyone know what is their monetization plan, or if they even
| have one? Editor with even this much polish takes a lot of time
| and effort. How is it being funded? Can we expect useful features
| to progressively get locked behind subscription as it grows in
| popularity (a la Gitlab)?
|
| Edit: Nevermind, found it - https://zed.dev/faq#how-will-you-
| make-money. Interesting charter. We envision
| Zed as a free-to-use editor, supplemented by subscription-based,
| optional network features, such as: Channels and
| calls Chat Channel notes We
| plan to allow offer our collaboration features to open source
| teams, free of charge.
|
| Edit 2: They have apparently also already raised money via
| private equity. I am quiet soured on "free" products which will
| almost always be enshittified as the pressure to turn profit
| grows.
| mikojan wrote:
| > We envision Zed as a free-to-use editor, supplemented by
| subscription-based, optional network features, such as:
|
| >
|
| > Channels and calls
|
| > Chat
|
| > Channel notes
|
| >
|
| > We plan to allow offer our collaboration features to open
| source teams, free of charge.
|
| https://zed.dev/faq
| jarule wrote:
| Build a big enough userbase for big tech to want to buy it.
| It's the only game left outside ads. Worked for WhatsApp,
| Instagram, Github, Kaggle, etc.
| kelnos wrote:
| Yeah, I just can't get excited by anything this foundational
| that has monetization plans. While neovim is a pain to
| configure and will probably never be a polished "product", it's
| completely free to use, with no weird monetization features
| that might start out in good faith, but slowly creep into must-
| have parts of the software.
|
| I'm perfectly willing to pay for some types of software, but
| for something as fundamental as my text editor, I want a model
| that doesn't depend on a company that needs money. That may
| sound a bit backward, as it otherwise depends on the goodwill
| of volunteer contributors, but that's the model I prefer and
| actually believe in.
| w-m wrote:
| Is (Python) debugging on the roadmap somewhere for Zed, or will
| this remain out of scope?
|
| I have a fast editor in Sublime already, but I'd consider jumping
| ship from VS Code to Zed if I can set some breakpoints and look
| at local variables and whatnot (very basic IDE stuff).
| llagerlof wrote:
| Just a suggestion. One of the best features of pure text editors
| (and incredible, not all of them implement it) is autosave
| keeping the "unsaved" state of the file.
|
| For example, if you make some changes in a file (new or not),
| don't save the changes, close and open the editor, the state of
| the opened files are kept like I never had closed the editor. The
| unsaved files are still unsaved. New edited files are still
| there, unsaved, ready to user manually save them.
|
| Notepad++ works that way, and it is an amazing feature.
| misternugget wrote:
| Working on it!
| sa-code wrote:
| Sublime works this way and I do appreciate it
| shitlord wrote:
| I have a tab in Sublime Text for my todo list, which I
| created several years ago and never bothered to save. It's a
| great feature for indecisive procrastinators.
| TremendousJudge wrote:
| Atom worked that way as well
| rbanffy wrote:
| I wouldn't mind auto saving and allowing me to undo changes
| from the previous session.
| stavros wrote:
| Is this if you close the entire editor? If you just close the
| file, do the changes remain next time you open it?
| 369548684892826 wrote:
| Just if you close the entire editor. Editors with this
| feature, if you close the file it will ask if you want to
| save changes, click no and the changes are lost.
| stavros wrote:
| That's very good UX, I really like that. I wonder why it's
| not more widespread.
| mintplant wrote:
| Similarly, I have unlimited persistent per-file undo turned on
| in Neovim. I can open any file I've edited previously and walk
| through the full history of how it got there. With Undotree
| [0], I can even navigate branching paths in development. I
| don't know how people live without this.
|
| [0] https://github.com/mbbill/undotree
| rustyminnow wrote:
| What are your undo settings? I set undofile and undodir, but
| not sure if it's unlimited.
|
| One issue I have is if nvim is closed and the file is touched
| by some outside process (say git pull) it clobbers the
| history. Do you know if there's a fix to that?
| zelphirkalt wrote:
| I think Emacs does this too, if you configure it, or even by
| default, using its backup files, that go by #some_name# or
| similar.
| jhoechtl wrote:
| While I love Emacs it's not like this. Scratch buffer? C-c
| C-x and all is gone without any warning.
| emporas wrote:
| Emacs definitely does this. I have saved many files from
| power outages. M-x recover-file, but the user has to recover
| the file right away when he opens it again or else a new
| auto-save will overwrite the old one. I think that's the
| case.
| TiredOfLife wrote:
| Jetbrains ides even have something like a shadow git.
| ziml77 wrote:
| Even Windows Notepad supports hot-exit now.
| natemcintosh wrote:
| Anyone else get ~60-70% CPU usage when moving the mouse around?
| And no GPU usage.
| simlevesque wrote:
| Yeah I get something like that too
| mikaylamaki wrote:
| We have a few words on this in our troubleshooting guide:
|
| https://zed.dev/docs/linux#troubleshooting
|
| Let us know if that doesn't fix it!
| natemcintosh wrote:
| Tried the advice, but wasn't able to change behavior. Added a
| [comment](https://github.com/zed-
| industries/zed/issues/13552#issuecomm...) to an existing
| issue
| jchw wrote:
| Man, I'm conflicted. I mean, Zed works pretty damn well. So far
| my biggest annoyance with Zed though is that it's constantly
| trying to download language servers and other tools and run them.
| And sure, that's handy, but 1. I don't really want it, I'd much
| rather only use distribution-provided tools. 2. It doesn't work
| _at all_ on NixOS, so it 's just wasting its time and our
| bandwidth constantly downloading and trying to update binaries
| that will never run.
|
| The thing is, I would just disable it, but you can't, as far as I
| can tell. There's this somewhat angry issue about it here:
|
| https://github.com/zed-industries/zed/issues/12589
|
| They might have a point but beyond whether or not they have a
| point regarding the fact that it automatically fetches binaries
| from the Internet, not having an option to disable it is just
| cruel.
|
| I still like Zed a lot and I also have a big appreciation for the
| design of GPUI, which I think is a very well-designed UI library
| that puts focus on the important things. So, I hope it goes well.
| mikaylamaki wrote:
| After we finished prepping this linux launch, we've started
| work on making this situation better. Follow along here:
| https://github.com/zed-industries/zed/pull/14034
| jchw wrote:
| Oh, thank goodness. Yeah, that's going to be a major quality
| of life improvement for me. I had a feeling it'd eventually
| make its way into Zed eventually, but when I initially read
| the issue I was under the impression that there was no plans
| to add options around this, which I found confusing.
| brunoqc wrote:
| > It doesn't work at all on NixOS
|
| Doesn't it work with: zed-fhs =
| pkgs.buildFHSUserEnv { name = "zed"; targetPkgs
| = pkgs: with pkgs; [ zed-editor
| ]; runScript = "zed"; };
|
| Still not ideal though.
| jchw wrote:
| Oh sure, you can create an FHS and have it work, though
| personally I wouldn't. After all, Zed itself actually _does_
| work without an FHS, it 's just that any binaries it tries to
| download will not. Which is actually not a huge problem in my
| case.
| 1attice wrote:
| Weird, I just added `zed-editor` to my environment and it's
| fine.
|
| NixOS is listed here: https://zed.dev/docs/linux
|
| For me, works as expected.
| winternewt wrote:
| I just tried it on NixOS 24.05. It starts, but nothing
| happens when I click "Open a project" or Ctrl+O. It's as if
| it lacks the ability to show a file selection dialog.
| ajitid wrote:
| Could this be your issue?
| https://zed.dev/docs/linux#opening-files-does-not-work
| jchw wrote:
| This is almost definitely the problem they're facing
| although I think that description is a little bit odd.
| It's missing the operative word: "portals". It's the XDG
| desktop portals service that is involved here. What you
| need to ensure is that you have a desktop portal provider
| set up that provides
| org.freedesktop.impl.portal.FileChooser. What's kind of
| neat about the way xdg-desktop-portals is architected,
| you can pick and choose different implementations for
| different services. This is especially useful outside of
| desktop environments where you might need to use e.g. the
| wlr provider for screenshots and screen capture, but you
| still want e.g. KDE file dialogs.
|
| It's unfortunate that the documentation for XDG desktop
| portals (and generally, setting up a complete desktop
| setup when using compositors like labwc or Sway) is
| relatively poorly documented. I have my feelings about
| the pervasiveness of DBus services everywhere but overall
| I like desktop portals.
| winternewt wrote:
| Apparently yes. I tried installing xdg-desktop-portal-gtk
| at first, but that didn't work. xdg-desktop-portal-kde
| did.
|
| But now I get issues that are likely due to problems with
| downloading language server binaries and running them, as
| the parent comment indicated. When I open a Rust project
| it says "Language server rust-analyzer-2024-07-08 (id 1)
| status update: Failed to load workspaces."
|
| Also, it dumps core every time I quit. :)
| dindresto wrote:
| NixOS 24.05 contains an older version of zed, as feature
| updates are generally not backported to stable NixOS
| releases. Try running the package from nixos-unstable
| instead.
| winternewt wrote:
| Well that got rid of the core dump each time I quit, and
| it fixed the language server issues. So together with the
| portals configuration it seems to be working as well as
| it can.
| 1attice wrote:
| [OP] yeah I'm using nixos-unstable too. I should have
| mentioned that
| benfrain wrote:
| I really wish they would bundle up the basic Language Servers
| with the download (HTML, CSS, TypeScript) so it at least has
| parity with VSCode in this regard
| foresto wrote:
| Looks like they're developing their own Apache-licensed GUI
| framework for this, called GPUI. I think of text handling as one
| of the trickier parts of building such a framework, so one
| specifically made to support a text editor would seem to be a
| pretty good foundation for a general purpose GUI toolkit. I
| wonder if they (or someone else) will pursue it as an alternative
| to Qt.
| jchw wrote:
| GPUI is very cool, they have blogged about it before.
|
| https://zed.dev/blog/videogame
|
| Many UI libraries being built today want to be very forward-
| focused, so they focus on being as general as possible. This
| does make some sense, especially considering that, for better
| or worse, using a web browser engine as a UI has become
| increasingly popular of a decision. However, in the end this
| leads to almost all new "greenfield" UI projects trying to
| develop scalable vector UI rendering engines that need advanced
| and highly optimized vector rendering libraries like Skia and
| Pathfinder. Having everything in vector all the way through is
| elegant, but it's complicated.
|
| The insight with GPUI is that it's not really necessary to be
| that general, the vast majority of UIs are made up of a
| relatively small number of different primitives that you can
| build on to basically do anything. So instead the vast majority
| of what's going on in GPUI is layers of roundrects. Text
| rendering is the classic approach of rendering into glyph
| atlases. I think this is a vastly more sustainable model for a
| UI library.
|
| I don't know if GPUI is ready to be used on its own, but it
| does have a spiffy if brief website.
|
| https://www.gpui.rs/
|
| Given that Zed actually has good "UI-feel", it tells me they
| are focused on the right things. A lot of new greenfield UI
| frameworks are spending a ton of time on trying to build
| extremely generic vector graphics systems but the actual
| widgets feel bad and are missing all kinds of tweaks and
| nuance. Here's a good litmus test for text editors: what
| happens if you double click and drag? In most good UI
| frameworks, this should result in word selection and then
| expanding that selection left or right. In a lot of smaller
| greenfield UI libraries, something vastly less useful will
| happen :(
| jenadine wrote:
| Their toolkit is developed in their monorepo and is not on
| crates.io nor versionned, so they can do breaking changes any
| time. Seems risky to use in 3rd party projects.
| foresto wrote:
| Today, sure. That doesn't preclude it from maturing into
| something more generally useful, nor from eventually getting
| its own repo. I've built more than a few libraries that
| started out as functions and data structures within
| application code.
| keb_ wrote:
| Definitely looks pretty rough so far (running Debian GNOME) --
| font rendering looks wonky, and resizing the window is slow and
| unresponsive. But I'm very optimistic for what's to come!
| mikaylamaki wrote:
| Check out our troubleshooting page, you might not be utilizing
| the GPU!
|
| https://zed.dev/docs/linux#troubleshooting
|
| If that doesn't work for you, please file an issue, and let us
| know whether you're using Wayland or X11 :)
| WhereIsTheTruth wrote:
| I gave it a fair try
|
| Cons:
|
| - spawning nodejs whenever you edit JSON files seems overkill,
| i'd prefer they use something native and more lightweight, or a
| way to completely disable it
|
| - text still looks a bit blurry on low DPI screens
|
| - doesn't support LSP properly, completion items are missing some
| data
|
| - Rust for plugins.. this is painful, compare it to Sublime
| Text's python API, it's night and day..
|
| Pros:
|
| - Fast and responsive
|
| - UI is simple yet effective
|
| - drag&drop layouting, something i wish Sublime Text had..
|
| - built-in terminal
|
| - built-in Debugger (not yet ready)
|
| Few more months of developments, and i'll certainly switch from
| Sublime Text, i'll be a little sad because i wrote plenty of
| plugins for it
|
| I however worry about their business model, i have 0 interests in
| their AI/collaboration stuff, i'll probably maintain a fork to
| get rid of all that crap, they should setup something as a back
| up plan, a small paid license, just for support, i'll be happy to
| buy one
| nilslice wrote:
| > - Rust for plugins.. this is painful, compare it to Sublime
| Text's python API, it's night and day..
|
| Yes, this is unfortunate as they've unsuitably chosen the
| barely usable & unstable "component model" for their Wasm
| plugin layer. It's really only half-decent in Rust (to write
| the code & compile to CM non-standard version of wasm binary.
| it's also only truthfully usable to call components _from_ rust
| too.)
|
| I think they are banking on the eventual support for cross-
| language async - which likely could never come, or could take
| longer than the company stays solvent!
| kelnos wrote:
| > _I however worry about their business model_
|
| For me, this is a showstopper. I don't want to use a text
| editor that even _has_ a business model.
| WhereIsTheTruth wrote:
| It doesn't really matter, it's open source with a growing
| community already, so it can only keep going if the company
| dies
| sauercrowd wrote:
| Cool to see a new editor in the arena with a lot of resources
| behind it, but I'm trying to find the selling point besides "it's
| really quick".
|
| Great feature but there's a lot more stuff I need for a truly
| outstanding editor, what are the novel pieces?
|
| The bar is ridiculously for editors (vim & emacs configurability,
| vscode just works, jetbrains can do it all) - what will/does it
| bring to the table to compete?
| taosx wrote:
| I really enjoy the AI assistant it has. One of the simplest
| easiest ways for me to interact with chatgpt/claude apis. Write
| prompt, copy, paste code.
| mikaylamaki wrote:
| As a Zed developer, our killer feature is the parallel
| programming that our software enables. It's like pairing
| without the terrible parts.
| rwdf wrote:
| Anyone got this working in WSL? Using WSLg perhaps?
| shanselman wrote:
| Trying but not succeeding
| Arch-TK wrote:
| I really don't get why this is the modern editor style of choice.
|
| 20% (35 chars) of screen space permanently wasted on a always on
| file browser (meanwhile the animation showcases fuzzy finding)
|
| 4% (7 chars) of screen space permanently wasted by line numbers
| (why are the numbers cut off on the right?)
|
| 2.7% (5 chars) of screen space taken up by a gutter
|
| So 27% of screen space effectively dead 99% of the time.
|
| Why do people do this to themselves?
|
| I can't quite figure out how to get the gutter to truly only
| appear when needed (I can't remember why) but in my vim
| configuration 2 chars of space are taken up by the gutter and the
| rest is for the actual code. The current line number is in the
| bottom right, and if I need to go to a specific line number I
| have `G` for that. If I need a file explorer, there's the default
| Netrw one, there's NERD Tree, there's a terminal (I actually
| rarely need this anyway, but I can understand not everyone can
| cope, but I can't comprehend why you would need it on 100% of the
| time).
|
| Why does the "modern text editor" waste so much screen space?
|
| I have a 1200p laptop monitor which gives me 174 chars of
| horizontal space at a comfortable font size. If I split that in
| half I get two terminal windows worth of 87 characters each. If I
| keep my code under 85 characters per line, not only is it easier
| to read, I can keep a man page or another piece of code on the
| other half of my screen.
| brunoqc wrote:
| You can close the left dock (ctrl+b for me). The gutter is
| still huge, though.
| Quot wrote:
| > 20% (35 chars) of screen space permanently wasted on a always
| on file browser
|
| That is toggleable. Cmd+B on Mac. I usually keep it closed, but
| it's just a shortcut away when I need it.
|
| > 4% (7 chars) of screen space permanently wasted by line
| numbers
|
| You can disable that in the settings with:
|
| "gutter": { "line_numbers": false }
|
| > 2.7% (5 chars) of screen space taken up by a gutter
|
| You can also disable the other items in the gutter to free up
| all of that space.
|
| > So 27% of screen space effectively dead 99% of the time.
|
| You can also press shift+esc at any time to toggle a fullscreen
| pane of whatever you are working on when you need more space
| without affecting your editor's state. I don't know the name of
| that action, I actually found that accidentally.
|
| Edit: I forgot to mention, you can actually disable the tab bar
| now too if you want even more space. You would just need to
| rely on the tab switcher feature or file search to move around.
| Arch-TK wrote:
| I would damn hope you can configure/disable this. But why is
| it the default?
|
| And if the answer is "discoverability" then where is the
| default-on fuzzy find, default-on command palette, default-on
| context menu, etc?
|
| My point was not to claim Zed was bad because I had the
| ignorant misapprehension that it was incapable of being
| cleaner, my point was to ask why people desire such a
| cluttered workspace by default? Most people I see using these
| editors _don't_ disable all this clutter.
| aidenn0 wrote:
| I haven't tried Zed and am unlikely to, but I get 238
| characters of fantasque sans mono 11pt on my 1200p screen, so I
| could give up those spaces and still have two vertical panes
| (assuming Zed supports vertical panes and the file-browser
| isn't duplicated).
| Arch-TK wrote:
| I think lots of people are comfortable with smaller fonts,
| but I find myself genuinely straining my eyes too much and
| getting headaches if I go smaller than this, and I already
| wear glasses (although I should probably update my
| prescription).
| aidenn0 wrote:
| Oh, there's no "right answer" to font size, but the fact
| that my size would work on a 1200p screen (and _many_ of my
| coworkers have significantly larger screens and younger
| eyes than I) could go towards explaining why the sidebar is
| on by default and the gutter is so huge.
| dbalatero wrote:
| I agree with you and probably have a similar setup to you.
|
| There's a % of people that like to think deeper about their
| tools, but I think most folks don't care enough or might be
| struggling with higher priority things at work. Plus, you don't
| know what you're missing.
|
| For me, good setup is like compound interest that just keeps
| paying off over time.
| marcodiego wrote:
| The last collaborative editor that I could use locally
| successfully was gobby. Currently its development is very slow or
| seems abandoned. I've been waiting for Zed because it was
| introduced as something that was "multiplayer-first" from the
| beginning. Reading the docs now, it looks like I need a feature
| called "channels" that I couldn't confirm can be used fully
| locally. Is there a way to use Zed as a collaborative editor
| fully locally?
| croemer wrote:
| To save you time: If you're on macOS, you can install with
| brew install --cask zed
|
| The docs don't make it very clear that the cask is available via
| homebrew.
| TiredOfLife wrote:
| On Steam Deck it just exits, or rather it and the old node.js it
| bundles stays in memory. But no UI.
| Brechreiz wrote:
| Is this better than VS Code?
| vondur wrote:
| Surprised they didn't make it a FlatPak. Probably would anger
| some, but it would work with most Linux distributions.
| zoogeny wrote:
| I'm a sucker for text editors. I've used so many at this point.
| Notepad++ from way back. Anyone remember Komodo, the Perl focused
| text editor from ActiveState? BBEdit. TextMate. Sublime text.
| Atom. Visual Studio Code. All kinds of IDEs from Eclipse to the
| IntelliJ family and the full fledged Visual Studio. I've used
| many flavors of vim and learned emacs multiple times. I doubt
| I've named half of the editors I've used.
|
| I'm at the point where I just can't motivate myself to try yet
| another. In my experience, they all have their strengths and
| weaknesses. My rule of thumb now: use whatever the majority of
| people on my team use. For non-team related work I find the
| community around Visual Studio Code to be good enough that it
| does what I need most of the time. I use bog-standard vim when I
| ssh into boxes.
| 1oooqooq wrote:
| komodo the editor (i recall it as a semi-commercial alternative
| to eclipse, much like intellij, but based on mozilla UX code?)
| was funny, because exactly the time it got traction and people
| started to talk about it, the tech news were inundated with
| Comodo the TLS operator caught doing shaddy stuff (and if i
| recall, blaming some hackers)
|
| didn't hear much about komodo till now
| zoogeny wrote:
| Komodo had some promise, in kind of the same way the original
| hype about Perl 6 had promise. For its time, it had features
| that were not widely available in other editors. However, I
| found it to be slow and buggy. And that was compared to
| Eclipse which was notoriously clunky. (Note: a quick look at
| the modern Komodo Editor, which appears to still be actively
| developed, looks much closer to a Visual Studio Code clone
| and is nothing like I recall the original)
|
| I recall it was pitched as a slightly lighter alternative to
| eclipse and intellij but initially geared towards Perl
| development (with plugin support for all languages). However,
| that kind of middle-ground wasn't popular at the time and
| devs mostly split into the full featured IDE camp or the
| stripped down editor camp.
|
| Editor hype cycles come and go. That's part of the reason I
| am so jaded when I see a new cycle start for a new editor.
| llmblockchain wrote:
| Seems like a good VSCode alternative, but I'll stick with my
| editor of choice. I imagine it will be 1~2 years before Zed is
| bought by Microsoft and either squashed like Atom or replaces
| VSCode.
| 1oooqooq wrote:
| I don't really like their editor, but their fonts (based on
| iosevka) is my 2nd favorite (after Mensch).
|
| And their opensource development mode is the best one I've seen
| so far! So many nice choices.
| sphars wrote:
| Unfortunately, they've switched out their Zed fonts for IBM
| Plex: https://github.com/zed-industries/zed/pull/13596
| 1oooqooq wrote:
| lol. Of course they would change the one thing i thought was
| great. and they bumped ligatures to eleven on top of the
| change. sigh.
|
| future generations will look at our silly use of ligatures
| like we look at comic sans.
| dario_od wrote:
| Sadly I can't run it in WSL.
|
| thread 'main' panicked at
| crates/gpui/src/platform/linux/wayland/client.rs:143:51:
|
| called `Result::unwrap()` on an `Err` value: UnsupportedVersion
|
| note: run with `RUST_BACKTRACE=1` environment variable to display
| a backtrace
| shanselman wrote:
| same. :(
| daghamm wrote:
| Man, what kinda of QA do they have that they miss something
| like this? WSL can be considered the second largest Linux
| "distro".
|
| Of course, zed has always felt like an osx first project with
| linux/windows being second class citizen.
| bozey07 wrote:
| That seems a bit rude. You get the QA you paid for - zero.
|
| And nevertheless, whenever Windows software doesn't work in
| Wine, you shouldn't think "Wow, how did you fuck that up?".
| They never promised it'd work in WSL.
| daghamm wrote:
| I disagree.
|
| They are on front page of HN with "zed on Linux is here".
| We got to have _some_ standards, don 't you think?
| umanwizard wrote:
| WSL is a pretty niche version of "Linux". I would guess
| that close to 0% of what makes it to the front page of HN
| had a QA team that explicitly tested it on WSL.
| daghamm wrote:
| Please stop making up facts.
|
| 1 of 7 Rust developers use WSL: https://blog.rust-
| lang.org/2024/02/19/2023-Rust-Annual-Surve...
| zapnuk wrote:
| niche?
|
| WSL (all distros combined) is the 2nd most popular Linux
| environment. Only behind Ubuntu.
|
| https://survey.stackoverflow.co/2023/#section-most-
| popular-t...
| Carrok wrote:
| One could easily reply an equally snarky answer of "Use a
| real OS, not MSFT spyware. We got to have some standards,
| don't you think?"
| kelnos wrote:
| Maybe they didn't do any on Windows, because this is for
| Linux, not Windows. WSL is still not Linux. They do appear to
| have Windows build instructions, though[0]?
|
| [0] https://zed.dev/docs/development/windows
| crabbone wrote:
| I've not heard of QA in open-source projects... unless it's
| something peddled by a big corp (eg. Chrome, Go, VSCode etc.)
|
| You are lucky if there's some automated unit testing, but
| that's as far as these things go. Programmers don't like,
| don't know and don't want to know how to QA. Also, they
| generally look at QA with contempt... so, unless forced to,
| they won't do it.
| oblio wrote:
| > Of course, zed has always felt like an osx first project
| with linux/windows being second class citizen.
|
| Unless I'm missing something, it doesn't even run on
| Windows...
|
| https://zed.dev/docs/#download-zed
| abhinavk wrote:
| I have been using it on Windows (native) after building it from
| source. Just for quick editing. It hasn't crashed on me yet.
| dcchambers wrote:
| However silly it is, I've always hated the aesthetics of VS Code.
| I know it's themeable but despite that the overall look and feel
| just isn't right on MacOS or Linux. That side bar drives me
| crazy.
|
| I find that out-of-the-box Zed is much prettier and feels more
| native than VS Code. But for a tool that we spend hours using
| each day, how it looks and makes you feel really matters.
|
| I am enjoying experimenting with Zed. I have kept my extensions
| and configuration to a minimum which is a refreshing change
| compared to the cluster that my VSCode installation has become.
| omneity wrote:
| The first thing I do on any VS Code fresh install is to switch
| the sidebar to the right. Pure heresy for many people, I know.
| But I want my eyes to naturally land on code, not on a file
| tree.
| ku1ik wrote:
| Same here! Also, when it's on the right toggling it doesn't
| move the code panes left and right.
| mikojan wrote:
| The activity bar is the worst. Luckily you can move it and make
| it smaller. "workbench.activityBar.location":
| "top",
|
| Just in case might as well try these..
| "editor.fontFamily": "'Monaspace Neon', monospace",
| "editor.fontLigatures": "'calt'", "workbench.iconTheme":
| "vs-minimal", "workbench.colorTheme": "GitHub Light",
| "window.commandCenter": false,
| "window.customTitleBarVisibility": "auto",
| "window.titleBarStyle": "custom",
| 3836293648 wrote:
| Tried it with mangohud and scrolled up and down a 100-line c++
| file with no lsp enabled. 30fps. Absolutely not ready yet. Not
| sure I'm willing to leave Emacs, but gpui looks cool and I hope
| someone makes a fast Emacs client with it some day.
| kokada wrote:
| Interesting the decision[1] of building against glibc instead of
| musl. Any reason for not using musl instead (and doing a static
| binary)? This would avoid the compatibility issues e.g.: Alpine
| and Nix.
|
| [1]: https://zed.dev/docs/linux
| oynqr wrote:
| Can you even do GPU acceleration without dynamic libraries on
| Linux?
| kokada wrote:
| This is a good question. It is not like the current `zed`
| binary is linked to anything that is needed for 3D rendering:
| $ ldd zed.app/bin/zed linux-vdso.so.1
| (0x00007ffed63f6000) libgcc_s.so.1 => /nix/store/
| bihw7p4zdqwyxmnc8h67c06lnjkvdan8-xgcc-13.3.0-libgcc/lib/libgc
| c_s.so.1 (0x00007fb5def3c000) libpthread.so.0 =>
| /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-
| glibc-2.39-52/lib/libpthread.so.0 (0x00007fb5def37000)
| libdl.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-
| glibc-2.39-52/lib/libdl.so.2 (0x00007fb5def32000)
| libc.so.6 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-
| glibc-2.39-52/lib/libc.so.6 (0x00007fb5ded3b000)
| /lib64/ld-linux-x86-64.so.2 =>
| /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-
| glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007fb5df05d000)
|
| However it may well be that this is dlopen during runtime,
| and for it to work correctly you need to use the same libc as
| the one in the system.
| alberth wrote:
| Whirlwind week.
|
| First, Zed found to allow silent (non-consented) background
| binary downloads [0]
|
| Now, launching on Linux.
|
| Both of which are big news in its own right.
|
| [0] https://news.ycombinator.com/item?id=40902826
| secondary_op wrote:
| I'm never using this editor unless it can install itself and work
| completely offline, without going for downloads and making web
| requests , it is crucial, especially after totally not related xz
| fiasco and the white house praise for rust.
| llmblockchain wrote:
| I only use editors written in C, as God intended.
| daghamm wrote:
| Correction: written in C plus some LISP, as God intended.
| tarruda wrote:
| This might seem funny until you read Ken Thompson's "trusting
| trust" paper and realize that bootstrapping Rust is a so
| overwhelming task that someone implemented a Rust compiler in
| C++ for this purpose: https://github.com/dtolnay/bootstrap
|
| I mean, who knows what kind of malware is transparently being
| injected in all Rust programs out there.
| umanwizard wrote:
| Nobody wrote a C++ compiler for this purpose; they wrote a
| Rust compiler (mrustc) in C++.
|
| > I mean, who knows what kind of malware is transparently
| being injected in all Rust programs out there.
|
| FWIW, using Guix it is very straightforward to build the
| rust toolchain fully bootstrapped starting from mrustc and
| gcc.
| tarruda wrote:
| > Nobody wrote a C++ compiler for this purpose; they
| wrote a Rust compiler (mrustc) in C++.
|
| Edited the comment
| Gormo wrote:
| If you want a fast, low-memory-footprint editor with no
| spurious network connectivity and a conventional desktop UI,
| check out Geany: https://geany.org/
| colinsane wrote:
| `unshare --user --net zed ~/file-to-edit.txt` seems to work
| fine. it just shows an "auto update failed" warning in the
| bottom, but seems otherwise functional. does that work for you?
| satvikpendem wrote:
| Zed is nice and all, but I simply cannot trust a VC backed editor
| of all things. Eventually, enshittification _will_ occur and I
| really don 't want that to happen to one of my core daily
| programs.
| refulgentis wrote:
| There's something interesting with the light mode / default theme
| I got after downloading and opening on Apple silicon:
|
| Sidebar contrast is too low, yet, spot on for the wrong contrast
| ratio target (3.0, for fill, versus 4.5 for text/bg).
|
| I'll file an issue on GitHub eventually, feel free to pass along
| email in my profile if y'all see this and have someone who is
| already nerding out on this stuff.
|
| Context on why, and before I get more fuzzy/opinionated, why I'm
| comfortable speaking to this is some quasi-authoritative tone: I
| built a new color system that ended up being launched as Material
| You at Google, at its heart is getting contrast while having
| expressive colors instead of just flat black/white, so I _really_
| appreciate the effort here.
|
| Fuzzy/opinionated territory:
|
| Problem with the low contrast here isn't just that it doesn't
| literally hit a 4.5 ratio. IMHO this isn't strictly verboten, if
| I thought that it would mean the engineer part of my brain was
| too in control. There's an argument to be made its good the
| sidebar isn't distracted. Problem is disabled states
| traditionally lower the foreground brightness, so it crosses over
| into "disabled element" territory when you visually parse it.
| mikaylamaki wrote:
| We'd appreciate the issue and discussion! We've been aware of
| contrast issues for some time, and I personally have been
| thinking about switching our color representation from HSL to
| OKLCH to give us more traction on these problems. But I've been
| working on Linux and am not a designer, so I haven't had the
| chance :D
| 1bent wrote:
| https://en.wikipedia.org/wiki/Atom_%28text_editor%29#History...
|
| I found the zed website unhelpful, but if wikipedia is to be
| believed, it's a successor to the Atom text editor
| andrewl-hn wrote:
| The Atom editor is being maintained as a fork: Pulsar
| https://pulsar-edit.dev
|
| Zed is co-founded by one (or more?) original developer of Atom.
| So, it's a successor in a sense that it is a new project by the
| same author.
|
| Atom was developed at GitHub, and GitHub Inc remains the owner
| of the original Atom project. From their perspective the
| successor of Atom is VSCode - developed by their parent
| company, - despite the claims by a former Atom engineer.
| poetril wrote:
| I've kept my neovim config, vscode, and zed configs in parity for
| a while now. To the point that the keybinds and behaviors are the
| same (or as simliar as they can be) across all three. In my
| personal experience zed is eating into the time I use vscode, but
| not really touching neovim as much. It really has come a long
| way, and I'm excited I'll be able to use it on my Linux machine
| without having to jump through hoops.
| Sesse__ wrote:
| First impressions: 1. curl | sh, seriously
| 2. The default theme is so low-contrast that I seriously
| struggled to read text. I could not find something that was,
| like, actual white on actual black. 3. I can figure out how
| to enable Copilot, but not to open a file. (I had to resort to
| "zed file.cpp" from a terminal.) 4. vim keybindings are not
| bad, but also not perfect. 5. It feels... laggy? Isn't this
| supposed to be fast? Whenever I move the cursor over a symbol, it
| first moves and then like 100 ms later, it tries to highlight
| that symbol everywhere. And that takes time. In a 200-line file.
| 6. Ugh programming ligatures. Where are preferences to turn it
| off? Where are the preferences for anything?
|
| OK, well, I guess I could use this if I had nothing better. But
| if the point is that it's supposed to be zero-lag, #5 really
| destroys the point for me.
| Gormo wrote:
| I couldn't even get it to run at all. It's in the official repo
| of my distro, but when I installed that package and tried to
| execute it, the binary launched another executable with a 'zed-
| cli://' URI pointing to some socket/named pipe it tried to
| create under /tmp (but didn't) as an argument, then just sat
| there doing nothing. Seems like it's doing some sort of local
| client-server implementation -- not sure why a standalone
| desktop app would be designed that way.
|
| It never spawned a window, and possibly because the process is
| itself launching another process, nothing is output to stdout
| or stderr to indicate what's going on.
| ajstarks wrote:
| Re: #2, use
|
| "buffer_font_weight": 600
|
| in the settings.json to fix the font rendering.
| maccard wrote:
| > 1. curl | sh, seriously
|
| It's pretty much guaranteed to work cross-platform, and if
| you're worried about it you can save the script and view it
| yourself. You're about to run their binary on your machine, why
| are you concerned about the script you're downloading?
|
| > 2. The default theme is so low-contrast that I seriously
| struggled to read text.
|
| The landing page when I opened the app had an option to choose
| from about 40 themes. I tried 3 of them and they were no
| _worse_ than VSCode's defaults.
|
| > but not to open a file.
|
| usual keyboard shortcuts, and system menu bar?
|
| > Where are preferences to turn it off? Where are the
| preferences for anything?
|
| System menu bar, which links out to some fairly comprehensive
| docs - https://zed.dev/docs/configuring-zed
|
| I agree on the vim keybindigs and the performance, though.
| tedunangst wrote:
| Apparently opening files is so complicated it requires an
| external helper program. https://zed.dev/docs/linux#opening-
| files-does-not-work
| brokegrammer wrote:
| I don't see any way to monetize a free text editor but I see that
| they're hiring and also hired talented devs like Thorsten Ball
| already.
|
| What's the business model here?
| saratogacx wrote:
| From their FAQ:
|
| We envision Zed as a free-to-use editor, supplemented by
| subscription-based, optional network features, such as:
|
| Channels and calls Chat Channel notes We plan to allow offer
| our collaboration features to open source teams, free of
| charge.
|
| https://zed.dev/faq#how-will-you-make-money
| dathinab wrote:
| i.e. very similar to how other editors approach it
|
| e.g. vscode uses network features to make people use the non
| fully open source version instead of codium (and it's
| otherwise subventioned by MS to reach the part of the
| editor/programmer market visual studio can't reach but IMHO
| if it wouldn't be that is also how they would bring in the
| money)
| neurobashing wrote:
| Now see, I'm the opposite. I would like to pay a reasonable
| fee to drive a silver-and-oaken stake through the heart of
| the collab features. I will pay real money to just make it
| all go away. As others have said, I work in an environment
| with lots of different tools so collab stuff like this is
| just visual noise, let me turn it all off.
| the_gipsy wrote:
| be cool and gain traction, to later extract profits?
| ElectronBadger wrote:
| I couldn't find anything resembling "Send code to REPL", so no
| Zed for me.
| levkk wrote:
| > Zed requires a physical GPU with a Vulkan 1.3 driver.
|
| That's new. Does everyone running Linux have a dedicated GPU
| these days? Only caught this because I'm in the middle of
| updating my nvidia driver.
| skavi wrote:
| I believe they mean "physical" as in not implementing in
| software. So integrated GPUs are perfectly fine as well.
| PhilipRoman wrote:
| IMO for a graphical program that's fine, but in general I
| really hate hard requirements for a GPU which I've seen in
| the wild multiple times. Just simulate the darn thing in
| software, I don't care if it takes 10x longer, I have all the
| time in the world.
| colinsane wrote:
| yes. it's working fine for me on 9 y/o integrated intel
| graphics.
|
| but it's kind of still a weird statement to make. i thought
| it was generally the OS's job to supply the vulkan layer, and
| that mesa -- which just about every linux OS will be using --
| provides pretty robust software implementations of those
| things as fallback. what would cause them to require a
| "physical" anything?
| fire_lake wrote:
| Does Zed work with any language with a language server?
|
| Is TypeScript support fully baked in? I don't want to pay for
| things I don't use.
| CapeTheory wrote:
| I have fallen in love with Zed on Mac, so glad to see it will
| still be an option when I switch back to Linux. My main concern
| is the collaboration features; just seems like a nonsensical
| addition. I have zero influence over what editors my teams use,
| and I work with dozens of different people on collaborative
| development every year - I'm not going to be persuading anyone to
| switch, and so that feature is just dead code and security risk.
| Even if I worked on a small and consistent team, I don't think
| the value-add justifies the complexity and risk.
| lexoj wrote:
| Absolutely agree, the collaboration features put me off a bit.
| I think it can very well become a very successful and popular
| editor without those features. Perhaps they can invest in those
| feature when they have a much bigger market share.
| lbhdc wrote:
| I have felt similarly about collab tools. Even if the tools in
| an editor look cool, someone on the team is gonna get left out
| because they use a different tools. It feels a bit like the
| wrong layer for the collab tools to live.
| thesurlydev wrote:
| Super excited for this project. Especially since it's available
| for Linux now.
|
| I still use the JetBrains products as daily drivers but always
| keen to use new tools like this.
| flurly wrote:
| Generally a big fan of Zed. Super fast and quite innovative in
| their grep UI. My biggest current gripe is Zed's filesystem
| watchers are either broken or misconfigured on Mac. If I do a
| `git rest --hard` via terminal or github desktop UI, zed doesn't
| detect it and I'm forced to do a hard reset of the app to get
| back to a synced state.
| lexoj wrote:
| The only reason why I dropped (and Im not alone) using Zed is the
| arcaic UI sublime-like search functionality. Please revisit that
| part because I really want to use ZED.
| bogwog wrote:
| > arcaic UI sublime-like search functionality.
|
| I've never used Zed, but Sublime is my primary editor
| _specifically_ because of the incredible search functionality.
|
| What do you use that's better?
| apatheticonion wrote:
| What does Zed use as the UI toolkit? Looking at the code they
| have a handmade UI toolkit called gpui. Does that map directly to
| OS/DE specific GUI bindings? I can't find where that's happening
|
| EDIT:
|
| Holy sh*t, they actually have bindings for each OS and built a
| Rust abstraction on top of that. That's pretty wild
|
| https://github.com/zed-industries/zed/blob/main/crates/gpui/...
| burnte wrote:
| It's SO BAD when people say ":just pipe this shell script to
| bash!" for their installers. I just can't take those projects
| seriously if they think that's acceptable.
| Buttons840 wrote:
| I've often had the same feeling, but taking a critical view:
|
| How is "run these bash commands", worse than "run this Python
| script", or "run these binary instructions on your CPU"? It all
| seems mostly the same.
|
| What am I missing?
| noisy_boy wrote:
| I am curious - if they provided a link to the script instead,
| would it have been ok? If you want to see the code before
| running, you can just redirect to a file before running it.
| joeldo wrote:
| You can review the bash script first. Regardless, they provide
| a few different installation options https://zed.dev/docs/linux
___________________________________________________________________
(page generated 2024-07-10 23:00 UTC)