The author could try forking and patching VSCode to fix the annoyances manually.

Years ago I had an issue with VSCode: it was missing a small feature that was very important to me, with the GitHub issue stuck in limbo.

I ended up going into the source and implementing the feature myself. It took a few hours after bugfixing, I think the fix was ~100 LOC. Then I used the locally-built version. I recall building took a while, and the source and artifacts took a lot of space, but no other problems.

I also created a PR referencing the issue and it got merged rather quickly. Someone else ended up finishing the work since there were some problems (I think relating to coding conventions, and possible edge cases I didn’t need or handle).

Maybe I was lucky for the feature to not require much edits, and probably for the PR to get taken over and then merged fast. But it seems like the author's issues are also small, and it would be easier and more ergonomic to patch VSCode than to create an entirely new debugger.

I had a near-identical experience. I looked into switching in 2019 and ran into this 2016 bug which was a showstopper for me. Fixed it myself, grand total 4 line diff. https://github.com/microsoft/vscode/issues/10643

This is the way. Anytime I have had issues with an open source project, creating a PR even if it's not great will often have it taken over, improved and merged.

I'm sure someone named some "law" after themselves for this. But it is true that the fastest way to get an answer to a question online is not to ask a question; post the wrong answer.

You are correct!

This is Cunningham's Law [1]! And it seems exceedingly plausible after observing behavior on many online forums!

[1] https://meta.wikimedia.org/wiki/Cunningham%27s_Law

Sometimes it's easier to start from scratch than figure out how some storied monolith works

This article by Joel Spolsky has some good advice related to that: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Tldr: avoid rewriting software. Most likely the gigantic monolith got big because because of all the business logic encoded in there.

Just a thought that sometimes people developing C# since the early 2000s don’t come from an open source culture, so fixing bugs in someone else’s programs doesn’t appear in their default list of resolutions.

Best time to learn was 10 years ago, the second best time to learn (and add it to their default list) is today!

Had you been using Emacs you would have written the fix on-the-fly, eval it and have it be live without even restarting your editor :)

I check with VSCode regularly because obviously an editor that is used by that many developers is worth keeping tabs on (pun n.i.).

I spend some time with it and then go back to Emacs because I can’t justify the trade-off, giving up the raw power and performance for just being more in sync with my team or something.

I’ll readily admit some of the extensions are very nice, like stuff for Kubernetes and so on, and they work well out of box. On the flip side, the customization story is not so great.

With Emacs, I usually spend a bit of time with a new package learning how it works and customizing it to my liking and then it typically becomes more powerful and integrated in my workflow than the VSCode equivalent. Plus the LoC count of a package is usually far far less than of an VSCode extension and I can audit it much faster.

>I'd tweak the script; then to see the results I would press F5 to run the already built binary and wait over a second EVERY SINGLE TIME (about 1480ms).

