base64 /dev/urandom | head -c 1000000000 > file.txtThough I take the point: if a text editor advertises itself as being "fast", this is the kind of stuff you expect it to handle.
EDIT: ok, so i just tried the hexdump version. Vim and Emacs took a couple of seconds each (Emacs being slightly slower and chunkier when you navigate, Vim handles it without issue and is perfectly repsonsive). less opened it instantly (obviously, it's less!). ox has been going for a few minutes now, nothing happening.
It's not the benchmark's fault, ox is just slow for large files.
XML and JSON without pretty print. Minimized HTML with embedded resources. While not often gigabyte sized those seem to be enough to get most editors to hang and make editing the files a miserable experience.
However, ox clearly performs poorly even when your text files aren't massive single lines, so it doesn't really matter: ox basically can't handle files like this regardless of line distribution.
Older Unixen at least (SVR3-based) had a tool called bfs - big file scanner. Used it some, e.g. when, as a system engineer, I helped IT staff of one of our customers, a university processing exam results of tens of thousands of students from dozens of colleges affiliated to that univ. IIRC, its UI was something like a read-only ed (google "unix bfs command"). You used it to scan really large (for the time) files, e.g. data files (input/output) in large data processing environments, for purposes like checking if the input or output files anecdotally looked okay, no major noticeable garbage in them. Haven't checked if it is present in modern Linuxes. Also don't remember if it could handle large files without newlines. Likely not, if based on ed. Didn't have such files to work on then.
(It'd be fine if not all features worked on these files.)
Sure, most files are reasonably sized and shaped, but sometimes you do find yourself needing to e.g. dig into that single-line 1GB json file to try to debug something, and it's inefficient to have to think, before opening any file, "is more normal tool sufficient for this, or should I use something else?"
There's no fundamental reason we can't have one tool that does it all!
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Lo...
my ideal editor would never block, and use file-sized based approximations to allow scrolling to arbitrary locations w/o having to actually read the contents of the entire. things like syntax highlighting &c would be either strictly time-limited to not drop frames, or done in the background.
Edit: Oops, posted some misinformation. The mistaken part, reproduced below:
> First, wrapping by default only occurs when writing to a tty. When stdout is redirected to a file, wrapping base64 output usually doesn't make sense, so wrapping doesn't happen.
Correction: coreutils base64 wraps regardless of whether stdout is a tty.
Yes it does. "-b N" or "--break=N" inserts a line break every N characters.
$ base64 /dev/urandom | head -c 1000000000 | wc
0 1 1000000000
Most of the time I only realize that everything is on a single line after opening the file.
A good editor doesn't require me to think about these things.
I don't want to chase separate tools that can format different text files, that's what editors are for.
The important thing to realize is that text editor performance is less about the technology used and more about the data structures and i/o.
Personally i see no reason why this is needed (just use vim), but I'm sure a lot of people will use it just because its written in rust^^
Unfortunately it's not automatable.
It also looks like vim and emacs don't decide what a realistic use case is, or if you're "most" users/developers. They just open text files for editing.
Even for large files, I've never noticed anything beyond microsecond-type delays with those. Definitely does not feel laggy to me, usually.
My beloved vim doesn't fair so we'll. VScode does very well on this.
I often find it's much faster to pipe out to a command line program to do formatting on huge files.
e.g.
:%! jq
:%! xmllint --format -i.e. I would have done:
:! jq %
:! cat % | ...I've always wanted to be able to try and verify performance bounds at the CI stage, and I'm hesitantly optimistic it can be done cleanly (although amortized analysis is extremely important, you can actually play "guess the C++ std container from the graph" if you plot the data right)
\s
Development speed of applications in Python compared to raw assembly is nearly infinitely faster, both because it’s easier to write and because the talent pool for ASM is near zero in most cities.
But the same can be said for basically all metrics people use to sell products.
I mean, I very rarely see non-rust projects say "Written in X!" as a selling point for the end user (why would an end user care?), and the campaign to re-write everything in rust is similarly irritating. I've never explored or read up on the rust community, but the sheer insistence that I see jutting into everything from the outside turns me off.
Lots of stuff where X != Rust.
> (why would an end user care?)
They probably don't. But, on GitHub, where programmers go, and on a forum like this, with lots of developers, this means something to many folks here.
Also, beyond that, note my "many"; sure, it doesn't mean anything to you. It feels weird to get upset about something that supposedly has no meaning, though. When I see something that's "written in X" and I don't care about X, I just move on with my day. If I post about how much I don't care about X, it really seems like I do actually care about X, otherwise, I wouldn't take the time to complain about it.
(The OP of this thread said that they did care, negatively. And you didn't explicitly say you don't care either. But this attitude is common and is also elsewhere in this thread so, let me just finally jump off this soapbox real quick...)
I do agree that I'd rather see the technology choice not highlighted so much, though. But it really is a proxy for some things that matter to me: if it is in Rust, I expect it to be a single binary I can easily install and which starts up quickly and performs well (as opposed to, say, javascript, python, ruby, or java programs), but is likely to suffer very few security problems (as opposed to, say, a C or C++ program), and has a decent shot at growing an active community, which I may be able to contribute to. A lot of these things apply to other technologies (like the aforementioned Go) as well, but it I do feel like I get some information by knowing the technology.
Maybe the better approach would be to enumerate benefits rather than saying what the technology is, even if the benefits flow from the technology choice.
That means the solution often ends up being written Go, Rust or C/C++, to the extent that Go and Rust specifically also turn out to be good signalling that the application may meet my other requirements, partly simply because they are relatively new languages. They also seem to signal better thought out and more “serious” solutions, perhaps because of the barrier to entry they present vs interpreted and scripting languages.
So yeah. Rust or other languages certainly aren’t a requirement but they do sometimes present some useful signalling.
Nothing has put me off of Rust more than "Rust people". The same thing happened to me with Python over 20 years ago and I've successfully (and happily) avoided that language for over 20 years because of just how unbelievably, unstoppably "effervescent" Python people were in the late 1990s. If Python were 10% as good as those people said is was, it would be, by a wide margin, mankind's greatest achievement for the next 10 millennia.
I get the exact same vibe from "Rustaceans."
I mean it can have a crappy UI, and not do what you want it to, but at least you won't have a memory leak.
I think for most applications, written in rust shouldn't be a selling point, but things such a cURL can definitely benefit from it
I'd seriously like someone to build a HN scraper that aggregates all the articles prefaced by "How I built a..." and then write an article called "How I built a scraper to aggregate 'How I built a...' articles to assess their HN upvotes." I'd upvote that.