There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

1984 ,
@1984@lemmy.today avatar

I can see the beginning of something truly great in this editor. It’s going to become better than VS code in a year.

It’s already great for some languages like Go and Rust.

Telorand ,

I hope that’s true, but it will be an uphill battle for them to get people to move. VS Code is already pretty good.

possiblylinux127 ,

VScode is proprietary and slow. If you are using something like that you should use VScodium

Mihies ,

But aren’t both the same speedwise?

possiblylinux127 ,

Yes but one is libre without telemetry

cerement ,
@cerement@slrpnk.net avatar

also seems to have some security issues

krolden ,
@krolden@lemmy.ml avatar

Lmao fuck this project

priapus ,

They are addressing this here: github.com/zed-industries/zed/pull/14034

krolden ,
@krolden@lemmy.ml avatar

Thats not the point. Why should you trust anything from this project after they would allow third party unsigned binaries from questionable sources

priapus ,

Because people can make make mistakes…

Loads of important projects have had vulnerabilities that showed up through minor mistakes and oversights. I agree that this shouldn’t happen, but it did. I’d still prefer this project to a closed source editor/IDE and even VSCodes method of having a store full of plugins, many of which are closed source and unverified. The project is in alpha, mistakes and problems are expected. This was obviously an oversight, and after being pointed out, it is being addressed.

Can you elaborate on questionable sources? All the sources I saw were the official sources of the binaries they wanted to download.

MagisterSieran ,

There ought to be a rule that posts about software releases have to say what it is.

cerement ,
@cerement@slrpnk.net avatar

Zed (a high-performance code editor announced in 2022), not to be confused with Xed (a small and lightweight text editor released in 2016)

EDIT: or Yed (a small and simple terminal editor core)

ksp OP ,

My bad, it’s up now

bionicjoey ,

Installer is piping curl into shell

I thought we were past this as a society 😔

kazaika ,

I mean its already in the nix repos as well as homebrew which means its essentially taken care of

GravitySpoiled ,

I’ve been using it with the nix package manager. It’s awesome how easy nix works

pukeko ,

It appears to be a couple of versions behind … and have some issues with dynamically linked libraries that hinder LSPs. Neither of these is Zed’s fault. I’m sure the packaged version will be up to date momentarily (given the interest in Zed, sooner rather than later). Not sure how easy the LSP thing will be to fix, though there are some workarounds in the github issue.

priapus ,

yeah the editor is being updated way too fast for nix to keep up. I’m sure it’ll be easier once it has its stable release. I see the have a nix flake in the repo, it would be great if they added a package to the outputs instead of just a devshell, nix users could easily build it from master or whichever tag they want.

There are solutions in this issue to the LSP issue. The editor would need to be built in an fhs-env, or they will need to find a way to make it uses binaries installed with nix instead of the ones it downloads itself. VSCode had a similar issue, so there is a version of the package that let’s you install extensions through nix, and another that uses an fhs-env that allows extensions to work out of the box.

krolden ,
@krolden@lemmy.ml avatar

So it should say hey check your distros package repos first.

atzanteol ,

Yeah. Especially rather than saying “curl/bash” is the preferred way of installing.

gravitas_deficiency ,

There are various package manager vectors for installation listed in the docs

Telorand ,

That was my first thought as well, but I will say that uBlue distros had a signing issue preventing updates recently, due to an oversight with how they rotated their image signing keys, and the easiest (maybe only?) solution was to pipe a curl command to sh. Even though uBlue is trustworthy, they still recommended inspecting the script, which was only a few lines of code.

In this case, though, I dunno why they don’t just package it as a flatpak or appimage or put it up on cargo.

Edit: nvm, they have some package manager options.

eager_eagle ,
@eager_eagle@lemmy.world avatar
cerement , (edited )
@cerement@slrpnk.net avatar

ooh, available for “x86_65” on Alpine

(and they’ve fixed that now)

executivechimp ,
@executivechimp@discuss.tchncs.de avatar

x86_64++

SidewaysHighways ,

Plus ultra!

eager_eagle ,
@eager_eagle@lemmy.world avatar

imagine the nightmare of writing a 65 bit instruction set

laughterlaughter ,

I don’t think it has to be a nightmare per se if you start from scratch.

Instead of 8-bit bytes, you have 5-bit “bytes” (fyves?) Hoozah! Done.

eager_eagle ,
@eager_eagle@lemmy.world avatar

only if double precision can be called high fyves

laughterlaughter ,

This is a mandatory rule now.

