You did hear about Snowden and the massive NSA data collection ? That was almost 20 years ago, think about what it's like now: they probably use our data to run an elaborate simulation of everyone.
Yeah, I’m not against the guy I was replying to at all. I don’t want my data in any government coffers. The false equivalency of state sponsored threats in China to a private American company just triggered me.
I’m definitely with you on the nightmare hellscape that is being cooked up by the NSA.
It wasn't China that recently threatened with an invasion of Greenland (I'm Danish). That being said, it's not like you would want your data to go to either countries.
I'm honestly surprised this issue in general didn't cause nearly every company to immediately ban all AI.
Why do these companies put so much effort into fighting right to repair to avoid IP leaks any halfway serious company could reverse engineer in a week, but on the other hand encourage their employees to vibe all company secrets into the cloud?
It's a bit trite, but the answers are: 1) money 2) money
Can't repair your own stuff and either need to use authorized repair shop or buy new? The company gets more money.
Force your developers to forgo quality in efforts to produce more cruft in less time? The company gets more money.
Of course, only considering short-term, long-term they'll lose money, but at that point all the executives and managers already got their bonuses and probably moved on to doing the same in some other company.
Uhh a lot of companies did and are strict on what AI tools are allowed.
The main thing I had to wait on for a long time was support for preventing 3rd party code from being plagiarized since our code base was intermingled with partnered companies.
> Why do these companies put so much effort into fighting right to repair to avoid IP leak
Only if you believe they are truthful about the reason for fighting right to repair. I think the reason for fighting right to repair is to reduce the time before a replacement purchase is required.
> but on the other hand encourage their employees to vibe all company secrets into the cloud?
Lots of companies do ban or restrict usage of LLMs etc.
Sure, AI tools can do this. However, VS Code is the platform. Why aren't more people worried about running arbitrary VS Code extension that can do the same thing, AI or not?
The situation is absolutely insane, but it's also productive, but real security would slow everything down a lot. The moment you ask some corporate bureaucrat to put their signature down on a piece of paper saying that such and such dev tool is approved for use, they're going to block everything to avoid the responsibility implied by their approval. I can't really come up with a system that both works and is secure. The only exception is signing up for an integrated environment where Microsoft or Apple provides the OS, compiler, and editor. Oops - Apple doesn't sell servers, so only Microsoft offers this. Hope you like C#.
In theory you can mix and match, but in practice most bureaucrats will insist on single-sourcing.
Linux development has a blueprint they could follow. Like the principle of least privilege. These aren’t cutting edge concepts.
Also I’m not sure the tradeoffs of adding security to an editor are that big of a deal. Are we really seeing revolutionary stuff here? Every now and then I check out VS Code only to realize Vim is still 10x better.
At the company I work for they locked down installing extensions through the marketplace. Some are available but most are not and there is a process to get them reviews and approved. You might be able to side load them still but I haven’t cared enough to want to try.
As an VSCode extension author, I am always terrified by the amount of power I have.
It is a shame that the team never prioritized extension permission issues [0] despite their big boss said security is the top priority [1]. All they have is "workspace trust" and various other marginally useful security measures.
I don't install a VSCode extension unless it is either official or well known and audited and I have to use it. I keep most of them disabled by default unless I need something for a project. (Even if you don't care about security, it's good for VSCode performance. I'll save that story for another day.)
When some minor extension that I have installed on VSCode updates (like parens colorizing and the like) I think what could happend if the author sells it to some bad actor (or decides to push some weird code in an update).
So I started uninstalling some icon themes and less used extensions that I installed on a whim years ago.
I implicitly trust extensions by Google, Microsoft and the like, but the less known published make me nervous.
It doesn't even have to be malicious. I used a certain syntax highlighting theme for years, when out of nowhere the author pushed an update that rearranged all the colors. It was extremely disorienting. I forked the extension and reverted the change, so I know that one at least won't change out from under me anymore.
This is the thing I hate the most about "automatic updates" in general. I've disabled them and gone back to updating manually because the constant unexpected and unwanted UI changes finally broke a part of my soul. Unfortunately that is something that can't be done on the web, where major UI changes can be rolled out right in the middle of a session on you.
I agree. Sadly most of us aren't going to build from source, and some tools don't really work without sudo. (Did I mention VSCode? On Linux you get a .deb file. Yeah.)
In practice, building from source is not going to fix the problem. Nobody reads the source code of projects they download and compile themselves, certainly not for larger projects. It also takes a long time to compile larger projects. So, realistically, these rarely happen.
Of course, the one advantage of having source is that it is easier to run things like SAST tools against source, but how many people do that in practice? How integrated is that with package systems? And when package maintainers might provide hashes of what they ostensibly checked, you still need trust.
So we need a combination of static analysis tools that are integrated properly to produce trusted binaries, and you need earned trust and authority. Hyperindividualist self-reliance is, at the very minimum, impractical. And with authority, we know whose job it is to care for the quality of software and therefore whom to hang.
> building from source is not going to fix the problem. Nobody reads the source code of projects they download and compile themselves
However commits tend to be much easier to trace at a later date than arbitrary binaries so attackers will be less inclined to go that route. Once committed it's there forever unless you can somehow get everyone to censor it from their own copies for an unrelated reason. Consider that the xz compromise involved downloading the payload later.
My policy is to either obtain binaries from a major distro or to build from a clean commit in a network isolated environment. If I can't go one of those routes it's almost always a hard pass for me.
Is just more characters. But you should do it simply because a poorly written bash script can accidentally mess you up when streaming.
Why sudo though?
I honestly think it's stupidity. Most people really don't know you can build programs to the user and don't need system privileges. I think everyone is just so used to installing from package managers and doing `sudo make install` that they forgot programs only need to be in $PATH and not /usr/bin
Third, you gotta read between the lines a little. I used some convenience considering my audience is programmers. Don't use && or shove && `less foo.sh` in the middle. There's a million options here
Most don't even use functions when writing those scripts and it can straight up fuck your system on accident. It's very unlikely but it can happen and a malicious actor can trigger it on purpose.
But this is true about lots of code. We have this notion of "it works, therefore there's no problem" which is just bad engineering. Just because you don't know there's a problem doesn't mean there isn't. Just because it passes the tests doesn't mean you have test coverage.
Same thing for browser extensions: a simple browser extension (e.g. web dark mode), can read all your password fields. It's crazy that there are no proper permission scopes in any major browsers ! It would have been so easy to make password / email fields exempt from browser extensions unless they ask for the permission.
In your example wouldn't that leave the email and password fields the wrong color? I agree with the principle though. Most extensions don't need to access everything.
Pro tip: I’ve seen plenty of dedicated extensions that could have just been simple snippet equivalents in Tampermonkey - an extension that lets you run JS limited to wildcarded websites.
I've used it to inject download links on sites, autoclose modals, etc. You can either write them yourself, or review other people before installing them.
It’s not a perfect solution, but at least it reduces the surface area to a single extension.
I do not think it'd be "so easy" to separate password input access into a separate permission because it'd only open up a can of worms. There's so many ways to read a password input's value, from listening to key events to monkey patching `fetch`, that it's not worth playing whack-a-mole just to provide users a false sense of security
I'm also skeptical that even a dark mode extension would be simple considering how varied web pages can be
I am (am worried) and recently stopped adding extensions by just the random anon. Also I take time to sanitise foreign (to my knowledge) gh repos using Claude code.
As an aside, claude and codex (and probably gemini) are pretty good at doing that. I've now done it with several repos and they are pretty good at finding stuff. In one case codex found an obscure way to reach around the authentication in one of our services. This is a great use case for LLMs IMHO
They are (of course) not foolproof and very well may miss something, so people need to evaluate their own risk/reward tradeoff with these extensions, even after reviewing them with AI, but I think they are pretty useful.
Installing any 3rd party dev dependency without sandboxing should terrify you. These supply chain attacks are not hypothetical.
Trusting other devs to not write malicious code has led to a surprisingly small number of incidents so far, but I don't think this will extrapolate into the future.
With more lines of code being auto-written without deliberate intent or review from an accountable author, things can only get worse!
What's stopping a vim plugin from doing similar data exfiltration? Tons of people blindly install LazyVim, Spacevim, or other vim tooling and choose a bunch of similar things.
I think it’s the culture behind the (neo)vim community is a bit more technical, and are quite quicker to sound the alarm if anyone tries something shady.
But, in any event, I hand-roll my own config and every plugin I install is inspected by me. When I pull changes, I check the diffs for anything shady. If a plugin is simple enough, I will just integrate it into my own stuff.
I don't really get how VSCode got so popular. You can use a language server perfectly easily with Vim, Emacs, Helix, Sublime, etc. You can customize basically everything in those editors, syntax, etc. You can just alias console commands for all of your build tools with some custom scripts if you need more complex build commands routinely. The git terminal tool works better than any VScode option. And VSCode is slower than all of those.
We already have so many good fast secure polygot customizable text editors. Why run one through Chrome and fill it with extensions for everything that will have arbitrary access to everything?
I used Sublime for years and VSCode is vastly better (the breaking straw was how they'd silo off critical bug fixes in new versions that were pay-only, upon finding vscode I felt silly for not switching sooner, it was so much easier to use and more powerful). Still use vim daily but not as a general IDE, memorizing decades of weird character commands and directives is not a great use of my time.
my favorite VSCode feature is the SSH remote working feature. VSCode gives me the full editing / console / Claude environment on my local workstation, where all files, shells, and yes Claude as well run on a company lab machine over the VPN. Props to the collaborative working feature where several people can all share the same VSCode editor session on their individual workstations.
Vim can do the above two things if you run as a terminal app with tmux. Sublime could do it if you shared the editor via X or Waypipe (well not the second feature). But VSCode integrates it directly in the app and it's a much better experience.
> But VSCode integrates it directly in the app and it's a much better experience.
Not for the admin of the server who has a bunch of idle vscode sessions. Sure, cli users do it too with tmux but the resource consumption is vastly different
I'm sure you're being sincere here but this really reads like that famous HN comment about "who needs Dropbox when ftp exists". The reason vscode is popular is not because it does something impossible to do otherwise, but because it does those things out of the box with a friendly UI.
But we are programmers. I think there is a difference between expect John Accountant who doesn't trust his computer to set up RSync and a server, and a Programmer who is already going to spend a good chunk of their day in a terminal windiow anyways.
Dude I'm tired. Tired of having to learn some stupid new UI paradigm just because.
I really really wish there was ONE standard orthodoxy with regards to UI and how programs work and how we get around them.
Instead we have these clowns constantly inventing new ones. I love learning things and tweaking things but I have limited bandwidth and I am so over micromanaging my PC
For the record I know and love vi. But as I get older I find myself yearning more for the cathedral than the bazaar
I think you missed the issue with the Dropbox comment. Look back at it. He talks about using Linux, FTP, curlftps, SVN, and doing a network mount.
The comment isn't actually even talking about providing the same service, so they mention emailing themselves files and usb drives.
The problem was there was a big technical hurdle to locally network mount a file system. Especially across OSes. It's even harder to do it non locally. Sure, it's not hard if you're familiar with that stuff. Sure, it's not hard to learn if you're comfortable in the terminal. Sure, today you can use rclone. BUT that's not a tool my grandma can use.
On the other hand, we're not talking about tools my grandma can use. We're talking about tools a programmer can use.
> I don't really get how VSCode got so popular. You can use a language server perfectly easily with Vim, Emacs, Helix, Sublime, etc.
You open it. It just works. And the learning curve is smooth.
Compare this to Vim where, if it's the first time you're opening it, you are forced to kill the process because you don't even know how to quit it, never mind actually do any productive work.
Developers? If you can't read docs then you can't do your job.
I don't have much confidence in LLMs replacing devs, but if the dev is so arrogant that they think they're too good for documentation and if they have to read is too complicated, then yeah I believe AI can already replace that person. They were just a warm body, not a dev.
This isn't the flex you think it is. You're really illustrating my point... being able to understand context and make inferences is part of basic literacy skills
> Compare this to Vim where, if it's the first time you're opening it,
If you open vim with a file, like you do with all file editors, there's no such examples. It's also at the bottom of auth/credit/contribution fluff in your example, which people would be expected to ignore.
> Because you can't read
I'm not arguing for more hand holding here, but saying the poster can't read is ironic. Reading is one part, comprehending is the other.
> If you open vim with a file, like you do with all file editors, there's no such examples
I think you are being disingenuous here. I'm serious. VSCode isn't just plug and play. It isn't just "install and away you go". It's not much you have to be taught, but you did have to learn something from somewhere. Either from another IDE with similar visual language or because someone showed it to you.
Besides, your first usage of VSCode isn't going to be opening a file. It also gives you info at the startup.
Are you seriously telling me you haven't Googled how to use VSCode? Or did you just forget because you are now comfortable using it and used to it?
> not sure why we're pretending vim is easy to use
Because it is! I don't know why you're pretending it is hard.
The conversation is no different than iPhone users fumbling their first time on Android and Android users fumbling their first time on iPhones. If you didn't have to learn things then this would never happen. Can there be better communication around vim? Certainly, that's always going to be true. But "run `vimtutor`" is pretty effective and I'm sorry, DEVELOPERS shouldn't be documentation adverse.
If you want to use vim you only need to know a few things. `i` to start typing (insert), esc (or ctrl+[) to go to "command mode", `:w` to write, `:q` to quit. That's literally 4 things. In the standard vim config you can use your mouse and arrow keys, so you don't even need to learn hjkl to get going.
Truthfully, the main difference is where the learning happens. vim forces the user to learn a few things up front (and not many). Getting all my python envs and configuring everything in VSCode took me much longer than the 15-20 minutes it takes to read vimtutor. You get your "Hello World" out faster, but it also makes dealing with environments and other things harder.
What I will admit is that vim is hard to master.
But mastery is very different than usage. Even intermediate level is not hard to achieve once you understand the design language. It's a different way of thinking but come one, it's aimed at programmers. You're really telling me it is hard to learn that there's a command mode and a writing mode? That commands are composed of actions + motions? Going through vimtutor means you should know a lot more commands than vimtutor introduces because of this design language. But mastery? It requires reading docs and years. But that's not a flaw because what you can do in vim is nearly unbounded. While that's also kinda true about VSCode there is a much steeper learning curve you need to do fancy things and that knowledge isn't going to make you really better at general VSCode usage.
> It's a meme
So is the difficulty of assembling Ikea furniture.
People brag about how dumb they are all the time. I don't get how you think that's a defense. There's plenty of docs in the program itself and plenty more online. Many being well written. But ultimately vim isn't being targeted at the general audience (unlike Ikea furniture) and it's perfectly acceptable that it requires a little reading. By my screen you get all the commands I listed, and more, with two screens worth of text from vimturor. 1 screen if you split, since it is 80 chars width. That really isn't much reading. If that is the definition of "hard", for developers, then I have no hope for software. It shouldn't be "hard" or "too much" for anyone. Let's be honest. Are you really okay with the bar being so low that it's impossible for a blind person to trip over?
> It's also at the bottom of auth/credit/contribution fluff in your example
Here's the message
VIM - Vi IMproved
version 9.1.857
by Bram Moolenaar et al.
Vim is open source and freely distributable
Become a registered Vim user!
type :help register<Enter> for information
type :q<Enter> to exit
type :help<Enter> or <F1> for on-line help
type :help version9<Enter> for version info
Not even 10 lines...
If you brag about being lazy, expect to be called lazy.
I just was mainly motivated in replying to your accusation that the original poster couldn't read -- I feel like that claim is pretty disingenuous from the get-go and if I'm being accused of it, well, I'm in good company.
I don't even know what to reply to here, but I'm in general agreeance with most of what you wrote. I just don't agree users type "vim" alone their first time, I'd wager it's following some guide/tutorial online that already has 'vim filename.txt' snuck in there. The fact that people get stuck in vim feels like something intentional to weed out people, otherwise it's a funny problem people run into on other programs like ftp, ssh, screen, even the python interactive shell. There's no unified lexicon on cli tooling, except maybe the gnu clis. It makes you appreciate good GUIs.
The real big brain approach here is to divorce the idea of vim from the command line editor and use it as a plugin in an IDE. Best of both worlds.
While there isn't there is more than most people give credit to. It shouldn't be too much of a surprise giving cli people write cli tools getting inspiration from cli tools. I mean we can't even say there's a unifying language in the GUI space.
> The real big brain approach here is to divorce the idea of vim from the command line editor and use it as a plugin in an IDE
Maybe I'll be convinced when a vim plugin or "vim bindings" represents something close to actual vim. I need a lot more than hjkl, gg, gG and such for movements. It's crazy how few even have H,M,L let alone <C-F>, <C-B>. I'm really surprised so many don't have / bit less surprised at * and the like. An ide giving me vim bindings needs to also give me :Ex, tabs, tags, and so on. I don't think I've ever seen a plugin give me :%s and I'd be really surprised if it gave me \\{-}.
I think there's a lot of confusion when it comes to vim. It's an editor. Editors aren't just for writing and the real power of vim is editing. It's a major bonus that I can do all this with less resource consumption that just a plugin
Frequently using vim bindings in plugins leads to me generating gibberish.
Frequently using vim bindings in plugins leads me to unintentionally closing windows
> You can use a language server perfectly easily with Vim, Emacs, Helix, Sublime, etc.
By the way, the language server protocol was originally developed for VSCode [1]. The popularity of LSP in other editors might have contributed to advertise VSCode.
> We install them without a second thought. They're in the official marketplace. They have thousands of reviews. They work. So we grant them access to our workspaces, our files, our keystrokes - and assume they're only using that access to help us code.
Who is this “we”? I don’t, and don’t know anybody else who does this.
Also, was this article itself written by an AI assistant? If the author is that carefree regarding these extensions, I guess probably.
This is why the architecture of AI tools matters so much. Any extension with full codebase access can exfiltrate - and the same risk exists for AI agents handling credentials or API keys.
We built a password automation tool (thepassword.app) specifically to address this: the AI model orchestrates browser navigation, but actual credential values are injected at the local browser level and never enter the model's context. Even if the model were compromised or prompt-injected, there's nothing sensitive to steal.
The lesson generalizes: for any AI tool touching sensitive data, the safest architecture keeps that data entirely outside the AI's reasoning loop.
bestouff | 17 hours ago
october8140 | 17 hours ago
pcwelder | 16 hours ago
TBF, Cursor's code indexing works the same way, it has to send all workspace files to their servers.
Auto-completion systems need previous edits to suggest next edits so no surprises their either.
raverbashing | 16 hours ago
otabdeveloper4 | 15 hours ago
y-curious | 15 hours ago
“Oh that’s cool, I already donate to my local neo nazi group. We are both philanthropists!”
Nothing makes me go from apolitical to a red blooded American faster than seeing someone make a stupid false equivalency about the US on this forum
mentalgear | 15 hours ago
y-curious | an hour ago
I’m definitely with you on the nightmare hellscape that is being cooked up by the NSA.
otabdeveloper4 | 15 hours ago
In fact, many even are from "hostile countries" that are "enemies of democracy".
What's more, some of those people aren't aligned with US interests and aren't willing to put their lives on the line for CIA operations!
Quothling | 15 hours ago
y-curious | an hour ago
Also, sorry about the whole US threat thing. Nobody I know on the ground here is happy with how we look on the world stage.
DeepSeaTortoise | 16 hours ago
Why do these companies put so much effort into fighting right to repair to avoid IP leaks any halfway serious company could reverse engineer in a week, but on the other hand encourage their employees to vibe all company secrets into the cloud?
embedding-shape | 16 hours ago
Can't repair your own stuff and either need to use authorized repair shop or buy new? The company gets more money.
Force your developers to forgo quality in efforts to produce more cruft in less time? The company gets more money.
Of course, only considering short-term, long-term they'll lose money, but at that point all the executives and managers already got their bonuses and probably moved on to doing the same in some other company.
wxre | 16 hours ago
The main thing I had to wait on for a long time was support for preventing 3rd party code from being plagiarized since our code base was intermingled with partnered companies.
direwolf20 | 16 hours ago
godelski | 13 hours ago
direwolf20 | 10 hours ago
fragmede | 16 hours ago
graemep | 16 hours ago
Only if you believe they are truthful about the reason for fighting right to repair. I think the reason for fighting right to repair is to reduce the time before a replacement purchase is required.
> but on the other hand encourage their employees to vibe all company secrets into the cloud?
Lots of companies do ban or restrict usage of LLMs etc.
pixl97 | 16 hours ago
mat_epice | 16 hours ago
zukzuk | 16 hours ago
tormeh | 16 hours ago
In theory you can mix and match, but in practice most bureaucrats will insist on single-sourcing.
rapind | 16 hours ago
Also I’m not sure the tradeoffs of adding security to an editor are that big of a deal. Are we really seeing revolutionary stuff here? Every now and then I check out VS Code only to realize Vim is still 10x better.
fc417fc802 | 14 hours ago
not_ai | 16 hours ago
They did the same with Chrome extensions.
g947o | 16 hours ago
It is a shame that the team never prioritized extension permission issues [0] despite their big boss said security is the top priority [1]. All they have is "workspace trust" and various other marginally useful security measures.
I don't install a VSCode extension unless it is either official or well known and audited and I have to use it. I keep most of them disabled by default unless I need something for a project. (Even if you don't care about security, it's good for VSCode performance. I'll save that story for another day.)
[0] https://github.com/microsoft/vscode/issues/52116
[1] https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...
yomismoaqui | 16 hours ago
So I started uninstalling some icon themes and less used extensions that I installed on a whim years ago.
I implicitly trust extensions by Google, Microsoft and the like, but the less known published make me nervous.
thedanbob | 15 hours ago
freedomben | 14 hours ago
fc417fc802 | 14 hours ago
Meanwhile random FOSS projects be like "please sudo curl bash to install the prebuilt binaries".
g947o | 14 hours ago
lo_zamoyski | 13 hours ago
Of course, the one advantage of having source is that it is easier to run things like SAST tools against source, but how many people do that in practice? How integrated is that with package systems? And when package maintainers might provide hashes of what they ostensibly checked, you still need trust.
So we need a combination of static analysis tools that are integrated properly to produce trusted binaries, and you need earned trust and authority. Hyperindividualist self-reliance is, at the very minimum, impractical. And with authority, we know whose job it is to care for the quality of software and therefore whom to hang.
fc417fc802 | 13 hours ago
However commits tend to be much easier to trace at a later date than arbitrary binaries so attackers will be less inclined to go that route. Once committed it's there forever unless you can somehow get everyone to censor it from their own copies for an unrelated reason. Consider that the xz compromise involved downloading the payload later.
My policy is to either obtain binaries from a major distro or to build from a clean commit in a network isolated environment. If I can't go one of those routes it's almost always a hard pass for me.
shermantanktop | 14 hours ago
godelski | 14 hours ago
Why sudo though?
I honestly think it's stupidity. Most people really don't know you can build programs to the user and don't need system privileges. I think everyone is just so used to installing from package managers and doing `sudo make install` that they forgot programs only need to be in $PATH and not /usr/bin
esafak | 14 hours ago
godelski | 13 hours ago
Second off, you're not steaming into bash
Third, you gotta read between the lines a little. I used some convenience considering my audience is programmers. Don't use && or shove && `less foo.sh` in the middle. There's a million options here
fc417fc802 | 13 hours ago
That aside, it protects you from this gaping hole of an exploit mechanism. https://news.ycombinator.com/item?id=17636792
godelski | 14 hours ago
But this is true about lots of code. We have this notion of "it works, therefore there's no problem" which is just bad engineering. Just because you don't know there's a problem doesn't mean there isn't. Just because it passes the tests doesn't mean you have test coverage.
dirkc | 14 hours ago
mentalgear | 15 hours ago
fc417fc802 | 14 hours ago
vunderba | 14 hours ago
I've used it to inject download links on sites, autoclose modals, etc. You can either write them yourself, or review other people before installing them.
It’s not a perfect solution, but at least it reduces the surface area to a single extension.
FYI: Just set Script Updates to Never.
https://github.com/Tampermonkey/tampermonkey
sheept | 13 hours ago
I'm also skeptical that even a dark mode extension would be simple considering how varied web pages can be
larodi | 15 hours ago
freedomben | 14 hours ago
They are (of course) not foolproof and very well may miss something, so people need to evaluate their own risk/reward tradeoff with these extensions, even after reviewing them with AI, but I think they are pretty useful.
dirkc | 14 hours ago
Trusting other devs to not write malicious code has led to a surprisingly small number of incidents so far, but I don't think this will extrapolate into the future.
With more lines of code being auto-written without deliberate intent or review from an accountable author, things can only get worse!
apt-apt-apt-apt | 16 hours ago
darepublic | 16 hours ago
deafpolygon | 15 hours ago
You all can take vim out of my cold dead hands.
evilduck | 15 hours ago
deafpolygon | 13 hours ago
I think it’s the culture behind the (neo)vim community is a bit more technical, and are quite quicker to sound the alarm if anyone tries something shady.
But, in any event, I hand-roll my own config and every plugin I install is inspected by me. When I pull changes, I check the diffs for anything shady. If a plugin is simple enough, I will just integrate it into my own stuff.
SanjayMehta | 15 hours ago
Even this reads like an AI extension wrote it.
jszymborski | 15 hours ago
ecshafer | 15 hours ago
We already have so many good fast secure polygot customizable text editors. Why run one through Chrome and fill it with extensions for everything that will have arbitrary access to everything?
mizuki_akiyama | 15 hours ago
bauerd | 14 hours ago
shermantanktop | 14 hours ago
ecshafer | 14 hours ago
godelski | 13 hours ago
zzzeek | 14 hours ago
my favorite VSCode feature is the SSH remote working feature. VSCode gives me the full editing / console / Claude environment on my local workstation, where all files, shells, and yes Claude as well run on a company lab machine over the VPN. Props to the collaborative working feature where several people can all share the same VSCode editor session on their individual workstations.
Vim can do the above two things if you run as a terminal app with tmux. Sublime could do it if you shared the editor via X or Waypipe (well not the second feature). But VSCode integrates it directly in the app and it's a much better experience.
godelski | 13 hours ago
zzzeek | 9 hours ago
qwertytyyuu | 14 hours ago
valicord | 14 hours ago
ecshafer | 14 hours ago
pdntspa | 14 hours ago
I really really wish there was ONE standard orthodoxy with regards to UI and how programs work and how we get around them.
Instead we have these clowns constantly inventing new ones. I love learning things and tweaking things but I have limited bandwidth and I am so over micromanaging my PC
For the record I know and love vi. But as I get older I find myself yearning more for the cathedral than the bazaar
godelski | 13 hours ago
The comment isn't actually even talking about providing the same service, so they mention emailing themselves files and usb drives.
The problem was there was a big technical hurdle to locally network mount a file system. Especially across OSes. It's even harder to do it non locally. Sure, it's not hard if you're familiar with that stuff. Sure, it's not hard to learn if you're comfortable in the terminal. Sure, today you can use rclone. BUT that's not a tool my grandma can use.
On the other hand, we're not talking about tools my grandma can use. We're talking about tools a programmer can use.
https://news.ycombinator.com/item?id=9224
kouteiheika | 14 hours ago
You open it. It just works. And the learning curve is smooth.
Compare this to Vim where, if it's the first time you're opening it, you are forced to kill the process because you don't even know how to quit it, never mind actually do any productive work.
godelski | 14 hours ago
I'm serious. Open a blank file by typing `vim` into the terminal. Don't press anything, just look at the screen.
I'm sorry, but reading docs, or just reading, shouldn't be considered a significant barrier to entry.
SoftTalker | 13 hours ago
Rule number one is that users don't read documentation.
godelski | 11 hours ago
General public? Yeah, assume idiotic.
Developers? If you can't read docs then you can't do your job.
I don't have much confidence in LLMs replacing devs, but if the dev is so arrogant that they think they're too good for documentation and if they have to read is too complicated, then yeah I believe AI can already replace that person. They were just a warm body, not a dev.
Daishiman | 12 hours ago
godelski | 11 hours ago
Daishiman | 2 hours ago
mrmuagi | 10 hours ago
If you open vim with a file, like you do with all file editors, there's no such examples. It's also at the bottom of auth/credit/contribution fluff in your example, which people would be expected to ignore.
> Because you can't read
I'm not arguing for more hand holding here, but saying the poster can't read is ironic. Reading is one part, comprehending is the other.
godelski | 9 hours ago
Besides, your first usage of VSCode isn't going to be opening a file. It also gives you info at the startup.
Are you seriously telling me you haven't Googled how to use VSCode? Or did you just forget because you are now comfortable using it and used to it?
Because it is! I don't know why you're pretending it is hard.The conversation is no different than iPhone users fumbling their first time on Android and Android users fumbling their first time on iPhones. If you didn't have to learn things then this would never happen. Can there be better communication around vim? Certainly, that's always going to be true. But "run `vimtutor`" is pretty effective and I'm sorry, DEVELOPERS shouldn't be documentation adverse.
If you want to use vim you only need to know a few things. `i` to start typing (insert), esc (or ctrl+[) to go to "command mode", `:w` to write, `:q` to quit. That's literally 4 things. In the standard vim config you can use your mouse and arrow keys, so you don't even need to learn hjkl to get going.
Truthfully, the main difference is where the learning happens. vim forces the user to learn a few things up front (and not many). Getting all my python envs and configuring everything in VSCode took me much longer than the 15-20 minutes it takes to read vimtutor. You get your "Hello World" out faster, but it also makes dealing with environments and other things harder.
What I will admit is that vim is hard to master.
But mastery is very different than usage. Even intermediate level is not hard to achieve once you understand the design language. It's a different way of thinking but come one, it's aimed at programmers. You're really telling me it is hard to learn that there's a command mode and a writing mode? That commands are composed of actions + motions? Going through vimtutor means you should know a lot more commands than vimtutor introduces because of this design language. But mastery? It requires reading docs and years. But that's not a flaw because what you can do in vim is nearly unbounded. While that's also kinda true about VSCode there is a much steeper learning curve you need to do fancy things and that knowledge isn't going to make you really better at general VSCode usage.
So is the difficulty of assembling Ikea furniture.People brag about how dumb they are all the time. I don't get how you think that's a defense. There's plenty of docs in the program itself and plenty more online. Many being well written. But ultimately vim isn't being targeted at the general audience (unlike Ikea furniture) and it's perfectly acceptable that it requires a little reading. By my screen you get all the commands I listed, and more, with two screens worth of text from vimturor. 1 screen if you split, since it is 80 chars width. That really isn't much reading. If that is the definition of "hard", for developers, then I have no hope for software. It shouldn't be "hard" or "too much" for anyone. Let's be honest. Are you really okay with the bar being so low that it's impossible for a blind person to trip over?
Here's the message Not even 10 lines...If you brag about being lazy, expect to be called lazy.
mrmuagi | 7 hours ago
I don't even know what to reply to here, but I'm in general agreeance with most of what you wrote. I just don't agree users type "vim" alone their first time, I'd wager it's following some guide/tutorial online that already has 'vim filename.txt' snuck in there. The fact that people get stuck in vim feels like something intentional to weed out people, otherwise it's a funny problem people run into on other programs like ftp, ssh, screen, even the python interactive shell. There's no unified lexicon on cli tooling, except maybe the gnu clis. It makes you appreciate good GUIs.
The real big brain approach here is to divorce the idea of vim from the command line editor and use it as a plugin in an IDE. Best of both worlds.
godelski | 3 hours ago
I think there's a lot of confusion when it comes to vim. It's an editor. Editors aren't just for writing and the real power of vim is editing. It's a major bonus that I can do all this with less resource consumption that just a plugin
Frequently using vim bindings in plugins leads to me generating gibberish.
Frequently using vim bindings in plugins leads me to unintentionally closing windows
bardackx | 9 hours ago
A lot of people can't, that is why vscode is so popular
godelski | 8 hours ago
A lot of developers not being able to read is terrifying.
guestbest | 12 hours ago
guyomes | 11 hours ago
By the way, the language server protocol was originally developed for VSCode [1]. The popularity of LSP in other editors might have contributed to advertise VSCode.
[1]: https://en.wikipedia.org/wiki/Language_Server_Protocol
flufluflufluffy | 12 hours ago
Who is this “we”? I don’t, and don’t know anybody else who does this.
Also, was this article itself written by an AI assistant? If the author is that carefree regarding these extensions, I guess probably.
sweetrabh | 3 hours ago
We built a password automation tool (thepassword.app) specifically to address this: the AI model orchestrates browser navigation, but actual credential values are injected at the local browser level and never enter the model's context. Even if the model were compromised or prompt-injected, there's nothing sensitive to steal.
The lesson generalizes: for any AI tool touching sensitive data, the safest architecture keeps that data entirely outside the AI's reasoning loop.