I put in a bug report for this years ago but it got ignored :( https://github.com/microsoft/vscode/issues/137066

Vscode has gotten slower over time. It's true you can't get nanosecond performance out of JS, but anything under 17ms should be trivial. I believe the vscode developers are skilled, it's just they don't care (imo) enough about performance for whatever reason, and that's a shame.

Everybody who worked writing code in the 70s-90s is smirking at “wait over a second”.

Back in the day, I used to go get my coffee, shoot the shit in the break room for a few minute, and come back to find my debug runs just starting.

Turbo Pascal was so fast in the 80s that if I saw a syntax error further down the page it was faster to hit "compile" and let the compiler move the cursor to the error than it was for me to move the cursor myself.

It was a very special compiler and they don't make them like that anymore.

The trick is to have language "optimized for compilation" and do not do fancy optimizations.

Java is similar (but overall infrastructure around compiler makes it slow).

Golang also quite fast.

I think LLVM missed the boat, on this, by being an early mover. A lot of the optimizations are resource-only analyses; the few that re not are "just" various levels of interpretation. That kind of implies we need a framework to define resource utilization and evaluation at the instruction/machine-code level with a standard API. Having an optimizer for an abstract IR is less useful.

The point being that compilers would then target emitting reasonable machine code at speed, and The Real LLVM would do analysis/transform on the machine code.

The tricks in the 80s were different than today's tricks.

(1) Single-pass compiler. No separate pass to convert to object or executable.

(2) Written in assembler (!). Helps that Pascal has fewer dark corners.

(3) No use of disk. A single file read or write would take 10-20s on a floppy. Instead, it's memory to memory.

It’s crazy that this is still the gold standard

We got outsteped by C and C++ industry adoption, followed by doing everything in interpreted languages.

Finally 30 years later, the pendulum is turning around.

And V 3.01 was under 40 KB (not a typo), and included a basic WordStar editor clone for program editing!

They still do. Lua is likewise extremely fast, and comes without bullshit mostly,

And in the 00's things were pretty instantaneous, at least from a UI perspective. I actually developed some "bad" habits where I'd just hold the step hotkey down to advance my program when debugging. And everything just worked and was synchronous. All the registers updated with each step, as well as my watched variables and everything else I can think of. I'm pretty sure this was visual studio 6.

That was peak Microsoft debugging experience for me, everything after that was worse, admittedly I did drop it and moved to Linux, so maybe it is good now. Although I very strongly doubt it.

This is the reason I like VIM. While I’m mostly using it locally, this deterministic way of handling input means that I can edit over a slow ssh connection faster than the result being displayed. The VIM language is like playing music, you’re only conscious of mistakes.

There was a data entry program (I forget its name) that I liked too. I could enter a complete survey form without watching the screen, just by tab-ing. I memorized the sequences and shortcuts for dropdown. Made a dull job less frustrating.

Amazing how technology has improved and matured in 50 years…

Wasn't that mostly compiling though? VSCode's CMake tools take multiple seconds just starting an already-built executable.

In my experience, that one-second wait to run a binary that you just built is due to realtime scanning by Windows Security. It's not very bright. It sees a new .exe file and assumes you downloaded it from the Pirate Bay, even though it was written by link.exe.

You can disable it as long as Group Policy doesn't dictate otherwise.

Not having an exclusion for a development directory is like using a 10yo machine or using a laptop without the power brick connected: it’s basically leaving half the perf on the table.

Still, a second seems a bit much for a real-time scan.

Under Windows 11, a "dev drive" can also make a big difference.

https://learn.microsoft.com/en-us/windows/dev-drive/

Thanks for tip, TIL

Clearly you do not work for corporate America. Any amount of performance loss is acceptable to check a security compliance checkbox somewhere.

This is the number 1 reason to use macbooks instead of windows laptops at any job. Security compliance software is like a cancer on windows, macos has some of this kind of crap as well but is nowhere near as bad.

I work for a large, slow moving US company in traditional industry. Of course there is an exclusion list, and it contains a few commonly used dirs like “C:\dev” and so on. If that would change (or if the request years back to have company wide exclusions wouldn’t have been listened to), it’s the kind of thing I’d insta-quit a job over, even after 20 years.

So anecdotally (N=1) it’s not automatically horrible in US orgs.

Don't forget the enterprise market has a whole different threat model. Even though blanket exclusions are often used, a determined attacker will quickly figure out to dump their remote exploration tool in c:\dev .

If the attacker gets far enough to be able to put something in c:\dev and run it, your protections have already failed.

I'm on linux tho (and the author of the article)

Wow, marked as-designed. I guess that's one way to fix the issue. In my experience latency needs to be < 250ms to be considered good, 500ms is roughly the max people can put up with, 2s is enough to drive people insane.

When I had a 2 GB laptop lying around, I always wanted a simple text editor with auto-completion etc. (Though only for Python, Linux)

After trying KDevelop, Kate, Eric, Sypder etc. I thought I could write my own.

I had a simple plugin system in mind, with similar to LSP style features (VSCode was not released that time).

The UI was inspired by Blender. Blender has such a fluent UI where you can customize everything.

So I wrote a small GTK library to mimic Blender's UI.

And started development of the text editor. But then got busy with school and left the idea.

Then I found out Emacs and Doom Emacs and dropped the idea of a custom text editor eventually :).

Two reasons: 1. Emacs was 200% configurable, which is what I wanted to implement in my editor too.