yogurtwrong ,
@yogurtwrong@lemmy.world avatar

Now imagine designing a 65 bit computer. The bus, registers, alu…

You’ll probably waste a lotta chips since most of them are designed for working with powers of 2

bitcrafter ,

Have you really not heard of it? It is a new architecture that is a bit better than x64_64.

mlg ,
@mlg@lemmy.world avatar
krolden ,
@krolden@lemmy.ml avatar

Not until after you convince these projects to stop using discord

TunaCowboy ,

It is worrisome that all the smug elitists are too incompetent to just leave off the pipe and review from stdout, or redirect to a file for further analysis.

Same people will turn around and full throat the aur screaming ‘btw’ to anyone who dares look in their direction.

skilltheamps ,

By that logic you have to review the Zed source code as well. Either you trust Zed devs or you don’t - decide! If you suspect their install script does something fishy, they could do it just as well as part of the editor. If you run their editor you execute their code, if you run the install script you execute their code - it’s the same thing.

Aur is worse because there usually somebody else writes the PKGBUILD, and then you have to either decide whether to trust that person as well, or be confident enough for vetting their work yourself.

krolden ,
@krolden@lemmy.ml avatar

Eh using aur is a bit different since most of# them pull the projects git repo directly anyway. Yeah the project might have vulns but thats on you to inspect before building it as well as the pkgbuild itself

ReversalHatchery ,

Can’t we basically call this a remote access trojan?

skilltheamps ,

Security wise it doesn’t matter, you run the code they wrote in any case. So either trust them or don’t. Where it matters is making a mess on your computer and possibly leaving cruft behind when uninstalling. But packages are in the works, Arch even has it since before linux support was announced officially.

GravitySpoiled ,

So did fedora and nix

ParetoOptimalDev ,

This isn’t true because until the PR fixing it goes through it downloads other binaries without user consent.

skilltheamps ,

I think you slipped in the discussion intendations somewhere, this branch of the discussion tree is about the implications of piping curl into bash vs. installing packages

wfh ,

A curl piped into a shell or some unofficial packages from various distros.

At this point I don’t get why these projects are not Flatpak-first.

ParetoOptimalDev ,

Flatpak is worse for debugging, development, and reproducibility.

Its good for user friendly sandboxing, portability, and convenience.

wfh ,

Is it really worse tho? A single build, against a single runtime, free from distro specificities, packaged by the devs themselves instead of offloading the work on distro maintainers?

ParetoOptimalDev ,

I’ll have to come up with some examples and write something more detailed I think to explore this.

Until NixOS I was very in favor of language specific package managers and things like flatpak.

crispy_kilt ,

It is. Security problem in core library? Good luck waiting for 27 randos releasing an update. Whereas the distro updates it even before the issue becomes public.

GravitySpoiled ,
ParetoOptimalDev ,

You see the conclusion of that article is that flatpaks are not repeoducible after presenting solutions to make it reproducible right?

carrabelloy ,
@carrabelloy@darknight-coffee-cannabis.club avatar

@ParetoOptimalDev @GravitySpoiled Tusky 25.2

Device:

Fairphone FP4
Android-Version: 11
SDK-Version: 30

Account:

@carrabelloy
Version: 4.2.10

eveninghere ,

GPU-accelerated renderer.

There’s a reason why GUIs don’t render fonts in the GPU.

shy_mia ,

Because it’s a pain, there’s not much more to it really…

eveninghere ,

AFAIK it’s the copy cost for the memory. GPU makes sense only when the hardware allows this copy to go away. Generally, desktop PCs don’t have such specialized hardware.

shy_mia , (edited )

I don’t see why you’d have to copy all that much. Depending on the rendering architecture, once all the glyphs are there you’d only need to send the relevant text data to be rendered. I don’t see that being much of a problem even when using SDFs. It’s an extremely small amount of data by today’s standards and it can be updated on demand, but even if it couldn’t it would still be extremely fast to send over every frame. If games do it, so can text editors. Real time text rendering on the GPU is a fairly common practice nowadays, unfortunately not in most GUI applications…

eveninghere ,

At this point I’m not expert enough to explain more details. You can check font renderers.

Below is what’s in my mind but it’s just a guess.

In typical PC architectures you have IO between the storage and the RAM, and then there’s the copying from the RAM to the VRAM, and editors maybe also want copying from the VRAM to RAM for decoration purposes etc.

shy_mia , (edited )

I am familiar with the current PC and GPU architectures.

