curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l
51
curl https://raw.githubusercontent.com/mgunyho/tere/master/Cargo.lock | grep source | wc -l
51
The answer to your question "How come a simple thing is more complex than I first thought?" is: "Because you've spent less time thinking about it than the author".
Whether this is better or worse seems to be a matter of contention for a lot of people, but it certainly poses a challenge for supply-chain auditing. I suspect for Rust to truly ever replace C++ in its domain, the ecosystem is going to need to come up with something like boost so you can grab one library that does all the things nearly any program wants (regex, serialization, cli opts, etc) but that don't get included in the core language's stdlib.
Yes, but then you are stuck with glibc + kitchen sink and GNU code quality, which is atrocious.
Musl is far superior as a libc, but most Linux software is written for glibc and has quirks that make porting hard.
Nope. It’s better at some things but with so many caveats that this is just dumb to claim.
Anyway, GLibc is just better, both in terms of performance (algorithms are more optimized, at the cost of a bigger executable size) and in terms of available features.
Not only for that. As much as I love copyleft, I'm really happy that musl exists so that I can easily test my programs locally for portability. Compiling stuff with different compilers and libraries exposes at once all sorts of weird bugs before you get to publish your codes.
The comment I replied to is less than 100 characters long plus a command line invocation.
One of these two has spent more time thinking about whether some dependencies are needed.
But you're right that it could always be simpler, in fact I wrote tere originally in C with curses as the only dependency, and it compiles >10x faster. But there I had to manually write some (pretty certainly buggy) unicode handling, and I think adding extra features (proper arg parsing, json for history file etc) would be way more painful.
With rust you just check in your Cargo.lock file to your VCS and then the versions of your dependencies and their dependencies (etc) are pinned, so if it works now then it will always work. For dependencies on crates.io authors don’t even have the option to remove a version once it’s published.
Upgrading dependencies is an explicit operation, so you only do it when required and run your tests afterwards.
In practice I’ve had far fewer issues with dependency versions using rust than I’ve had using dynamic system libraries in the C/C++ ecosystem
As long as the use of dependencies remains reasonable, the number of dependencies does not immediately mean that the code is "bloated".
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.
And unless you're actively developing in Rust, why would some other people's choice of naming their projects in a language and tool chain you don't ever plan on using be such a big deal?
I'm not saying that there should be some kind of totalitarian regime that enforces naming, I'm simply saying that yeah it kinda sucks that Rust devs tend towards cutesy names over ones that convey functionality.
This just seems like you're getting weirdly offended for no reason. Not everything is some kind of attack on individual agency. There is absolutely nothing wrong with me remarking on the state of Rust naming. The fact that you are conflating it to be a "big deal", which I never said it was, just seems like bad faith arguing me. This is just not something to get so offended over.
Are you using Rust? If not, why does it matter what they choose to name their libraries. This is my entire point, you're coming in as an outsider criticizing something that is clearly not a problem to Rust devs.
If actual Rust developers are using them to the point where they're popular enough to gain (unwarranted, imo) criticism, then clearly they're working, silly name and all.
It's almost as if people care more about what the function a package provides rather than its name.
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 your critique.
Also, pot calling the kettle black. You spent an entire comment being offended over my critique.
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 threatening you. I'm simply surprised that you make such inflammatory and aggressive comments on an account that is so closely tied to your professional life, that is all. I think you should reconsider doing so
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.
This is exactly cultish thing about Rust, that unless someone is praising Rust, they are free to keep their mouth shut.
Nobody said that. Of course you can criticize. But be aware that your criticism itself could be subject to criticism.
https://trends.google.com/trends/explore?date=all&geo=US&q=s...
Sure, it could be named serde_framwork and serde_json, but I think serde and serde_json isn't that bad either.
That's what I mean when I say Rust community is toxic here https://news.ycombinator.com/item?id=32105449
For context, I totally agree that rust often ends up with more dependencies than I would like and that crate names are often super unhelpful, but I downvoted the comment.
crossterm = "0.24.0"
dirs = "4.0.0"
regex = "1.5.4"
serde_json = "1.0"
serde = { version = "1.0", features = ["rc"] }
textwrap = "0.14"
unicode-segmentation = "1.7"
I guess one could write their own textwrap and probably also dirs, but other than that they all are probably vital to this tool.
The only reason this wouldn't be a problem in another language would be because that language already includes the functionality of such libraries
[dependencies.clap]
version = "3"
default-features = false
features = ["wrap_help", "suggestions", "std"] 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]
│ │ └── regex v1.5.4
│ │ ├── aho-corasick v0.7.18
│ │ │ └── memchr v2.4.1
│ │ ├── memchr v2.4.1
│ │ └── regex-syntax v0.6.25
│ └── unicode-width v0.1.9
├── crossterm v0.24.0
│ ├── bitflags v1.3.2
│ ├── libc v0.2.126
│ ├── mio v0.8.4
│ │ ├── libc v0.2.126
│ │ └── log v0.4.14
│ │ └── cfg-if v1.0.0
│ ├── parking_lot v0.12.1
│ │ ├── lock_api v0.4.7
│ │ │ └── scopeguard v1.1.0
│ │ │ [build-dependencies]
│ │ │ └── autocfg v1.1.0
│ │ └── parking_lot_core v0.9.3
│ │ ├── cfg-if v1.0.0
│ │ ├── libc v0.2.126
│ │ └── smallvec v1.8.0
│ ├── signal-hook v0.3.13
│ │ ├── libc v0.2.126
│ │ └── signal-hook-registry v1.4.0
│ │ └── libc v0.2.126
│ └── signal-hook-mio v0.2.3
│ ├── libc v0.2.126
│ ├── mio v0.8.4 (*)
│ └── signal-hook v0.3.13 (*)
├── dirs v4.0.0
│ └── dirs-sys v0.3.6
│ └── libc v0.2.126
├── regex v1.5.4 (*)
├── serde v1.0.134
├── serde_json v1.0.75
│ ├── itoa v1.0.1
│ ├── ryu v1.0.9
│ └── serde v1.0.134
├── textwrap v0.14.2 (*)
└── unicode-segmentation v1.8.0
Having over fifty dependencies for something like this is not in any way terrifying—you’re just starting with a different set of expectations and understandings of how things are done. It’s a natural and reasonable outworking of (a) using the right tools for the job, (b) doing things properly rather than half-heartedly (most obviously where terminal interactions are involved), and (c) Rust’s deliberately thin standard library.
Writing in Rust looks like casting spells in an Infocom game.
Gnusto rezrov!
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
Different tools for the same job. One is explicitly integer to string conversion the other is sting formatting.
You can technically use the latter, but some prefer a function which explicitly does one thing and one thing only.
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.
Assuming you get it working at all.
I don't think it's an inherent feature of scripting languages that they are hard to distribute. I'm pretty sure it's possible to package up a tiny Lua interpreter (or e.g. QuickJS) and all necessary scripts into a standalone file.
Reminds me of the idea regularly pushed here that you need a virtualenv even for thirty-line scripts. I read these kind of takes here often and am a bit baffled by them. Maybe it is because developers have lost administrator skills over time, that this feels like an insurmountable challenge?
Don't forget the startup time overhead of first loading a whole interpreter into memory, then loading a python program into the interpreter.
Granted, a few of these things apply to Rust stuff as well (e.g. resources and manifests can’t quite be done out of the box without extra tools), but most of them are inapplicable, and the remainder tend to have better solutions than I observed in Python-land. And a lot of the pain that I’m describing of the Python stuff isn’t that it’s hard to do anything, but more that I’ve found it all just exceptionally error prone and unreliable.
Is that really all that different from Python?
> Because of Python’s conservative nature when it comes to backwards-compatibility, when a module is added to the stdlib its API becomes frozen.
So it sounds like they do do something fairly similar, but just a different mindset on adding libraries
You can do a lot with pythons stdlib, and a lot of popular libraries (requests, for example) largely are just usability wrappers for underlying stdlib stuff.
Whereas with Rust, you have a very minimal std, and things you want to achieve are imported specifically.
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.
I recommend either CBT or writing your own version with fewer dependencies to ease your terror.