2. Emacs worked pretty good on my 2 GB laptop with all the goodies.

But compared to 10 years back (when I was trying these things), it is quite easy now thanks to LSP, Tree-Sitter etc. But it is always a fun ride with algorithms and data structures. :)

I haven't used VSCode, but it is really nice how it changed the text-editor platform with LSP etc.

Now I have a laptop with 24 GB RAM but I'm forever vendor locked-in with Emacs :D

During the vi / emacs wars, the joke was that emacs stood for "eight megabytes and constantly swapping".

How times have changed.

Or, Eventually Munches All Computer Memory.

There were probably other expansions too.

It's now eighty megabytes ;)

Tiny!

I've liked Emacs, but the left-handedness of the key-chords tore me up all the way to the shoulder after any substantial amount of use.

Spacemacs was my answer.

https://www.spacemacs.org/

doomemacs is similar and tends to be lighter and works well native jit compiling all the add ons.

Did you swap caps lock and ctrl?

No, I never did that with stock Emacs.

The 'space' in Spacemacs is how all of the menu options trigger, and I find it a pleasant approach.

I had a very similar experience. I spent so much time searching for answers, early-adopted atom, etc, only to find that vim was the answer the whole time.

I use vscode for doing devops-y things (Terraform, OpenTofu, JSON, python, yaml, txt, dockerfiles, etc.) and sometimes the way it bogs down my system drives me bananas. I'll punt to Sublime Text on occasion and use it for a few days, but then start running into papercuts in various places and have to go back to vscode. I so, so wish there was a better way to do this without fucking electron.

Keep an eye on https://lapce.dev/ and https://zed.dev/ . Both immature, but show a lot of promise! Also both open source, so (in theory, I haven't tried) you can contribute patches to fic your issues

Man, Zed gives me hope, but it's missing so many features and (robust) extensions. Monthly I'll open it and see if I can start working with it, but the day still has not come.

Exactly.

Talk about something as simple as code folding. VsCode does the best job of it I know, and yet the other day it simply stopped working properly for pure JS code, not sure if that's because Microsoft prefers we use Typescript instead of JS. Nothing I did fixed it, and something as simple as that messes us with your workflow. And then I remember that VSCode has introduced a recent bug where after you collapse a piece of code, the file jumps to a weird location. And other paper cuts too numerous to mention, which seems to appear and go randomly

So I tried Sublime text again, only to find that "Collaspe All" does not work properly by design, whatever the reason for that. And it still insists on making many things un-ergonomic.

So I try Webstorm again, and after a few tweaks, it seems to do pretty much what I want. But, it is dog slow, and the display of collapsed comments is a bit weird. I start thinking of writing my own code editor...

My point is pretty much this: The various advanced code editors spend so much effort on advanced features, but they forget that the basic must work flawlessly for most devs to have a good experience. I wish they focused on the basics again to make common sue cases frictionless.

My guess is we have have a different 10% that we consider common use cases. Much the same way folks complain about Microsoft Office being bloated.

> devops-y things (Terraform, OpenTofu, JSON, python, yaml, txt, dockerfiles, etc.)

> I so, so wish there was a better way to do this without fucking electron.

I do all of those things in vim and it works fine. No GUI and I'm sure it's missing some fancy new features, but it's fast and reliable (and it's not electron).

I traded vim for VSCode back when VSCode was fast. These days, there is so much shit running in VSCode by default that it has become an unruly mess. I couldn't tell you what happens when I save or open a file like I could with Vim--what checks are being ran or what telemetry is being exfiltrated.

At this point it's just laziness and inertia keeping me on VSCode, getting my neovim setup back (along with the muscle memory) keeps getting pushed off.

I haven't been able to find an IDE use because their vim integration is only ever for the editor. But I hate having to constantly manage my vim config; I settled on using LazyVim and have been pretty happy. It's heavy as far as vim is concerned, but once you get used to it, it's nice being able to update and not have everything break hah

I had a ridiculously fine tuned neovim setup in my dotfiles that I created over the years, including a nice neovim terminal setup that I can navigate/change using only keyboard (never been a big tmux fan). I've managed to replicate some of it decently with VSCode (vim extension, and I can do CTRL+j to open a terminal and CTRL+k to move back to the editor), but it's just slow and has a tendency of crashing at the worst time.

There is some syntax highlighting for Terraform in nano, so maybe I should try rolling with the terminal for a while.

I have like 10 separate VSCode workspaces (windows) open at all times along with 2 browsers and dozens of tabs and I never feel like my system is bogged down.

In that sense I wonder if your computer just needs an upgrade?

I’m not advocating for e-waste but also if you’re a developer then you’re the most justified person to invest in a beefy system.

E.g., if you have any kind of Intel Mac, you absolutely should upgrade.

I don’t let my computers get older than 3-5 years because compromises to my workflow aren’t worth the cost savings (I just make sure I keep them in good shape and sell them to someone who is going to continue using them). I want to choose the best software for my workflow, which is not necessarily the software that is most resource efficient (that would be like choosing MS Paint instead of Photoshop).

Why do you think your issue has anything to do with electron? That sounds like a meme.

It is your drives, no? Does the browser make your system drives work a bunch? Much more likely, it is VSCode running ripgrep (rg in htop/activity monitor) in the background to find symbols in your codebase.

That would be exactly the same regardless of GUI toolkit.

edit: misread "system drives me bananas" as pertaining to "system drives" nvm

Its not electron, but abusing the webview rendering for realtime software'

Makes me glad I stuck with vim.

I do pretty much the same thing as you, what made you use vscode in the first place? What are the coolest features in your context?

VS Code has a strong plugin ecosystem, and is built around plugins. You can find plugins for everything, so whatever linting, code formatting, back end integration, custom renderers, menus, etc you want you can build and plug in if they aren't available already. Beyond that access to a project tree view / definition list toggle on the side, debug code at cursor, context menu options to refactor/find usage/etc, and easy pixel perfect control of pane layout when working with multiple documents simultaneously.

I never got that deep into vim/emacs but I wasn't impressed with their versions of the features I listed compared to what is available in a good IDE like intellij/vscode. I do wish the performance was a bit better but I have a beastly workstation so it's not a big deal.

I'd say everything you described is true of vim as well, especially nowadays with LSP and tree-sitter and async capabilities in plugins. The plugin ecosystem is thriving. Neovim's lua api makes it even easier to develop plugins.

It does take a fair bit of configuration if you want to start from scratch, but there's also distributions (such as LazyVim [1]) which make it trivial to start from an editor basically as fully featured as VScode.

Of course, there's still the learning curve for a modal editor, but that's the whole point of using vim. I assume there are vi-style plugins for VScode, but then you're missing out on performance.

1: https://www.lazyvim.org/

As well as its own plugins Vim/NeoVim can use VSCode's LSPs, DAPs and extensions either directly or via plugins like CoC[1] and Mason[2].

I would be surprised if emacs couldn't do the same.

1. https://github.com/neoclide/coc.nvim

2. https://github.com/williamboman/mason.nvim

VimL can be cumbersome, but I believe Lua in Neovim can be nicer to work with. But if you’re pressed by time or the task is not that important, I’d say VSCode is good enough. But everything is mostly a CLI away and VIM is especially good interacting with CLI tools. And Emacs is an operating system for texts.

I’d go with Jetbrains IDEs for their language stacks though, because they’re really good at what they do.

Seems like a lot of training wheels to me. I mean linting, formatting can be done by piping buffer into external programs. Not sure what back end integration means but you can accomplish a lot with just bash+vim+tmux (or zellij which I recently switched to).

The disadvantage is of course that it's not integrated, but the advantage is that my editor never crawls to a halt.

Training wheels isn't a fair characterization, the IDE tools are just better for a lot of use cases. I haven't had an IDE grind to a halt since earlier versions of IntelliJ on some large codebases back in ~2016 where the internal linting process lost the plot. Mostly they're just memory hungry and they start up slower.

IMO, the big is one good/smart programming language support, either out of the box or with a few clicks. If you know vim well, the vim plugin has serious limitations though. On windows/linux the reliance on home/end/pgup/pgdn/arrow-keys/del/mouse etc... is atrocious if you are used to vim so the vim plugin is still a life saver. The remote dev extensions also pretty good.