IO is a non issue. Even a massive file can be trivially memory mapped and parsed without much hassle, and in the case of a text editor you’d have to deal with IO only when opening or saving said file, not during rendering.

As for the rendering side, again, the amount of memory you’d have to transfer between RAM and VRAM would be minimal. The issue is latency, not speed, but that can be mitigated though asynchonous transfer operations, so if done properly stutters are unlikely.

Rendering monospaced fonts (with decorators and control characters) at thousands of frames a second nowadays is computationally trivial, take a look at refterm for an example. I suspect non-monospaced fonts would require more effort, but it’s doable.

As I said at the beginning, it’s not impossible, just a pain. But so is font rendering in general honestly :/

eveninghere ,

As I indicated, please check (articles and the documentations of) font renderers at this point.

PushButton ,

It’s made in rust, therefore it must be safe!

mogoh ,

Interesting project, how ever it will be hard to compete with existing editors and its plugin eco-systems.

GravitySpoiled , (edited )

I don’t think so. The guys who write the plugins are the cracks and the cracks will use zed.

priapus ,

It supports LSPs, and has treesitter syntax highlighting and git integration which honestly makes it 90% of the way there already

linucs ,

Vim keybindings or death

aaro ,

It has those as well

linucs ,

Great!

tabular ,
@tabular@lemmy.world avatar

What’s that?

coolmojo ,

Integrated Development Environment (IDE) from the makers of Atom. It is written in rust.

electricprism ,

New Editor, by Atom Devs, Rust

Buildout ,

Editor, Atom, Rust

YourMomsTrashman ,
@YourMomsTrashman@lemmy.world avatar

EAR

gravitas_deficiency ,

Oh man I LOVED Atom. Giving this new one a test drive now :)

RayJW ,

I think Zed is quite different from Atom. But Pulsar might be your thing. A direct fork of the last release of Atom being developed by ex Atom developers :)

gravitas_deficiency ,

I just mean that I liked the work that the devs did on Atom, which makes me want to try this one out too

RayJW ,

Oh, in that case you might like either. I think both are great in their own way!

Daeraxa ,

Just to clarify, the Pulsar devs aren’t ex-Atom devs. Some of the team are from atom-community but none of the core Pulsar team were part of the official Atom team.

RayJW ,

Oh, interesting. In that case I misunderstood that part, I thought there were core devs of Atom involved in Pulsar, thanks :)

Daeraxa ,

Watch this space for the full history, I’m literally putting the final touches on a blog post that will go into details of how Atom started then how it became Pulsar as a little celebration after we hit 3k stars.

tabular ,
@tabular@lemmy.world avatar

Thanks. I briefly used Atom (on Win) but stopped as it was terribly slow to startup.

What is the software license for Zed? It’s Github page isn’t clear.

furzegulo ,

The code for Zed itself is available under a copyleft license to ensure any improvements will benefit the entire community (GPL for the editor, AGPL for server-side components). GPUI, the UI framework that powers Zed, is distributed under the Apache 2 license, so that you can use it to build high-performance desktop applications and distribute them under any license you choose. zed.dev/blog/zed-is-now-open-source>

Virkkunen ,
@Virkkunen@fedia.io avatar

Zed is not an IDE, it's a code editor. No, they aren't the same things, it's like saying a table and a kitchen are the same thing.

coolmojo ,

You are right, stand corrected.

eager_eagle ,
@eager_eagle@lemmy.world avatar

This distinction is not as meaningful as it used to be before LSPs; there’s little a PyCharm IDE can do that you can’t do in VS Code editor for example.

markstos ,

Anyone care to compare this with Helix?

Bolt ,

Very first impressions since I literally just downloaded before writing this, and haven’t read the manual, I may change my mind with more experience.

  • It’s incredibly snappy, to my eyes as fast as Helix.
  • A lot of stuff that took me a while to figure out in VS Code was immediately obvious. How to toggle inlay hints for Rust? Parameter Icon > Inlay Hints (with the keyboard shortcut there for easy toggling).
  • Interactive is generally intuitive because it seems pretty permissive. Tab vs Enter to autocomplete? Either! ctrl-shift-Z vs ctrl-Y to redo? Same thing!
  • After being so used to Helix I often reach for keybinds that don’t exist. I might have to learn Vim keybinds because I’m definitely going to keep trying Zed.
  • Not sure how I feel about what seems to be an inline discord-like chat/voice-call feature.

Going to check out if there’s git integration, because I couldn’t easily find it.

pukeko ,

