Live data from Hacker News

Show HN: tere – A Faster Alternative to cd+ls

github.com

131–140 of 206 posts

Re: Show HN: tere – A Faster Alternative to cd+ls

#131

Earlier quoted context omitted.

As long as there's no need to ship standalone binaries without shared libraries.

Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.

Standalone Python apps as binaries tend to be poorly performant, and huge (due to shipping an interpreter, stdlib, deps, etc) in my experience.

Assuming you get it working at all.

Re: Show HN: tere – A Faster Alternative to cd+ls

#133

Earlier quoted context omitted.

`cargo tree` output: tere v1.0.0 ├── clap v3.0.10 │ ├── bitflags v1.3.2 │ ├── indexmap v1.8.0 │ │ └── hashbrown v0.11.2 │ │ [build-dependencies] │ │ └── autocfg v1.1.0 │ ├── os_str_bytes v6.0.0 │ │ └── memchr v2.4.1 │ ├── strsim v0.10.0 │ ├── terminal_size v0.1.17 │ │ └── libc v0.2.126 │ └── textwrap v0.14.2 │ ├── smawk v0.3.1 │ ├── terminal_size v0.1.17 (*) │ ├── unicode-linebreak v0.1.2 │ │ [build-dependencies] │ │…

I don't know much about Rust, but I have a hard time believing python's standard library wouldn't have all the required functionality covered (whether performance would be adequate is different question). I for one, really really like python for its comprehensive standard library.

No, actually. Of the direct dependencies, Python’s standard library has equivalents of regex (re), serde/serde_json (json), clap (argparse) and the boring half of textwrap (textwrap, which is only suitable for ASCII, and possibly curses providing a buggy and incomplete version of Unicode- and column-awareness, but I’m not sure of even that much, and I don’t think it’s properly cross-platform either), and some parts of crossterm (curses, of uncertain availability and reliability). But it completely lacks equivalents of most of crossterm and textwrap, and all of dirs and unicode-segmentation, providing in the latter two cases only functionality pretty much exactly equivalent to what Rust’s standard library contains.

This is the sort of thing that I meant by “doing things properly rather than half-heartedly”. You could make something like this by reimplementing half the libraries in an inferior fashion, full of bugs, cross-platform inconsistencies and missing functionality. Or you can take an extra dependency. Even in Python, the recommendation would be firmly to add dependencies like appdirs for dirs and I dunno what for the rest.

Re: Show HN: tere – A Faster Alternative to cd+ls

#134
Interesting.

OTOH, people have named a number of similar tools, and I'm going to point out 'mc' aka Midnight Commander, which is part of most linux distro's, and is a clone of the 1980's Norton commander. Its designed to be a command line TUI helper, sorta like the project here, with not only cursor/etc based directory navigation but copy/rename/delete/etc functionality just a keystroke away. Its fairly convenient because it overlays the command line rather than replacing it.

Re: Show HN: tere – A Faster Alternative to cd+ls

#135

Earlier quoted context omitted.

But it does matter. If the people actively using the packages aren't complaining, then there isn't really a problem. You've hyperfocused so much on my "criticism of your criticism" and the permissibility behind it that you chose to ignore the actual criticism I laid down. I'm not continuing this either way since I've said my piece. Maybe step back and actually read my comments rather than focusing on me criticizing y…

You probably shouldn't make such inflammatory comments on an account that is directly linked to your professional and personal profiles, it really doesn't look great Also it isn't a criticism of my criticism, it is an assertion that I should not be allowed to criticise at all, which is a totally different thing. Of course I am going to call that out EDIT: I can't reply because rate limited Please calm down. I'm not t…

Oh so you jump to implicitly threatening those you disagree with? Wow. At least you made it clear how open you are to discussion and debate.

I never said you can't criticize. As the other commenter already said, you're allowed to critique but don't be surprised when your criticism is then critiqued itself. That's the epitome of modern discussions and debate.

I gave you examples of what you can do right now, aka making your own alternative packages, but you chose to ignore that all and double down on "don't you dare critique my criticism".

And then (I'm going to point this out again because it's so absurd) vaguely implied my comments would face professional retribution. Because I chose to disagree with you and make that public.

In any case, I said I'm stopping and I am. You should too, as you're already crossing several lines with this comment.

Re: Show HN: tere – A Faster Alternative to cd+ls

#137

Earlier quoted context omitted.

hashbrown, smawk, corasick, parking_lot, itoa, ryu Writing in Rust looks like casting spells in an Infocom game. Gnusto rezrov!

Really? itoa is one of your "magic incantations"? https://en.m.wikibooks.org/wiki/C_Programming/stdlib.h/itoa I get the others, but that ones a pretty standard type converter, the opposite of the C standard atoi

atoi is a classic example of the sort of bad naming C has long been infamous for. It's not a word, it's an initialism, and the common documentation for it doesn't even say what the initialism actually means. It's relatively easy to infer what it means from the description of what it does (ascii to integer), but can easily be incorrectly inferred ([character] array to integer.)

C kind of gets a pass for this stuff because C was old and in the early days they were limited by token size. But to still be using this term today in a new language seems fairly derisible.

Re: Show HN: tere – A Faster Alternative to cd+ls

#138
post #6

curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l 51 How come that such a simple tool has more than half a century of dependencies? This is terrifying.

Cargo.lock is the wrong place to be looking, there really are only 7 direct dependencies, https://github.com/mgunyho/tere/blob/master/Cargo.toml#L14-L... The deps for each of these packages is really out of the authors hands, this is really the same for any programming language though which need to pull in dependencies of their own.

That's true, but OP did ask a question "How come...". Your answer is that the Rust ecosystem is to blame for encouraging micro-dependencies, like Node.js, and not the author. I think that's a pretty reasonable take! But it doesn't mean that there's not a problem.

Re: Show HN: tere – A Faster Alternative to cd+ls

#139

Earlier quoted context omitted.

As long as there's no need to ship standalone binaries without shared libraries.

Indeed, Python would be a good language to implement this in terms of ease of development, but it's very difficult to distribute a standalone binary (which I wanted to do). The built-in curses support of Python is also not cross-platform I think.

It’s a funny thing I’ve noticed about scripting languages: they’re generally easier to get going with yourself, but they’re horrible for distribution/deployment, and if you have to integrate code written in other languages (even C libraries with Python bindings, or similar—things like wxWidgets or GTK), that rapidly escalates to a nightmare. Meanwhile, ahead-of-time compiled languages like Rust and Go are simply a breeze to distribute/deploy.

Re: Show HN: tere – A Faster Alternative to cd+ls

#140
post #6

curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l 51 How come that such a simple tool has more than half a century of dependencies? This is terrifying.

Just wait till the deps go away or change in some significant way.

They cannot be removed without good reason (like “here’s a letter from my lawyer” or “this code secretly exfiltrates credentials”), and a lock file means that even if they change, your usage of them won’t until you ask to upgrade versions.
Post reply on HN