Except for the occasional python I don't need to touch any of that. I'm the author, try looking the editor up in 3 or 6months. It may have most of the papercuts solved. I went after the big things that I had no time to implement the little

Paper cuts like what? Deficiencies in the syntax plugins?

* Drag/drop support from Finder. * Git pre-commit chokes Sublime Merge (for some weird reason), I'm sure I can troubleshoot this but I every time I take a swing at it, it blows up in my face and I give up * Strange autocomplete issues * A few other things I forget about, but will try it again and see if I can remember

It's the terrraform part of the LSP that's buggy and there's an issue open for that on Terraform extension's GitHub repo.

Yeah, the LSP does seem to go through some seriously bad days/weeks.

On the flipside, I recently had to make some changes to a ~1.5GB XML file, like in the middle of the file. I had a sudden flashback to the Atom editor, which developers considered a 1MB XML file as "large", and hence it totally chocked on a 100MB one I tried once, crashing out after eating 8+GB of RAM.

To my mild surprise, it opened in a few seconds, and while all the fancy checking stuff got disabled, basic syntax highlighting still worked so element tags were colorized. Finding and changing the offending element was not much different from normal. I checked memory usage, expecting it to be astronomical, but it was quite within reason (~3 GB IIRC).

I admit I did not expect it to go that well.

You didn't mention which editor you were able to edit the large XML in. Just confirming, it was VSCode? Because that'd be amazing!

Yes, VSCode as of half a year ago.

VSCode is still on the top of accessibility, so when you can claim that you work perfectly with a screen reader, you will convince me to switch.

Emacs

people often overlook accessibility and other essential features of a modern editor, you telling me that your rudimentary rust editor is faster than vscode? and? people don't use it because it's fast (it's not).

How is accessibility an essential feature? I'm not disabled, so I don't care if editor is accessible or not. I care about my use-cases. And I use vscode precisely because it's crazy fast.

You're not disabled yet. But you may want to care about this before your eyesight, motor accuracy, etc. start failing. It's not some big "disabled/not" switch - setting the font 1pt higher is accessibility, changing the colours is accessibility, being able to tab through fields consistently is accessibility, etc.

The idea that I might eventually become disabled still doesn't make it an essential feature. Disabled users are not a significant portion of the userbase of most software. Accessibility is an essential feature for a text editor in the same way that Linux support is an essential feature for Fortnite.

> Disabled users are not a significant portion of the userbase of most software.

Have I got news for you. https://www.disabled-world.com/disability/statistics/

> Currently, around 10% of the world's population, or roughly 650 million people, live with a disability.

> In countries with life expectancies over 70 years of age, people spend on average about 8 years, or 11.5 percent of their life span, living with disabilities.

Sure, not all of the disabilities will apply to using an editor. But disabilities overall are very common. A significant proportion of users of anything are disabled in some way - it just may not be obviously visible.

This is why we have laws protecting disabled people from being ignored by markets. And even in the absence of the law (which may impact your software, talk to your lawyer about the ADA) there's such a thing called morality.

100% of people lose visual acuity.

Flat out you will eventually need glasses and your ability to see differentiate two different colors with a low contrast difference will fall apart.

and yet, wacom pens are not supported. I need it to help with RSI

Fast search shows Vacom to be a proprietary platform on tablets. Not sure how easy it is it to port an app for it, but I might be able to put you on touch with the accessibility product manager of VSCode.

Do you have a preferred com channel?

This reminds me of the famous Visual Studio rant by Casey Muratori https://www.youtube.com/watch?v=GC-0tCy4P1U

And the hundreds (if not thousands :D) of rants by Jon Blow saying how contemporary software performance sucks

Have you seen "Jonathan Blow plays Visual Studio"? I ran across it after I started and understood his pain

That guy is hilarious, thank you for sharing!

Congrats on the launch!

The non-open license is a blocker for me; an editor is perhaps the most important tool for me as a programmer, I'm unwilling to risk not being able to use it how I want. This looks like the same reason that made the author write their own editor. I won't do that, I will stick to vim and emacs.

Sublime text is great! It’s been worth it to write small plugins to fix my biggest complaints but since they got LSP runni by first class it has been a great place to be.

BTW if VSCode is slow for you, check what extensions you have installed.

Yeah, for me it's more than fast enough except for the Microsoft pylance and C# extensions, both of which I really need to feel productive, and both of which (especially pylance) make VS Code much slower and buggier. It has been getting bad enough that I've been looking around for other editors, but as far as I can tell VS Code really wins on having all the language features, plus copilot and git integration in a single place.

C# extension generally has acceptable performance (as long as you use Roslyn LSP and not the Omnisharp one, although it also was fast at the cost of higher memory usage and less stability). What could be slowing it down is other extensions, especially if they have heavy Roslyn analyzers.

For large project it doesn't scale as well, which is where Rider comes into play, I still daily drive VSC as the editor since it's just way snappier and more fluid than Rider.

To be fair, it's not hard to outperform something written in Electron with native code with a factor of ten :) Anyway, this is really impressive, so good job!

Opening a 1GB JSON file and scrolling, editing, and keeping syntax highlighting correct is something that even native text editors struggle with.

Notepad++ is a champ at doing that, as long as it has line breaks. (It chokes with massive single-line files like any other editor)

Love Notepad++ to bits, but it chokes on just 20MB of nicely-formatted XML if you have syntax highlighting on. Disable that (if you can figure out how), and you're golden.

Native code does not replace efficient algorithms.

V8 can also JIT JS to something that runs fast, although the extra layers of abstraction between web code and platform interfaces do not help, and V8 can only do so much.

Sublime have opened way larger files with no issues for me

I’ll second this. And to emphasize, so it’s not just a useless “+1 comment”: I never cared for Sublime as an editor, despite some effort to appreciate it when it was at its popularity peak. But it instantly became, and remained, my go to editor for working with huge files.

I had to buy UltraEdit which is capable of handling 10GB files (the size in my case). Nothing else that I tried would work. Of course, this was ten years ago. I havent had to work with very large text files since then.

It was able to perform search and replace at an acceptable and responsive pace, nearly instant.

With a native editor, like Sublime, it may take a while to become functional, but it will eventually do what I want.

With VS Code, loading in a big file usually crashes it.

Thankfully I don’t have to deal with this as much as I used to.

One of the benefits of Electron is being able to build the same app for multiple operating systems. When writing GUI app using native OS calls, how does one make sure the code is compatible with all three major operating systems?

Folks did this plenty prior to Electron, either by using cross-platform GUI toolkits (GTK and Qt both run on Windows, Java's been doing this forever with Swing and JavaFX, etc), or by writing GUIs for multiple toolkits/OSes that work with the same/similar core application logic.

Electron makes it easier to build cross-platform apps, and certainly cheaper, but it's not like it's the only way to do it.

I'm the author. I had experience with SDL and wrote a test to confirm it still performs well (I never tried it on linux). It did, SDL has been ported to just about every OS. I have some OS specific code for windows but not much. The only OS specific things were executing a binary + stdio + closing it and slight differences in socket code (mostly used for DAP). C++ now has filesystem support so I didn't need any OS specific code for that

This is an important consideration for the developer/publisher, but less so for the user.

I use all three major operating systems on a daily basis, and typically preferentially prefer single-OS apps, as I can typically expect them to be more performant and to better follow a platform's UI conventions.

Were it only that easy

Tell me how its fundamentally not this easy? Its just not really "easy" to write correct compliant code.

> FOR PERSONAL USE ONLY

Since the license says for personal use, I assume that means I can’t use this in a corporate setting?

https://bold-edit.com/download

If you interpret this very strictly it could even imply that this editor couldn't be used to say write open source code that's distributed to the public. Basically all you could do with it is write code at home for your own use.

That’s why I ask actually.

Whats the generally accepted legal interpretation for “personal use”.

I wonder, does it even matter? Who would know what editor you used to write a piece of code?

Unless the author has the significant resources to audit any companies he's suspicious of, no one will know.

All my work in a corporate setting is personal use. It's me personally using the software to earn money.

Point is, "personal use" is such a nonsense term.

I assume that means "don't rely on this in any serious setting" and/or "don't try to sell it for profit".

Is it open source? What programming language and what GUI toolkit does it use?

I really want GUI programs that don't lose a frame no matter what.

I'm the author, I haven't seen it drop a frame when running in a release build. I had experience with SDL and wrote a test to see if it performs as well as I remembered. It did, so I implemented this without using a GUI toolkit. I didn't really want to fight (and optimize) a toolkit to implement syntax highlighting, autocomplete, etc

It's written in C++ because I knew I'd spend time optimizing it. I've been writing C++ for 20years so I didn't hurt my foot or do anything that caused me harm

well, you put SDL in it, which has so many i18n and accessibility gotchas that you've pretty much blown both your feet off already. I'd be surprised if it's keyboard handling is robust enough to work with non US layout keyboards for a start.

This is pretty cool, but why not use neovim or emacs or something?

The only thing that annoys me about VS code is that Microsoft decided to call it visual studio, which means if I search for help for a problem with actual visual studio I end up with vscode suggestions. Id like to know why ms thought this was a good idea.

Microsoft has been flopping with their naming recently... Case in point, Copilot. GitHub Copilot, Microsoft Copilot, Office 365 Copilot... all different products for different uses. Still can't figure out why they didn't follow through with Cortana being the OS copilot name and retired it. It was such a perfect fit. My only guess is that they are worried about anthropomorphizing the AI.

> Still can't figure out why they didn't follow through with Cortana being the OS copilot name and retired it.

I can't figure out why they didn't use it as an opportunity to bring back Clippy.

most likely because of greyhairs with PTSD

It really is too bad vs code is the only available option. If only there were more editors for people to choose!

Yeah imagine if there was an editor that was super fast and lightweight that was designed with extendability as a first class citizen.

VSCode is slow?

I mean, for 7 years? Somewhere around early 2017 things started to get out of hand and VSCode was super hyped. To the point 99% on HN was saying it was very fast. Initially ( Pre 2017 ) it was compared to Atom which means the bar was low. And then somehow people start claiming it was as fast as Sublime or they see no difference.

As someone mentioned down below, both Lapce and Zed is designed with speed in mind. Or just use VIM.

VSCode may be flexible, but it is only fast by the measure of an electron App.

It's fast enough for me to not notice any slowness. I switched to it from JetBrains IDEA because it was literally causing seconds of delays when scrolling / entering code during heavy indexing in large projects. I never noticed anything of the sort in vscode, even if extensions are doing a lot of background work I don't notice any significant impact in the UI, I can always scroll and type without interruption.

I tried out zed, I don't really find it noticeably faster, although I'm sure it is! I guess there are people who are more sensitive to this sort of thing but for me it's really completely fine.

Probably a combination of new developers and wide spread use of SSDs have made it's public image of speed. But really it is pretty quick, on modern hardware it is more or less instant at most tasks.

I use Jetbrains IDEs and am migrating to neovim, even Jetbrains is basically instant searching across large codebases once on good hardware.

If I were to guess, like everything else, it’s fast until you install extensions.

Really cool work. By the way does it support variable DPI? Maybe it's just a limitation of how my sandbox is set up, but font size and everything else seemed a bit small.

Right now I have only the icon and font size as hardcoded. I plan on implementing a config file so users can set their own font, size and etc. I have no idea when I'll release another build. I'll be spending the next week catching up on sleep

As an alternative to VSCode, consider Theia[1].

Open-source, runs all the VSCode extensions, etc.

[1] https://theia-ide.org

That's the one that took the Monaco editor (the part of VS code originally made by Microsoft) and then advertised it as the true alternative to VS Code.

While trying to cough up more details about this, I discovered https://bolinlang.com/faq#:~:text=One%20issue%20we%20have%20... so it seems the skunkworks site design is a thing. I especially enjoyed the "cloud company stol my shit" vibe

Currently and for the past year or so neovide+nvim+lazy has been the thing that got me off vscode.

Lapce https://lapce.dev/ is a very promising up-and-coming editor that has the "VSCode looks" but could use more developer effort to get it to be finally usable.

Should use nvim, btw

No offense, but who made this? How did the submitter find this? The Download page has a name but a Google search doesn’t return much.

Not that anyone would run a binary just like that, but I do find it interesting.

Hey, I'm OP. I did not write this blog post. It was an interesting one from r/programmers that I felt worth cross-posting to HN. Not sure if there's a clear way to indicate that in the title...

Here's the original reddit post: https://www.reddit.com/r/programming/comments/1c8yhll/i_cant...

ok, thanks

I hope developers are among the most careful about putting new things on their systems. I hope.

Nah, we can’t work without admin on our system because we need to install 100 programs we’ve never really vetted, a couple of which have been out of support for a decade.

How else are we going to efficiently add 20,000 lines of code we haven’t read as dependencies to our project… this week?

We’d love to do things safer but it’s not in the sprint plan, which plan assumes speed only possible if you use third party tools and code you haven’t properly vetted for basically everything.

Never mind that then you slow to a halt when infosec sees a CVE rate of ten a week against all those packages you had to have, often against ones you’re not even using but are a dep-of—a-dep for some optional functionality you don’t invoke, and now your team spends 80 person-hours a week addressing those and messaging about doing those and having code reviews of one-line dep version bumps and running regression tests and moving them through the deployment pipeline (we’re Responsible and Safe, as you can plainly see, so of course we have at least three multi-step stages to get to deployment, wouldn’t want to be unsafe!), all because we want to “move fast” but also “be safe” (but not at the same time, so the left hand doesn’t know what the right hand’s doing until everything’s already all fucked up)

(Sigh)

> I hope.

I have... simply the worst of news.

I usually read most of the description's first sentence before downloading a npm package. Does that count?

When you use the word "just," you seem to be implying that Vim is a suitable development environment out the box, when in reality it takes hours of configuration over weeks of time, conservatively. Even then it's not going to supplant VSCode or JetBrains for most people due to its limitations.

there are out of the box neovim experiences, like kickstart.vim. I've kept it largely the same, tweaking only small settings like colorscheme, some line wrapping stuff, like I would in any editor.

You really dont have to take hours to install and tweak and debug 100 plugins anymore, if you dont want to

It’s likely more “out of the box” than developing your own text editor from scratch.

Vim is extremely inaccessible, and most people have better things to do than learning an obtuse and antiquated control scheme used for a single piece of software.

Have you had a good debugging experience with (neo)vim? I'm the author

There are DAP extensions for both Vim (e.g. https://github.com/puremourning/vimspector) and NeoVim (https://github.com/mfussenegger/nvim-dap). I can't speak as to the experience in detail (I think I briefly played with nvim-dap a year or two ago), but I suspect that for most it will be good enough.

It's not ideal for me yet. I've had some problems with DAP. The DAP servers I've checked were a bit unstable and slow. For now I'm using gdb with nvim-gdb https://github.com/sakhnik/nvim-gdb

Very reliable and as fast as gdb is. But with all the problems just using gdb has.

And same for Emacs, great LSP and DAP integration.

I heard someone say gdb works great with emacs but I never had a good experience with C++ in neovim. I asked friends and they all say they use a second editor to debug which is part of why I bothered to do this

Oh, yes, I used to use gdb just a small handful of times a few years ago, but Emacs' gdb mode is very powerful. But I assume there is a gdb DAP as well by now?

Could have just used Visual Studio if you/re deep in C# lol

Have you tried doing much with VS/C# in practice? I get some new, weird bug every time I use it, the UI preview tabs take ages to show up, the compilation delay is easily crossing 2s, etc. It's really not great if you're already bothered by the speed of vscode.

Visual Studio editing experience is just not nice compared to VS Code.

A lot of developers have moved on to Rider or VS Code + Rider combo nowadays.

And Zed?

Doesn't Zed only run on MacOS?

Yes, although there is a Linux version underway. It seems to be about ~80% complete, maybe check it in a few months. No idea of a windows version is in progress or planned though.

vim exists

Should you nvim, btw