Microsoft Edit

Is... this a meaningful benchmark?

Who's editing files big enough to benefit from 120GBps throughput in any meaningful way on the regular using an interactive editor rather than just pushing it through a script/tool/throwing it into ETL depending on the size and nature of the data?

Challenge. Accepted.

Not on the regular, but there are definitely times I load positively gigantic files in emacs for various reasons. In those times, emacs asks me if I want to enable "literal" mode. Don't think I'd do it in EDIT, though.

Who cares? It’s fun. Programming can be fun.

To turn this around, you can have fun and ask if something is meaningful or not outside the fun at the same time. If it is, great. If it's not, no harm.

As a specific benchmark, no. But that wasn't the point of linking to the PR. Although the command looks like a basic editor, it is surprisingly featureful.

Fuzzy search, regular expression find & replace.

I wonder how much work is going to continue going into the new command? Will it get syntax highlighting (someone has already forked it and added Python syntax highlighting: https://github.com/gurneesh9/scriptly) and language server support? :)

I'm not saying that doing this can't be fun, or even good to learn off of, but when it's touted as a feature or a spec, I do have to ask if it's a legitimate point.

If you build the world's widest bike, that's cool, and I'm happy you had fun doing it, but it's probably not the most useful optimization goal for a bike.

Right, these are more useful features, IMO, than the ability to rip through 125GB of data every second. I can live without that, but syntax highlighting's a critical feature, and for some languages LSP support is a really big nice-to-have. I think both of those are, in this day and age, really legitimate first-class/built-in features. So are fuzzy searching and PCRE find&replace.

Add on a well-built plugin API, and this will be nominally competitive with the likes of vim and emacs.

I have to scroll through huge files quite frequently, and that's the reason I have Sublime Text installed, as it deals with them very well.

At work we have to modify some 500 MB XML's every now and then, as the source messes them up in non-repeating ways occasionally.

Typically we just hand edit them. Actually been pleasantly surprised at how well VS Code handles it, very snappy.

Not a great analogy. This editor is really fast. Speed is important, to a point. But having more of it isn't going to hurt anything. It is super fun to write fast code though.

I have FAR installed for the same reason.

For a text editor, yes, absolutely.

As developers, we rotinely need to work with large data sets, may it be gigabytes of logs, csv data, sql dump or what have you.

Not being able to open and edit those files means you cant do your job.

I use the CudaText for big files. It is like open source Sublime.

But are you really trying to do that on a Windows Server? I feel like there are better tools for the job.

"Better tools for the job" isn't always "the tool currently bringing in the $$$$$$$$$$$$$$$". So you live with it.

Sure, maybe by switching to linux you can squeeze out an extra CPU core's worth of performance after you fire your entire staff and replace them with Linux experienced developers, and then rewrite everything to work on Linux.

Or, live with it and make money money money money.

I work exclusively outside of the windows ecosystem, so my usual go to would be to pipe this through some filtering tools in the CLI long before I crack them open with an editor.

You could make an argument for emacs, but probably not using emacs as a pure text editor.

> make money money money money.

Subject, of course, to Microsoft allowing you to continue to use their software.

I don't think a sentence in a big report page is counted as touting.

less works pretty well if you don't need to edit the files.