Hacker News new | ask | show | jobs
by sammoth 3261 days ago
Because developers may need to delete large folders in Windows
2 comments

That deleting (and moving) large folders is so slow in Windows is a major pain point for node.js developers.
I recently went to an nvme drive... didn't even notice it being particularly faster until I worked on one of my larger node projects... was about 3x as fast as my sata ssds. Never going back to HDD if I can avoid it, I have one for video transcodes, that's it though.
This is incredibly basic computer knowledge. Has Windows actually fallen so far out of the loop that there are developers who know Rust or Go, but don't know something this fundamental?
I neither know Rust nor Go, and I didn't knew about these operations in the Windows. But I get surprised when some other stuff end up in the front page. People have different scopes and the multidisciplinary of HN makes it a valuable network.
It's incredibly basic computer knowledge that a modern day OS is so badly designed that it requires the user to drop into the command line to delete large folders efficiently because otherwise, it spends most of its time telling you how long it will take to tell you how long it will take?

That's one hell of an indictment of Windows!

There's some truth to it though - the Windows Explorer file operations are flaky as hell.

I was just trying to copy files between an old system drive and a new one but I kept getting infinite recursion issues with the "Documents and Settings" (which is linked to Users) directory, permission issues, etc. Even as the SYSTEM user. I wound up having to learn a little robocopy for it.

Yeah, since Windows Vista/7, when Documents and Settings was moved to Users, the system creates new user directories with a bunch of symbolic links/junctions that don't seem to be properly created and always cause issues when copying the directory to another place or deleting the directory. I always get this problem when moving my profile directory out of the system partition.

Incidentally, it's amazing that Windows still doesn't let you specify a custom location to create the profile directory of a new user.

I work with Microsoft stuff every day, but I didn't know the little registry trick at the end, so that's handy.
Windows users vastly prefer modern GUIs instead of old, archaic command line interfaces that were invented in the 1960s.

So, I don't see how these commands should be considered fundamental to those users.

As someone who uses these "old, archaic command-line interfaces" all day, every day, on Linux, Windows, and macOS, I find this characterization very entertaining.

This is an age-old argument (GUI vs command line), and I think each generation coming into computing via the GUI will initially agree with you, but after some time trying to do things that are slow and frustrating using the GUI, will break out into song and dance on discovering the ease and speed with which the command line can do them.

It's all about using the right tool for the job. GUI is awesome for many things, the command line is better for many others.

GUIs are objectively better for every single task. Given a proper choice, 100% of users would choose a GUI over the command line. I have no doubt about this in my mind.

Unfortunately, GUIs are still more difficult to build well. Once that is no longer true, the command line will soon cease to exist.

> GUIs are objectively better for every single task

If they are objectively better for every single task, there will be metrics and studies that prove this objectively. Kindly cite these studies and metrics. I don't think they exist.

I refute the quoted statement with two words: headless servers. Oh, and REPLs. And CLIs embedded in so-called GUIs. In many cases, GUIs contain command-line emulators. Think of, say, Wireshark's filters, or any JavaScript console.

Maybe you are railing against text-mode displays, as opposed to terminal emulation programs that use graphics to emulate a text-mode display?

> Given a proper choice... No true Scotsman...?

Can you even imagine Turing-complete GUI? That's what would be necessary to rival Turing-completeness of scripting in CLI.

And even if such GUI would be created, I don't think it would be any easier to understand than learning CLI commands. And it would require significant overhead to use; consider for example how you would search files for content matching a regex - in CLI I simply type in the regex one-liner, but in GUI I guess I'd have to click around visually building the regex? This would be a nightmare to use.

GUIs definitely are not a good tool for vast range of tasks.

Why would I even want a Turing complete interface? So I can program it? No thanks! Sounds tedious. I want to get my work done, not create more work.

Regex is also not the CLI, it's a text-pattern matching DSL that you enter into your CLI as an argument. There's nothing stopping anyone from using regex patterns in a GUI.

If I had to type regex patterns I'd much, much rather type them into a GUI instead of a CLI because when I do this, the results can be instantly actionable without any further thought. Instead of having to do more CLI-programming to act on the results, I can typically act on them immediately in a GUI.

Better than regex though would be a simple GUI for handling the most common cases (match case, match whole-word, etc - the options that most IDEs offer) and a yes - visual builder for making complex rules for the more complex cases. I'll take a well-built visual builder any day of the week over a textual representation of a regex pattern that I have to use rote memorization or external references to understand.

Today's GUI systems are definitely not a good tool for a vast range of tasks. That's not my point though. GUIs have the potential to be way, way better than any CLI but unfortunately there are a lot of things holding them back like market forces and unimaginative people. I fully expect those things to change at some point, but probably not in my lifetime.