Building existing tools in a language you are learning has been a thing forever. I would argue it's one of the best ways to learn a language in fact. The README also compares it to existing tools and explains why it's different from them.
That trend is usually limited to a TodoMVC level of effort. It's not usually about reinventing wheels (or worse). Except in the Rust case, where it almost always is.
That’s a lot of negativity just for someone experimenting with a unique programming language to see what it’s good and bad at. People see a new tool and try to figure out what it excels at and what it falls short at. Rust tends to be an “everything” language and people try to uncover new patterns and techniques.
“How much faster/leaner/more user friendly can I make X when I don’t have to care about safety, performance, or package management?”
They shipped their hobby project into Homebrew's core tap. 'brew install ox' belongs to them. They've put it out in the world for others to use and have also stated their case for why people should.
This is far above the level of scrutiny of just someone's experiments.
I have a hobby project that is a feature-complete scratch
rewrite of Ruby's ActiveRecord, but I'd be kind of an arsehole if I named that something and uploaded it to rubygems.
I think that the author had the audacity to imply that his project is grater or equal to many people's favorite tools. Add this to the rewrite it in rust meme and people feel entitled to pummel the author to the ground. I call it the righteousness fallacy where the fact that the other side is wrong give oneself permission to be as ugly as it feels good because if the other is wrong, then one can't be anything but right.
I really only had issue with the fact that they decided their hobby project was ready to be shipped using mainstream package managers.
Most of the pummeling is me just defending this viewpoint after getting pummeled for my negativity.
Nothing should be immune from criticism, and something really can't be a "hobby project" and distributed with mainstream package management tools at the same time. You have to pick one. Names are finite.
If this was a "clone my github" only distribution, I'd have kept my mouth completely shut.
I actually didn't have anybody in mind when commenting but the general direction of the discussion. As far as I get your main issue is the name squatting which is okay. Good names are hard to get and this is something that all packet managers should take into account. However, please, don't be too harsh on someone who wants a nice name for their project.
I agree with you. It's so much engaging way to explore a language and try implementing those features we really wanted. Just saying building in Rust is the new fad. I only hope in these projects people take take a little more risk in trying out ideas.
> Ox took the idea for the customization and extensibility of Emacs and made a configuration system where you can change the colours and appearance of the editor.
Thanks but no thanks. Almost all editors let you customize the color and appearance. Few allow you to customize to such a deep extent as Emacs.
They also ignored the modes and composability of Vi.
Chalk up another mark on the board of unserious things the Rust community does with its time.
Edit: I'm sure this will be an unpopular, downvoted comment. I just want to say that I think that Rust is a fantastic language with an enthusiastic community. It's just a community that repeatedly demonstrates that it doesn't know what "good" looks like and has the world's worst case of NIH. Something about the community attracts the like minded.
Well, if these weren't the results that the community produces over and over and over and over again. Look up any of the long list of "X in Rust" Show HN posts that there have been.
It's kind of a meme at this point.[0,1,2]
It's going to start effecting interviews. I'm saying this as a hiring manager who has to evaluate what projects candidates spend their time on and what they are going to be like to work with. People who oversell their work or don't know how to evaluate value go into the hard pass pile.
And no, I'm not shitting on them for having a hobby project. I'm shitting on them for clearly demonstrating that they don't understand what the very mainstream software they're actively trying to compete with does.
It's no longer a hobby project when you have the most prominent section of your README comparing your project to a bunch of other mainstream software and you're arguing for why people should use your project over those.
It's not a hobby project when you've shipped your Brew into Core and reserved a name.
At that point, we get to make the apples to apples comparisons.
Props to the Arch community for having the good sense to keep this in the AUR.
Are you implying that if you make an effort to share and promote your work to others, it becomes a free-for-all where criticism with any tone whatsoever is alright? If not, what is your point in arguing whether it's a hobby project?
There are people who take an effort to produce something and then take the extra step to show it to others so they might learn or collaborate. And those people often get comments where their project is being picked apart with a fine-toothed comb, packaged in an abrasive tone.
This happens over and over again in IT. There's plenty of people with insecurities who - for reasons that psychiatrists understand better than me - rejoice in taking others down.
Lots of people would say it's because we are hidden to each other behind the screen and would never say this stuff to a colleague. I guess that's part of the reason why it's so prevalent in HN. Though, I've seen the same style of rhetoric in the industry, face-to-face.
"You should go to back to school before talking about CSS" and plenty of laughing was something directed at me when I suggested that the ´class´ attribute for HTML tags has semantic meaning beyond just hooking up CSS rules to it. I had trouble explaining it, but my colleague with longer industry experience took it as "lol this noob junior programmer doesn't even understand what ´class´ means". He didn't even stop to consider how class attributes can be used through Javascript and beyond, he immediately went for taking me down as fast as possible.
And that f'ing hurt. And after that I have probably been toxic to other people too. I wish I could go back and undo all the times I have hurt someone like that. Totally unnecessarily and without reason. But I can't. That's why the least I can do when someone suggests that "hey, tone it down a bit" is to shut up with the explanations why I am right to say what I'm saying and think whether there's a more constructive way to go forward.
Rust deserves negativity, though, just for balance’s sake.
Nevertheless, this project is somebody learning Rust on an intermediate/advanced level. Nothing wrong with that, and people deriding it because it cannot compete with real text editors with millions of man-hours behind them are behaving bit silly. Who knows, one of these exercises might become a great editor some day.
I never expected it to compete with real editors. I'm just disappointed by the flippant and very dismissive "comparison" section, which manages to perfectly miss what makes each editor so popular. asciimov's comment sums it up.
I've also seen (elsewhere) "inspired by emacs ... it has emacs keybindings".
One of the advantages of emacs is that an insane level of customisation is possible. Or, more practically, the high level of customisation allows for a lot of low-hanging fruit for people to create editor macros that suit their usage.
> "inspired by emacs ... it has emacs keybindings"
Lol, incidentally macOS native text fields / text views support a bunch of Emacs keybindings out of box (C-f, C-b, C-n, C-p, C-a, C-e, C-k, C-d off the top of my mind), so any native Mac application with any text input can claim “inspired by Emacs” for free.
that's likely a side-effect of emacs bindings being the readline default in Bash more than anything. (set -o emacs)
What will be interesting to see is if this changes now that zsh (which does not use readline) has become the standard...but alas, if you don't have EDITOR or VISUAL set, emacs is the default there too...
As for those curious, emacs is the readline default because readline is part of the GNU project.
What are you talking about? I’m talking about Cocoa NSTextField, NSTextView etc., got nothing to with libreadline or bash, unless there’s a history lesson here you’d like to share.
Edit: Your comment was expanded as I was replying / after I replied. From which it’s quite clear you didn’t get my point.
Oh I get it, I think you're just underestimating how much effort Apple's developers put into system-wide consistent behaviors in macOS. And also how picky developers are about keyboard first and changing keybindings.
They decided to use emacs bindings because emacs bindings are the system default for macOS programmers.
Apple's developers were also macOS's first users and they started with a terminal long before they had a working UI.
Reread your comment. I misunderstood the first time round. You presented a theory that Apple implemented Emacs keybindings for Cocoa text input widgets not because of Emacs per se, but rather, mainly for consistency with bash. It's an interesting theory, but without a history lesson backed up by sources it's still a theory.
For the record I don't underestimate how much effort Apple puts into system-wide consistent behaviors in macOS. <s>Also, zsh's default keybinding mode is Emacs mode.</s> (Of course, you did mention that.)
Technically, that was systemwide inconsistent behavior.
Readline compatible keystrokes came from nextstep (sorry, I don’t dare to guess how to capitalize that). Traditional Mac OS used completely different key combinations (command left arrow instead of control-a, for example). Because of that, Carbon apps didn’t support readline-like key combinations (but system input fields did)
The two could happily coexist only because the Mac originally didn’t have control keys (it only got them for supporting terminal programs, as part of trying to make Macs sell better in business), so none of its navigation keystrokes used the control key.
I recently showed an OSX based colleague some bash key bindings. He was amazed that I knew these, even more when I replied emacs has the very same key bindings.
Exactly. You can even add some more on your own. Just add the file ~/Library/KeyBindings/DefaultKeyBinding.dict and fill in. I added M-f and M-b but you can add more to make the experience even more Emacs-like.
basically this is what stood out to me. that and mentioning Vim modes and saying, "but not this!"
still, I don't like to be harsh. there is a difference between treating this as a serious alternative to a Vim or Emacs (or whatever) and a programmer resume piece. I could see it being quite fun to develop my own editor as a toy project.
Yeah, they missed what makes Emacs so customizable: its architecture.
What makes Emacs great is that the low-level text editor features are implemented in a compiled language and then exposed to an interpreted language to be composed into the actual editor.
If they're not splitting the architecture into a compiled part and an interpreted part, they aren't taking anything from Emacs.
The compiled/interpreted architecture is only important because Emacs is written in C and Elisp isn't incrementally compiled to native code.
If Emacs was written in Lisp (like Zmacs), then it would have the same flexibility it currently has without having to contain an interpreter of any kind, and the user-written customizations would have the benefit of being compiled to optimized native code. Some things that you can't do in Elisp for performance reasons would be perfectly doable in a Common Lisp version of Emacs.
To me it sounds like it’s been written in a humorous spirit. That, and things like “You can use the keys Backspace and Return / Enter as well as all the characters on your keyboard to edit files!”
The readme is confusing: it says it wants to take the best of all text editors, calling out Vim first (note that the editors are not listed alphabetically), and specifically mentioning modal editing. But the rest of the readme looks like vanilla `PageUp` and `Ctrl+C` instead of `GG` and `yy` to me. So...is it modal or not?
"Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed, however it takes the idea of being a keyboard-only editor and being able to act just like an IDE after some configuration."
> Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed, however it takes the idea of being a keyboard-only editor and being able to act just like an IDE after some configuration.
Modal refers to Vim's insert and normal [and visual, etc] modes, where [almost] anything typed in insert mode is entered into the buffer, and you can [sorta] only navigate and manipulate the text from normal mode. The command examples you quote don't really have any bearing on modality.
PageUp/PageDown key binding is strange. I'd go to a natural one instead (the keys are named for a reason) and bind top / bottom of the document to Ctrl + PageUp / Ctrl + PageDown.
I feel like in 2020, readme with screenshots don't cut it for me anymore . I need a youtube video of someone going through in couple minutes to get me interested.
Editor looks pretty cool, but I really admire how optimized the headline is for reaching the top of the front page. I mean, it's practically an HN bingo card in a single line: Text editor! Rust! Terminal! Fast! All that's missing is "minimalist" and "respects your privacy".
I'm slowly putting together a library and series of blog posts for really showing this, so stay tuned (one measurement often isn't enough).
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)
Python compared to raw assembly development is slow as hell in computationally heavy scenarios.
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.
Running subjective benchmark now. Generated 1G text file. Vim and nano after some delay are showing things on screen, ox is still thinking. 5 minutes and counting...
base64 /dev/urandom | head -c 1000000000 > file.txt
Yeah but that's not a realistic usecase for most users/developers. I haven't measured if Ox is faster or slower, but for me startup time and ability to quickly open files under 10MB are more important.
But for 10MB range do you even feel the delay for any of text editors? For me it feels instant whatever (terminal based) editor i'm using. And what does it even mean "fast" in this case. They all are definitely faster than me typing.
I noticed some years ago that vim can be much slower due to highlighting of particular syntax of huge files. For example it was fine with a 10MiB C file, but super slow with a 10MiB XML file, but fast again with ":syntax off"
Huh, thanks, I didn't know you could put the contents on stdin like that (%!) - just in case you (or anyone) was similarly unaware in reverse, you can also put `%` wherever you want to use the filename in the command.
i.e. I would have done:
:! jq %
and have probably been guilty of (not knowing `%!` per above):
I frequently open minified CSS/JS by accident. IntelliJ's project search window includes a small preview of each result when you hover it, so when you navigate through the results your might pass through a minified file and get your IDE to hang for a couple of minutes :)
> Yeah but that's not a realistic usecase for most users/developers.
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.
One thing about this particular benchmark is that the file it produces is a little bit unusual even for large text files, because it is only contains one (massive) line. Most huge text files you open in text editors are things like multi-gigabyte logs and database dumps, which are composed of many relatively short lines. Text editors often bake that assumption into their data structures. A more representative test would probably be to use hexdump instead of base64 there.
Though 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.
> the file it produces is a little bit unusual even for large text files, because it is only contains one (massive) line.
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.
Yes, true enough, it does happen occasionally, but it's pretty rare (and usually there are other ways to deal with it: using less or similar tools, or just running your massive single-line JSON thing through jq first). And my point was exactly what you're saying: many text editors choke on files like this, so it's not such a huge indictment of ox that it chokes on it as well.
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.
> and usually there are other ways to deal with it: using less or similar tools, or just running your massive single-line JSON thing through jq first
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.
Whether there's a wrapping feature depends on the implementation. coreutils base64, yes. Other implementations, maybe not. macOS's /usr/bin/base64 for instance doesn't have the concept of wrapping. FreeBSD base64, judging from the manpage, doesn't do that either. https://www.freebsd.org/cgi/man.cgi?query=base64
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.
As an emacs user, one of the things I really wish it had was robust support for arbitrary file sizes and shapes.
(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!
emacs -q or -Q is often quite fast. It's things like syntax highlighting, word wrapping, etc. which modes add which usually slow it down. Anything trying to run regexes over the buffer isn't going to scale well.
I think long lines are (were? [1] seems to be a new feature) a well known problem in emacs even without a custom config. There have been ways to work around this for awhile I think, but as far as I know emacs -Q isn't one of them.
oh that's neat, i didn't know about that! could help.
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.
This is not an excuse for an editor being claimed "fast". Textadept is written in C and is also very fast but has the exact same issue -- choking on huge files when Vim and others are able to handle it.
If it's over 1 GB and single line you're almost always going to exit the editor, run some scripts on it, and open it again when it's correctly formatted.
Sure. I'd not be able to actually do anything useful with a gigabyte single-line file so what I'd want my editor to do is say "Longest line is over 100k characters, truncating display to the first 100k".
issue is that the editor can't tell if it's a multiline file with a first big line or an editor with one big line if it's cut at the first line. But I'd rather have the editor bail at the first 100k line than not opening it.
I wonder: Couldn't we have some kind of simulated line breaks, which an editor places virtually, so that it can manage very long lines easily and efficiently internally, while writing out the file without these virtual line breaks? Basically only so make the conditions appropriate for the editor's string data structure?
Direct to X can be much faster, as there is no middle man.
And can have better keyboard (and mouse) support which in terminals is pretty poor.
This is why vi(m) is best for terminals, because it's keyboard shortcuts are adapted for that (except typical 1 second delay on escape key).
Yeah! I think Rust is mature enough now that this isn't necessary from a novelty perspective. And it's not really an obscure language. "In Haskell" for eg is still warranted because it's obscure and uncommon, but I don't think this fits Rust.
For an even catchier headline, it should be prefaced with: "How I built a..."
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.
I'd add "alternative to popular software" to that list as well. People love to find alternatives that are supposedly better and not from big corporations.
Am I the only one who feels _less_ inclined to use a program if they use 'written in rust' as a selling point?
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.
I mean, it tells you that if you wanted to contribute, you'd also have to learn Rust before being able to do so.
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 agree with the other poster that it doesn't add anything to the title. I'm not "upset" about it, this is simply a side discussion about what goes in a title. I wanted to add my thoughts and now I'm done.
If I see that something is written in Rust, I'm predisposed positively because I know it'll be a single binary I can easily install, it'll be fast and it'll usually be well-designed (Rust and good cli design correlate, for some reason).
I’ve recently started syncing these single binaries along with zsh dotfiles using them to all the machines I use with syncthing and have been extremely happy with the result. Just had to set PATH=$HOME/Sync/$(uname)/$(uname -m):$PATH and haven’t been without a tool since.
Similar for Go for me. I personally like Go and will go out of my way to use tools written in it because I understand the tooling and the language well enough that building from source is painless.
Agree wholeheartedly. Just yesterday I saw what looked like a very useful tool whose install instructions were "npm install -g <thing>" and I felt a little pang of "ugh" but went ahead and did it anyway. Never got the thing running but did get a nice error message that said "Electron failed to install correctly, please delete node_modules/electron and try installing again." I actually said out loud, "why the hell does this tool use electron?!" and gave up.
When I’m looking for a new open source application, for various reasons of experience and preferences about what I work with, I often look for and prefer relatively new projects in compiled, statically typed languages that are reasonably active and mature codebases.
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.
If it's open source, the audience isn't just end users, it's also programmers. They might be interested in looking at the code, reusing it in some way, or even contributing to the project.
It seems cyclical. There was a time when it was "written in Go" that was on the bingo card. I remember this being an original hype point for docker, for instance.
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.
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.
As far as I can tell, this is basically a toy project to show off the programmer's skills and practice doing something in Rust. It's also probably something that was fun to do and the programmer would probably like to show it off.
Treating it as some kind of alternative to Emacs or Vim is probably missing the point.
Agreed. This should probably be under ShowHN. I was expecting to see an semi-finished product here. And even the first sentence of the "About The Project" section states:
> Ox is a text editor with IDE-like features.
And then we had the actual feature list, current version seems to be 0.2.5.
> Auto indentation (0.3.0)
> Auto brackets (0.3.1)
> Auto complete (0.3.2)
Which are quite essential for calling something "IDE like".
Other than that. It looks nice. I've seen people calling it an Nano replacement in the comments here, which seems to be missing the big point of nano - it's easily available in a lot of *nix systems by default.
The editor feature list sound definitely promising and certainely has appeal.
I've tried micro, psi but they're not in a state I can use them daily.
What i'd love is basically sublime text in a terminal. I tried ox, but it's currently a bit buggy and non intuitive (no help that I could find, no backspace, cursor on the wrong line..)
Nothing wrong with this, it's a work in progress and early in its development. It shows great promise and I'll definitely check back in the future !
These days I'm working on log files sized around 300mb. Vim is slow and some times stop responding. Geany edior works most of the time. Do you guys have any recommendations?
I haven't used this but watched a talk from the author about how it can load huge files really quickly and can even edit while saving. Sounds pretty god tier in terms of performance:
I've edited 1GB sql dump files in Vim with no problem. I had to turn off my vimrc for it to work, but 300MB should be no problem as long as you are using barebones vim.
For performant buffer-wide operations (:g, :%s), I had success with using vim like an improved sed by passing in commands directly via the command line. That was noticeably faster than opening vim up and running the commands before exiting e.g.
# join together lines delimited by LF into one line, then convert all CRLF into LF
vim -Es \
-c 'g/[^^M]$/.,/^M$/join' \
-c ':%s/^M$//g' \
-c 'wq'
> Nano is an editor that is very simple to grasp due to its intuitive key bindings such as “Ctrl+S” to save and “Ctrl+?” for the help menu etc.
I don't think that's describing nano or pico, at least, no version I've ever used had those keys doing useful stuff. Maybe this is supposed to reference some other editor?
It's only intuitive to people who grew up with PC-style keybindings as well—the editor does not appear to bind super-s despite this being the other obvious keybinding.
One of the selling points for Vim and Emacs is that they are pretty impressive at raw text editing, having "simple, intuitive" keybindings like nano seems to go against this goal?
Eh... what turns me off is that list of features and other editors that just names off other editors as inspiration. Don't even mention other editors unless you are fully copying their features.
Imagine a car being advertised in a similar style called Imacar.
Ferrari, know for its Italian design and sleek lines, Imacar takes those famous design cues by including wheels and tires.
Toyota, known for it's rugged truck's like the Hilux. Inspired by that ruggedness and repairability the Imacar includes easy change windshield wipers.
Tesla, know for their famous electric motors and batteries, inspired us to add a battery to Imacar's petrofuled engine.
I think comparison list with other editors gives good introduction about what to expect from ox, For any terminal text editor comparison with vim, emacs is inevitable. It is good to know authors opinions.
For sure. Also the author is probably going to get bombarded by people referencing their favorite editors. This may help them get out in front of that scene...
Comparison is fair. What's presented there isn't exactly a comparison, though. It claims to "take features from some of the most popular editors out there, gaining the best of all worlds", then proceed to list features that are decidedly not the best, nor even differentiating:
- Vim: they took away "being a keyboard-only editor" (every CLI/TUI text editor?) and "being able to act just like an IDE after some configuration" (most programmer text editors?). Also, "being a keyboard-only editor" isn't even accurate for vim, it totally supports mouse input even in a terminal: https://vim.fandom.com/wiki/Using_the_mouse_for_Vim_in_an_xt...
- Emacs: they took away "a configuration system where you can change the colours and appearance of the editor"... This is adequately discussed elsewhere in the thread.
Therefore, gp's analogy of taking away wheels and tires from Ferrari is apt.
Who argued whether it’s impressive or not? People are not impressed with the rather pointless “we take the best features out of popular editors” section of README that neither adds to nor detracts from the editor itself, and only unnecessarily antagonizes people by mischaracterizing other editors.
You can build an impressive car without pointlessly referencing Ferrari.
Why not? Your car dealer will happily compare and contrast the different models too.
It is perfectly fine and valid to explain how the "new" thing fits into the crowded landscape of similar offerings. Especially when the reader is likely to be familiar with many of the "landmarks". Using other products as a point(s) of reference is very useful.
Agreed, I thought it was amusing that there's a comment saying, "wow this headline is perfect for HN" and yet so much negative talk in the other comments.
I guess this happens as you approach a really specialized set of features and aesthetic--it activates some kind of nitpick psychology, where people who are proud of their specialization are able to demonstrate their unique ability to perceive just what makes a thing in this domain really special. Well, they spend a lot of time working with these interfaces and thinking about it, so it makes some sense--the thought-energy needs to be expressed.
Anyway IDK if one can easily demonstrate that kind of deep specialist insight and also pay attention to how it makes them sound in relation to the author and the author's gift to the world. It's easy to get caught up in what your own perception is offering the world, and kind of steal the stage with what is likely to be perceived as a weirdly negative energy.
> Agreed, I thought it was amusing that there's a comment saying, "wow this headline is perfect for HN" and yet so much negative talk in the other comments.
Well, the headline is perfect for grabbing HN's attention, and the comparison section is perfect for making HN angry, so that's only to be expected.
Because the readme says this: "What features does Ox have and why should I use it?".
Instead it should say: "This is a toy project of me. Learning about text editors. It got pretty far and is really usable. Give it a try."
Also there are zillion articles about "rewrite software x in rust because it's written in evil unsafe C".
The author doesn't say this but i instantly think about it if someone tries to write a better vim.
I think much of the hate is because the thread title wasn't prefixed with a "Show HN" to indicate a pet project. Instead it's read as a possible contender in the editor space. Combine that with the somewhat naive, selly text in the readme and you got a nice negativity storm brewing.
It's a really impressive feat to accomplish something like this, and it's sad that it gets framed unfairly. I just hope it doesn't deter the creator. Maybe in the future it could indeed be a serious option for people that want something between nano and vsc.
This is a pretty looking editor! PageUp and PageDown going to the start and the end of the document is questionable! Typically we use ctrl+home and ctrl+end for that. PageUp and PageDown should go a page up or down respectively.
My suggestion: scrap the entire section which compares Ox to other editors. Replace it with something which pitches Ox to people who use text editors and might want to use yours.
I came away from the compare-and-contrast part confused and nonplussed.
It's also perfectly alright to say "I wanted to write a text editor in Rust, so here it is! I like it and use it, you might too".
Yeah. The section that compares it to Vim seems to misunderstand that people actually _like_ the modal nature of Vim, and that it's one of its main advantages.
Also, when I think of minimal I think of nano or ed (I have not used ed but it still comes to mind). Vim is pretty complex out of the box if you think about it, and that’s what enables the tons of plugins that you get.
I can guess why this is. You're probably fighting it instead of embracing it, or perhaps have unrealistic expectations for yourself. Embrace it, and understand it's OK to not know every single thing. I doubt that's even possible for an average user.
But there are also a lot of people who _don't_ like the modal nature of Vim too. Ox not being modal is then one of its main advantages over Vim in that case.
Looks cool from a distance, and looks more user friendly than most! However any modern editor which doesn't support multiple cursors (be it terminal or gui) is missing the start line of the race these days.
Sure you can, but you have to use a trick. You can fake it by modifying the background color of the cell where the cursor is located. Many terminal editors have support for multiple cursors.
Yeah that's a drawback -- multi-cursors will be displayed as blocks regardless. As far as I know there is no way to solve that, but using block cursors for multi-cursor operations isn't that bad.
maybe I'm missing fonts, but rather than the icons at the bottom (a new document icon, a rust icon, 5 horizontal lines icon ...) I see Japanese characters. As a test I also opened a sh file and it was unable to color the syntax. Hopefully this continues development, but right now it doesn't look ready
Perhaps a tangent: I wonder about the true utility and longevity of a project that advertises itself foremost based on the language it is written in, when that should never matter to the consumer. It comes across as a hobby project or a portfolio entry or a tech demonstrator. If it was intended as such: kudos! That is quite an achievement.
This editor seems lovely, it has very interesting features and it looks nice.
Yet, I hate the punchline "A Rust powered editor". Why should anybody care? Other text editors are never presented according to the language they are written in! For one, I'm getting a bit tired of this obsession with Rust, as if being written in a particular language was somehow an interesting feature.
Binaries written in Rust or Go tend not to require external libraries and tend to be a little more cross-platform than average, it seems. I tend to like things written in Rust or Go.
349 comments
[ 4.5 ms ] story [ 340 ms ] thread“How much faster/leaner/more user friendly can I make X when I don’t have to care about safety, performance, or package management?”
This is far above the level of scrutiny of just someone's experiments.
I have a hobby project that is a feature-complete scratch rewrite of Ruby's ActiveRecord, but I'd be kind of an arsehole if I named that something and uploaded it to rubygems.
Most of the pummeling is me just defending this viewpoint after getting pummeled for my negativity.
Nothing should be immune from criticism, and something really can't be a "hobby project" and distributed with mainstream package management tools at the same time. You have to pick one. Names are finite.
If this was a "clone my github" only distribution, I'd have kept my mouth completely shut.
[0]: https://github.com/hlissner/doom-emacs
Thanks but no thanks. Almost all editors let you customize the color and appearance. Few allow you to customize to such a deep extent as Emacs.
Really?
Chalk up another mark on the board of unserious things the Rust community does with its time.
Edit: I'm sure this will be an unpopular, downvoted comment. I just want to say that I think that Rust is a fantastic language with an enthusiastic community. It's just a community that repeatedly demonstrates that it doesn't know what "good" looks like and has the world's worst case of NIH. Something about the community attracts the like minded.
It's kind of a meme at this point.[0,1,2]
It's going to start effecting interviews. I'm saying this as a hiring manager who has to evaluate what projects candidates spend their time on and what they are going to be like to work with. People who oversell their work or don't know how to evaluate value go into the hard pass pile.
And no, I'm not shitting on them for having a hobby project. I'm shitting on them for clearly demonstrating that they don't understand what the very mainstream software they're actively trying to compete with does.
[0]:https://transitiontech.ca/random/RIIR [1]:http://adventures.michaelfbryan.com/posts/how-not-to-riir/ [2]:https://news.ycombinator.com/item?id=21334510 (which is just the comments here from [1], but also interesting.
It's not a hobby project when you've shipped your Brew into Core and reserved a name.
At that point, we get to make the apples to apples comparisons.
Props to the Arch community for having the good sense to keep this in the AUR.
There are people who take an effort to produce something and then take the extra step to show it to others so they might learn or collaborate. And those people often get comments where their project is being picked apart with a fine-toothed comb, packaged in an abrasive tone.
This happens over and over again in IT. There's plenty of people with insecurities who - for reasons that psychiatrists understand better than me - rejoice in taking others down.
Lots of people would say it's because we are hidden to each other behind the screen and would never say this stuff to a colleague. I guess that's part of the reason why it's so prevalent in HN. Though, I've seen the same style of rhetoric in the industry, face-to-face.
"You should go to back to school before talking about CSS" and plenty of laughing was something directed at me when I suggested that the ´class´ attribute for HTML tags has semantic meaning beyond just hooking up CSS rules to it. I had trouble explaining it, but my colleague with longer industry experience took it as "lol this noob junior programmer doesn't even understand what ´class´ means". He didn't even stop to consider how class attributes can be used through Javascript and beyond, he immediately went for taking me down as fast as possible.
And that f'ing hurt. And after that I have probably been toxic to other people too. I wish I could go back and undo all the times I have hurt someone like that. Totally unnecessarily and without reason. But I can't. That's why the least I can do when someone suggests that "hey, tone it down a bit" is to shut up with the explanations why I am right to say what I'm saying and think whether there's a more constructive way to go forward.
Nevertheless, this project is somebody learning Rust on an intermediate/advanced level. Nothing wrong with that, and people deriding it because it cannot compete with real text editors with millions of man-hours behind them are behaving bit silly. Who knows, one of these exercises might become a great editor some day.
https://news.ycombinator.com/item?id=24976470
https://github.com/BurntSushi/ripgrep
One of the advantages of emacs is that an insane level of customisation is possible. Or, more practically, the high level of customisation allows for a lot of low-hanging fruit for people to create editor macros that suit their usage.
Lol, incidentally macOS native text fields / text views support a bunch of Emacs keybindings out of box (C-f, C-b, C-n, C-p, C-a, C-e, C-k, C-d off the top of my mind), so any native Mac application with any text input can claim “inspired by Emacs” for free.
What will be interesting to see is if this changes now that zsh (which does not use readline) has become the standard...but alas, if you don't have EDITOR or VISUAL set, emacs is the default there too...
As for those curious, emacs is the readline default because readline is part of the GNU project.
Edit: Your comment was expanded as I was replying / after I replied. From which it’s quite clear you didn’t get my point.
They decided to use emacs bindings because emacs bindings are the system default for macOS programmers.
Apple's developers were also macOS's first users and they started with a terminal long before they had a working UI.
For the record I don't underestimate how much effort Apple puts into system-wide consistent behaviors in macOS. <s>Also, zsh's default keybinding mode is Emacs mode.</s> (Of course, you did mention that.)
Readline compatible keystrokes came from nextstep (sorry, I don’t dare to guess how to capitalize that). Traditional Mac OS used completely different key combinations (command left arrow instead of control-a, for example). Because of that, Carbon apps didn’t support readline-like key combinations (but system input fields did)
The two could happily coexist only because the Mac originally didn’t have control keys (it only got them for supporting terminal programs, as part of trying to make Macs sell better in business), so none of its navigation keystrokes used the control key.
still, I don't like to be harsh. there is a difference between treating this as a serious alternative to a Vim or Emacs (or whatever) and a programmer resume piece. I could see it being quite fun to develop my own editor as a toy project.
What makes Emacs great is that the low-level text editor features are implemented in a compiled language and then exposed to an interpreted language to be composed into the actual editor. If they're not splitting the architecture into a compiled part and an interpreted part, they aren't taking anything from Emacs.
If Emacs was written in Lisp (like Zmacs), then it would have the same flexibility it currently has without having to contain an interpreter of any kind, and the user-written customizations would have the benefit of being compiled to optimized native code. Some things that you can't do in Elisp for performance reasons would be perfectly doable in a Common Lisp version of Emacs.
They do, actually. What happens if you type `yy` in a non-modal editor? You get "yy" in your text. It only works in Vim because you're in normal mode.
So c o n fused I(c) am
I think most editors on mainstream Linux distros and also Windows use Ctrl + Home/End for to go to the top/bottom of a document.
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)
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.
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.
ori.e. I would have done:
and have probably been guilty of (not knowing `%!` per above):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.
Though 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.
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.
(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.
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.
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.
Unfortunately it's not automatable.
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^^
\s
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.
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...)
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.
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 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.
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."
Treating it as some kind of alternative to Emacs or Vim is probably missing the point.
> Ox is a text editor with IDE-like features.
And then we had the actual feature list, current version seems to be 0.2.5.
> Auto indentation (0.3.0) > Auto brackets (0.3.1) > Auto complete (0.3.2)
Which are quite essential for calling something "IDE like".
Other than that. It looks nice. I've seen people calling it an Nano replacement in the comments here, which seems to be missing the big point of nano - it's easily available in a lot of *nix systems by default.
I've tried micro, psi but they're not in a state I can use them daily.
What i'd love is basically sublime text in a terminal. I tried ox, but it's currently a bit buggy and non intuitive (no help that I could find, no backspace, cursor on the wrong line..)
Nothing wrong with this, it's a work in progress and early in its development. It shows great promise and I'll definitely check back in the future !
I wish to give you enough money for a coffee and a fancy cookie.
* lnav about 4 seconds to index[1] and display
* vim about a second to display
* emacs about 3 seconds to display
This is on a late 2013 27-inch iMac with a 3.5Ghz i7 and the file cached.
[1] - Indexing in lnav involves parsing all log lines to extract their timestamp and log level (status codes in this case)
https://github.com/arximboldi/ewig
Check out the talks from Juan Pedro Bolivar Puente. They are truly next level imo.
For performant buffer-wide operations (:g, :%s), I had success with using vim like an improved sed by passing in commands directly via the command line. That was noticeably faster than opening vim up and running the commands before exiting e.g.
I don't think that's describing nano or pico, at least, no version I've ever used had those keys doing useful stuff. Maybe this is supposed to reference some other editor?
https://www.nano-editor.org/dist/latest/cheatsheet.html
I'm constantly reflexively reaching for ctrl+s and then correcting myself just at the last second.
Imagine a car being advertised in a similar style called Imacar.
Ferrari, know for its Italian design and sleek lines, Imacar takes those famous design cues by including wheels and tires.
Toyota, known for it's rugged truck's like the Hilux. Inspired by that ruggedness and repairability the Imacar includes easy change windshield wipers.
Tesla, know for their famous electric motors and batteries, inspired us to add a battery to Imacar's petrofuled engine.
It's entirely unclear what niche this editor is aiming for. If it's a replacement for the editors it claims as inspiration it's not going to succeed.
Yes, after reading how the author described vim and emacs, I knew this project was not for me.
It looks like someone has never read the vim manual.
So vim both only provides basic text editing functionality and is harder to use than Ox?
Vim has a special "insert mode" in which the keyboard is repurposed for entering text. I don't think that's a very hard concept to grasp.
- Vim: they took away "being a keyboard-only editor" (every CLI/TUI text editor?) and "being able to act just like an IDE after some configuration" (most programmer text editors?). Also, "being a keyboard-only editor" isn't even accurate for vim, it totally supports mouse input even in a terminal: https://vim.fandom.com/wiki/Using_the_mouse_for_Vim_in_an_xt...
- Emacs: they took away "a configuration system where you can change the colours and appearance of the editor"... This is adequately discussed elsewhere in the thread.
Therefore, gp's analogy of taking away wheels and tires from Ferrari is apt.
I’m not really sure what to think of everyone being so negative here.
You can build an impressive car without pointlessly referencing Ferrari.
Why not? Your car dealer will happily compare and contrast the different models too.
It is perfectly fine and valid to explain how the "new" thing fits into the crowded landscape of similar offerings. Especially when the reader is likely to be familiar with many of the "landmarks". Using other products as a point(s) of reference is very useful.
Pretty impressive what you've put together! I'm sure it's really cool being able an editor to work exactly the way you want it to work.
I guess this happens as you approach a really specialized set of features and aesthetic--it activates some kind of nitpick psychology, where people who are proud of their specialization are able to demonstrate their unique ability to perceive just what makes a thing in this domain really special. Well, they spend a lot of time working with these interfaces and thinking about it, so it makes some sense--the thought-energy needs to be expressed.
Anyway IDK if one can easily demonstrate that kind of deep specialist insight and also pay attention to how it makes them sound in relation to the author and the author's gift to the world. It's easy to get caught up in what your own perception is offering the world, and kind of steal the stage with what is likely to be perceived as a weirdly negative energy.
Well, the headline is perfect for grabbing HN's attention, and the comparison section is perfect for making HN angry, so that's only to be expected.
Instead it should say: "This is a toy project of me. Learning about text editors. It got pretty far and is really usable. Give it a try."
Also there are zillion articles about "rewrite software x in rust because it's written in evil unsafe C". The author doesn't say this but i instantly think about it if someone tries to write a better vim.
It's a really impressive feat to accomplish something like this, and it's sad that it gets framed unfairly. I just hope it doesn't deter the creator. Maybe in the future it could indeed be a serious option for people that want something between nano and vsc.
I came away from the compare-and-contrast part confused and nonplussed.
It's also perfectly alright to say "I wanted to write a text editor in Rust, so here it is! I like it and use it, you might too".
Either way, it is fair to clearly state where the project stands regarding the modal style interaction vis-à-vis Vim.
The vagueness of this statement is great.
Yet, I hate the punchline "A Rust powered editor". Why should anybody care? Other text editors are never presented according to the language they are written in! For one, I'm getting a bit tired of this obsession with Rust, as if being written in a particular language was somehow an interesting feature.
Potential contributors to the project may care.