_ Alternatives

Similar projects and alternatives to _

lodash

187 58,843 5.1 JavaScript _ VS lodash

A modern JavaScript utility library delivering modularity, performance, & extras.
InfluxDB

www.influxdata.com sponsored

Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better _ alternative or higher similarity.

Suggest an alternative to _

_ reviews and mentions

Posts with mentions or reviews of _. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-12-16.

Unix philosophy without left-pad, Part 2 - Minimizing dependencies with a utilities package
3 projects | /r/ProgrammingLanguages | 16 Dec 2021

Your post (and library) seem to imply that micropackages are good if they are useful (in an absolute sense), so long as they don't create excessively large dependency trees. I would argue instead that every package should be treated to a cost/benefit analysis, and it's often better to not use useful packages at all when the benefit is small. As a concrete example, your Recursion module appears to be about 20 lines of code whose value proposition is that you can now type &_ instead of &?ROUTINE (or Dbg lets you type foo(dbg($x)) instead of dd($x); foo($x)). This is (arguably) a useful thing to have, but using even this very tiny micropackage comes with costs. The first cost is that there are now 20 extra lines of external code you must trust to be bug-free, performant, maintained, and non-malicious, but there is also a cost that whoever is reading your code now has to know what &_ means, or where to look to find the answer.
Unix philosophy without left-pad, Part 2 - Minimizing dependencies with a utilities package - Daniel Sockwell
1 project | /r/rakulang | 12 Dec 2021

After that, I agree that there should be some way to mark some sub-packages as v0.*, but I'm not quite sure what the best way to do so is. I've jotted down some initial thoughts at github/codesections/_/issues/3 and would be interested in any thoughts that you (or others) might have (warning: very rough!). I don't currently have anything in there about API numbers – I like that idea, but I'm not sure where they fit.