Git integration seems to be so embedded that it’s easy to miss. Open a git repository folder and you can switch branches and whatnot. But, like, in the command palette, there’s no Git > Pull or Git > Clone as in vscode. (I have barely scratched the surface so it might be there hiding in plain sight.)

toastal ,

What other VCSs are supported?

hemko ,

Going to check out if there’s git integration, because I couldn’t easily find it.

Asking this because I’m noob, not elitist ass: Why a git integration in ide instead of using the cli? I’ve been working only on few projects where git is used, but the cli seems to be a ton easier to understand how to work with than the git integration in vscode which I discarded after few attempts to use

iiGxC ,

I mainly use git with cli, the one thing that’s been super helpful in vscode is gitlens, which shows you who last updated the line you’re on, and lets you look at the commit

hemko ,

Oh that sounds very sweet!

micka190 ,

Depends on the features.

Git has some counterintuitive commands for some commands you may want to do when you want to quickly do something. Being able to click a button and have the IDE remember the syntax for you is nice.

Some IDEs have extra non-native Git features like have inlined “git blame” outputs as you edit (easily see a commit message per-line, see who changed what, etc.), better diff/merge tooling (JetBrain’s merge tool comes to mind), being able to revert parts of the file instead of the whole file, etc.

the git integration in vscode which I discarded after few attempts to use

I’m going to be honest, I don’t really like VS Code’s Git integration either. I find it clunky and opinionated with shitty opinions.

hemko ,

Git has some counterintuitive commands

Yeah… ‘git merge main’ weirds me out because my brain likes to think the command is merging current branch TO main instead of other way around

Some IDEs have extra non-native Git features like have inlined “git blame” outputs as you edit (easily see a commit message per-line, see who changed what, etc.), better diff/merge tooling (JetBrain’s merge tool comes to mind), being able to revert parts of the file instead of the whole file, etc.

Okay this sounds very good, so they actually improve git cli feature wise in addition to implementing GUI for it.

Thanks for the reply!

Bolt ,

I’m probably more of a git noob than you, but I do usually use the cli. I figured if I’m going to give a gui editor an honest shake I should try to do things the inbuilt, gui, way. And more to the point, I do appreciate a good user interface with information at a glance or click instead of having to type out a command each time.

hemko ,

I’m probably more of a git noob than you

Doubt =D

And more to the point, I do appreciate a good user interface with information at a glance or click instead of having to type out a command each time.

Agreed with good user interface, my criticism was specifically for the vscode default git plugin which I was not compatible with at all but it could be just a me-problem

flux ,

A great git integration can work well in an editor. I use Magit in Emacs, which is probably as full-featured Git-client as there can be. Granted, for operations such as cherry-picking or rebasing on top of a branch I most often use the command line (but Magit for interactive rebase).

But editor support for version management can give other benefits as well, for example visually showing which lines are different from the latest version, easy access to file history, easy access to line-based history data (blame), jumping to versions based on that data, etc.

As I understand it vscode support for Git is so basic that it’s easy to understand why one would not see any benefits in it.

ParetoOptimalDev ,

This video using emacs magit git porcelain might help you see why:

m.youtube.com/watch?v=qPfJoeQCIvA&feature=youtu.b…

Basically you can go quickly from the log to viewing diffs or any other action on commits or groups of commits and more.

I used to only use git from CLI for 10+ years but mostly only use magit now.

pukeko ,

Zed has a lot more features and is GUI-based. Helix is more focused and is CLI-based. I think a more direct comparison would be with VSCode(ium).

theshatterstone54 ,

Why Helix over (neo)Vim?

priapus ,

Better/simpler experience out of the box. With Helix you install the LSPs for languages you use and you’re set with a fully featured editor. Manual configuration is only needed for setting themes, keybinds, and small setting changes. It also feels much faster than a fully configured vim/neovim. Lastly its keybinds are inspired by Vim/Kakoune, but different from both.

markstos ,

A better out of the box experience-- fewer plugins required. More discussion here: urbanists.social/

theshatterstone54 ,

Cool, but is it possible to add vim bindings to Helix? I’m too used to them, I even use them in Emacs.

markstos ,

A lot of the bindings are the same, because Helix was inspired in part by Vim.

Helix overall tries to make more consistent vocabulary and “nouns” and “verbs” in the keybindings, so there are some breaking changes.

Someone published a more “vim-like” set of keybindings for Helix: github.com/LGUG2Z/helix-vim

I started with that and then have slowly disabled a number of them as I come to appreciate the Helix defaults, and have realized that some of these vim-bindings are overriding other Helix bindings that I wanted.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines