Live data from Hacker News

Microsoft Edit

github.com

31–40 of 337 posts

Re: Microsoft Edit

#31
post #22

Earlier quoted context omitted.

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?

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 ) an…

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.

Re: Microsoft Edit

#33
post #27

It'd be nice if they didn't recommend winget for installation though. winget is an egregious security risk that Microsoft has just like pretended follows even minimal security practices, despite just launching four years ago with no protection from bad actors whatsoever and then never implementing any improvements since.

disclaimer: I used to commit to winget a lot and now I don’t. …but is it really less secure than brew or choco? The installers are coming from reasonably trusted sources and are scanned for malware by MS, a community contributor has to approve the manifest changes, and the manifests themselves can’t contain arbitrary code outside of the linked executable. Feels about as good as you can get without requiring the ISVs…

The installers are coming from random people on the Internet. Most software repositories have trusted contributors and a policy of requiring a piece of software be arguably worthy of inclusion. Perhaps because Microsoft is afraid to pick winners, every piece of garbage is allowed on winget, and there's no way to restrict who can make changes to what packages.

There are ISVs that would like to lock down their software so they can maintain it but a trillion dollar company couldn't spare a dollar to figure out a "business process" to do this. As far as I know, Microsoft has a single employee involved who has laughed off any security concerns with "well the automated malware scanner would find it".

The "community contributors" were just... people active on GitHub when they launched it. Was anyone vetted in any way? No.

The Microsoft Store has actual app reviewers, winget has... "eh, lgtm".

Re: Microsoft Edit

#34
post #6
post #4

Earlier quoted context omitted.

That may be the written goal, but I doubt that's the actual reason the project exists.

Yeah ... I don't think there's any overlap between "users largely unfamiliar with terminals" who want something easy to use, and 'Linux users who are sufficiently technical that they would even hear about this repo'.

Here's a scenario. You're running a cluster, and your users are biologists producing large datasets. They need to run some very specific command line software to assemble genomes. They need to edit SLURM scripts over SSH. This is all far outside their comfort zone. You need to point them at a text editor, which one do you choose?

I've met biologists who enjoy the challenge of vim, but they are rare. nano does the job, but it's fugly. micro is a bit better, and my current recommendation. They are not perfect experiences out of the box. If Microsoft can make that out of the box experience better, something they are very good at, then more power to them. If you don't like Microsoft, make something similar.

Re: Microsoft Edit

#35
post #30

Earlier quoted context omitted.

I am curious about how you made money with it, if you don't mind sharing.

My first company out of uni was a company that sold a tv advertising application written in dos. It did all the reports, put together spot advert packages, measuring reach and frequency, cost per point, etc. Used Neilsen ratings for data. The company at the time paid commissions along with salary to programmers. The app still lives on in windows, but I've been out of that game for decades. Written in TP for dos, then…

Honestly dude, this is clever. Good on you for finding an opportunity to make a useful tool and you made out like a bandit in the process. :)

Re: Microsoft Edit

#36
I don't understand why they want to go with DLLs for scripting instead of WASM + wamr which is really small. Maybe I'm just really inexperienced in this space.

Re: Microsoft Edit

#37
post #10

Earlier quoted context omitted.

It's for people that want to use the Windows Terminal to edit files. The old `edit` command has been unsupported on Windows since 2006, so there was no Microsoft-provided editor that could be used in the command line since then. It's impressive to see how fast this editor is. https://github.com/microsoft/edit/pull/408 > By writing SIMD routines specific to newline seeking, we can bump that up [to 125GB/s]

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?

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.

Re: Microsoft Edit

#40
post #10

Earlier quoted context omitted.

It's for people that want to use the Windows Terminal to edit files. The old `edit` command has been unsupported on Windows since 2006, so there was no Microsoft-provided editor that could be used in the command line since then. It's impressive to see how fast this editor is. https://github.com/microsoft/edit/pull/408 > By writing SIMD routines specific to newline seeking, we can bump that up [to 125GB/s]

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?

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.

Post reply on HN