17 ms·
Had a look at the About page, and the live coding feature does sound useful. I'm sure the guys are excited; it's a fun project. You get to write algorithms, opt
by torlok 3y ago
Had a look at the About page, and the live coding feature does sound useful. I'm sure the guys are excited; it's a fun project. You get to write algorithms, optimise performance, and do GPU programming. But who needs another text editor that will probably never reach feature parity with Vim and a terminal multiplexer.
- peoplefromibiza 3y agozed is actually very fast though
- v3ss0n 3y agoOnly works on Mac Big no no
- egze 3y agoI actually prefer Mac only apps. It usually means the experience is way more polished.
- loloquwowndueo 3y agoUnless you don’t own a Mac.
- ivancho 3y agoEven more so then. Simplify, simplify, simplify!
- littlestymaar 3y agoMac-only apps come with additional security benefits on Windows and Linux too: there's no safer software than the software you cannot run.
- sofixa 3y agoOr even worse, you own a Mac (say, through work), but aren't entirely in the Apple ecosystem and don't want to relearn everything and fight muscle memory every time you switch devices.
- jeffhuys 3y agoRemap the keys.
- loloquwowndueo 3y agoMost people who say “all editors have vim keybindings just use that” miss the fact that bindings or not, a lot of vim’s functionality is just not available on other editors.
- alpaca128 3y agoAnd that Vim is more than its keybindings, despite the often repeated jokes. Tabs, window splits, search and countless other details may work very differently, and usually not completely with the keyboard.
- loloquwowndueo 3y agoExactly. If all you needed to move off vim were keybindings, then I submit that you weren’t really using vim at all.
- sofixa 3y agoI have (but or course Apple make it hard to do so you need third party software). But that doesn't help with special mac only software that has it's own style, like Arc or Zed.
- Keyframe 3y agocompared to their non-mac versions?
- kstrauser 3y agoI think they mean compared to cross-platform apps that feel equally weird on every system. There’s some talk in the Mac world about “Mac-assed Mac apps”. I use BBEdit as my main editor because it feels right. The default shortcuts are like every other Mac app. You can use standard Mac tools like AppleScript to automate it. It uses the same fonts, widgets, and menu systems as everything else. It’s made for that environment and it shows in a million ways. VSCode is a marvel of engineering and I love that it exists. It also feels uncanny-valley “off” on my Mac in ways that make my brain itch, so I don’t use it. Same with Obsidian: it’s a brilliant app, but it bugs me. It’s not bad in any way, it’s just not the right choice for me.
- noSyncCloud 3y agoThanks for saving my time. Topic hidden.
- 0x6c6f6c 3y agoCross-platform support is in development. You might miss the announcement that actually matters to you
- timeon 3y agoFor now.
- dist-epoch 3y agoSo? It's a code editor. Have you ever seen a serious programmer which is not on a Mac?
- __MatrixMan__ 3y agoOne of the people I admire for their programming skill works on a raspberry pi. I use my work MacBook through ssh because I prefer Sway to MacOS's window manager. We are many and varied.
- jkogara 3y agoTroll often?
- cdelsolar 3y agoLol
- erik_seaberg 3y agoMy favorite corporate laptop and desktop ran Goobuntu. macOS is dissimilar to production hosts in datacenters.
- kvark 3y agoYou can already build and run it in Linux, even type things in and have dialogs! Linux and Windows are coming.
- v3ss0n 3y agoOh that's awesome!!
- smarkov 3y agoThis might be one of those things like monitor refresh rate where you can only really tell the difference if you've experienced the better version for a while, but I haven't ever felt slowed down by the speed of VS Code.
- madeofpalk 3y agoEvery now and then I switch back to Apple's Terminal app, and I'm blown away at how much faster it is at just typing than iTerm it is, and how much nicer that is.
- bbkane 3y agoI switched to iTerm2 a few years ago due to blurry fonts on zoom with Terminal.app . Wonder if that's still a problem? A few months ago I switched to WezTerm and, after some config wrestling, I've been very happy using it (https://github.com/bbkane/dotfiles/tree/master/wezterm https://github.com/bbkane/dotfiles/tree/master/wezterm).
- snet0 3y agoI do think it's something like that. Things can quickly get to the speed that feels "fast enough" that they don't feel subjectively slow, but can still be sped up by a couple orders of magnitude. If you Ctrl-F something and it takes a few hundred ms, you probably don't feel like it was slow, but in reality the "speed-of-light" for this operation was probably orders of magnitude faster than it happened on your device. Once you experience something close to the theoretical speed, it's really hard to go back to something you thought was perfectly fine before. And you start noticing that everything feels slower than it "should".. I think of something like grep, where if I tried to grep a large hierarchy it'd be really slow and I'd sorta reason to myself "well yeah it's a lot of files in a large tree, of course it'll be slow!". Then I installed ripgrep and suddenly what I thought was a reasonable speed was shown to be unreasonably slow!
- peoplefromibiza 3y agoit is actually faster and snappier to use on a beefy M2 max, on the same hardware zed starts up in half the time. the difference is very noticeable. of course it is much less configurable and doesn't work with a lot of things VS Code can do easily. edit: see this comment for a much better explanation than mine of what I originally meant https://news.ycombinator.com/item?id=39409763 https://news.ycombinator.com/item?id=39409763
- madeofpalk 3y agoI would guess most developers do not use vim. Pretending that vim is the universally loved editor that every developer has agreed upon using seems pretty disconnected from the real world. VS Code came up out of nowhere pretty recently, and is used by a lot of people, so that shows that there is (or was, but still post-vim) opportunity for a new editor. Whether Zed is able to gain momentum to cater for the long-tail that other developers do remains to be seen, but I'm pretty keen to see more products trying to compete for users.
- foobarian 3y agoI feel like these classic editors are good to know just for general education like writing cursive. If you end up on some barebones system you will know how to edit a config file and exit. But for day-to-day it's all IDEs nowadays.
- eropple 3y agoThe line between "IDE" and "text editor" has blurred to the point where I'm not sure they're super useful terms anymore. When I used vim up till about 2019, I had it configured with all the toys to the point where it wasn't all that far off of where my VSCode setup is today. Also, you know, insert Emacs joke here assuming if you still have enough RAM to post, etc.
- kstrauser 3y agoI don’t believe there’s a useful distinction, at least for more advanced editors. For instance, I’m not aware of anything you can do in, say, PyCharm that you can’t do in Emacs or Vim. I don’t mean that in a curmudgeonly way like “nothing I care about, because we don’t need those fancy features to write a pageful of Fortran on my 1997 laptop”. I mean, I don’t know of a single feature of any kind that doesn’t exist on essentially all modern editors.
- lelanthran 3y ago> I mean, I don’t know of a single feature of any kind that doesn’t exist on essentially all modern editors. All composed commands. Like Repeat. As in `repeat the following command 5 times`. Like `d5` in Vim (delete 5lines). Or y30 (Copy 30 lines). Or `V?^func` (select text from current cursor position to the beginning of the function). None of those are memorised commands. They're simply one command composed with another. Composability is the real killer feature in Vim. Even in Emacs, I don't get the same ease of composability as I do in Vim.
- jmull 3y agoI can't think of a nice way to express what I think of vim, but I think your general point is apt. Some pretty full-featured editors already exist that people are happy with or, perhaps, have at least gotten used to. Where does a new editor fit in? It's neat that it's "multiplayer" but that's an edge case. I'm also not convinced by the business model. Do people really want channels, calls and chat integrated with their code editor? Personally, I have an almost visceral negative reaction to the idea but maybe that's just me.
- ParetoOptimal 3y agoEmail in emacs is useful because workflow automation can be done based on emails I'm reading. Chat is similar.
- hresvelgr 3y ago> But who needs another text editor that will probably never reach feature parity with Vim and a terminal multiplexer. Feature parity with Vim is not meaningful in my opinion. LSP evened the playing field enough for all editors to the point where you can daily drive anything and be no less productive than most. Use whatever you like and helps you get the job done. That includes Vim too, but I'm getting sick and tired of people acting like using Vim is some kind of irreplaceable boon. Becoming a better thinker will make you an exponentially better programmer than any tool.
- torlok 3y agoVim is just an example. My point was that code at the end of the day is just text, and there's only so many features you need to be able to write/compile/edit efficiently in 99.9% of the cases. Any new power tools for text editing will end up taking more time to learn and remember than be of use.
- __MatrixMan__ 3y agoI'm not so sure. The fact that were editing the code as text and not as mutations and annotations on its syntax tree has always struck me as a sign that we're still in the stone ages when it comes to expressing ourselves precisely to a computer.
- skydhash 3y agoThe basic model of computation is the turing maching, and it’s a symbol manipulating one. So editing text is at the core of what computing is. You could go a step higher to edit tokens and that’s what VIM does, albeit imperfectly due to tokens not being a finite set.
- __MatrixMan__ 3y agoI'm not sure what you mean by "tokens not being a finite set". I suppose there's the theoretical issue of token length being potentially unbounded, but whatever problems your editor has with that, your lexer will likely also have. For any finite length file, there is a finite number of tokens, and once you parse it, you've got a much smaller list of symbols plus a convenient address for each one. I don't think it's a practical issue. Vim's understanding of tokens makes some reasonable assumptions, but unless you've configured the textobjects plugin to talk to a properly configured language server, you're working on vim's presumed tokenization and not a tokenization that's native to whatever the underlying language is. Helix tries to bundle this in by default, but it still doesn't feel like a first class citizen. As for turning machines, not since the 80's have the tokens that appear in our editors been the tokens that are manipulated by our processors. There are typically a myriad of bytecode translations or compiler optimizations or parser hijinks between what you're editing and what you're running. It's the AST that matters to the code author, and the AST is a tree, not a string. We need to get to the point where you can directly annotate on a function parameter: > this function is slow when this parameter is > 100 ...such that the annotation sticks to that parameter, however the viewer has chosen to render the text. The best we can do at present is to sprinkle some text nearby leave the problem of deciding which parameter and which function are referenced an exercise for the reader. This then necessitates that we preserve the way the text appears, which prevents us from presenting it differently based on the view context (e.g. maybe the reader prefers different units, timezones, or a language which flows their text differently than the author).
- giancarlostoro 3y agoIn my opinion I wish more editors would become a face to Neovim which can run in a headless mode, allowing you to not have to emulate VIM at all, but take full advantage of it and all its plugins. It still kills me JetBrians chooses to maintain what VIM users call an awful plugin that simulates VIM, when they could just implement a Neovim front-end natively into their IDE, giving them the edge of "we fully support Neovim and all it brings" which is a much bigger selling point than, we have a VIM-like plugin.
- satvikpendem 3y agoThe VSCode-Neovim extension does this for VSCode, I use it over the VSCode vim extension which is just an emulator.
- lelanthran 3y agoI did not know this. My google/brace/ddg foo is failing me. Do you have a link to the full reference on how one would use headless neovim to provide a full headless vim with a GUI wrapped around it? I'm thinking it would be nice if my Lazarus IDE supported Vim commands.
- giancarlostoro 3y agoFor some reason they're just called GUIs, but its not just some wrapper, it actually uses RPC iirc. https://github.com/neovim/neovim/wiki/Related-projects#gui https://github.com/neovim/neovim/wiki/Related-projects#gui There's also the GitHub topic: https://github.com/topics/neovim-guis https://github.com/topics/neovim-guis
- lelanthran 3y agoThanks, I'll have a look at those pages in more detail. They did not seem applicable when I first saw them, so ... Mea Culpa?
- giancarlostoro 3y ago