PSI is a perfect fit for htop. I sent a PR to add it some time ago (https://github.com/hishamhm/htop/pull/890) but it hasn't been merged yet.

We've been using it for some time as well, not even with a random value, just `X-Entity-Ref-ID: null` works too. Found it through some obscure StackOverflow answer.

React has a built-in useReducer hook now as well: https://reactjs.org/docs/hooks-reference.html#usereducer

I think object-capabilities are one way to have much safer code reuse. Suppose a dependency exports a class UsefulService. In current languages, such a class can do anything - access the filesystem, access the network, etc. Suppose however that the language enforces that such actions can only be done given a reference to e.g. NetworkService, RandomService, TimeService, FilesystemService (with more or less granularity). Therefore if UsefulService is declared with `constructor(RandomService, TimeService)`, I can be sure it doesn't access any files, or hijacks any data to the network - nor do any of its transitive dependencies.

The method of sandboxing using OS processes + namespaces and what not is too heavy and unusable at such granularity.

The method of per-dependency static permission manifests in some meta-language is also poor.

The method of a single IO monad is too coarse. Also using any sort of `unsafe` should not be allowed (or be its own super-capability).

Obviously there are many tricky considerations. [For example, it is anti-modular - if suddenly UsefulService does need filesystem access, it's a breaking change, since it now must take a FilesystemService. But that sounds good to me - it's the point after all.] But does any language try to do this?

One reason I still use git grep is this: I have some minified .js files in the repository, which I don't want to be included in grep results. So I mark the files as binary in gitattributes, then git grep just says "Binary file foo matches".

For ripgrep, you can achieve this via a custom ignore file, e.g., `echo '*.min.js' > .ignore`.

Another approach I've seen people take is to put `-M300` in your ripgrep config file, and then any super long lines are automatically omitted from output.

I've seen the few posts deciding to use .ignore as the file name but I hope this won't be a mistake in choosing the right name without enough discussion. Even for users it's hard to figure what the file is for.

I consider .grepignore to be more comprehensible.

You can also use .rgignore.

Have you considered parsing .gitattributes and offering support for reducing files marked as "binary" down to a "binary file matches" notice?

Nope. I don't think I've ever used .gitattributes. Might be a neat idea. Not sure.

Have you heard of persistence hunting? Here's is a short documentary from the BBC: https://www.youtube.com/watch?v=826HMLoiE_o

It is believed to be one of the oldest hunting techniques, and so would indicate that humans are in fact meant to run long distances. According to Wikepedia, the runner runs for "about two to five hours over 25 to 35 km (16 to 22 mi)".

The fact that the rest of humanity didn't bother with persistence hunting may also be a clue that we weren't designed for that either.

Or it's a clue that we figured out that building a trap or using a weapon to kill an animal from greater distance burns a lot less calories.

For sure. And that's the point. Persistence hunting is a strategy developed by a set of humans living in one small area of the world that isn't particularly hospitable to humans. In fact, give how inhospitable the African Savannah is, it is a point against the idea that this is somehow a 'natural' state of being for us. And it makes sense, this kind of long distance running is incredibly energy intensive and injury prone - it's not a great way to make a living.

It is not as clear cut as you say, there appears to be some scientific discussion on this: https://en.wikipedia.org/wiki/Endurance_running_hypothesis

I think it would be neat if WebAssembly were embedded in other languages, like it is in JavaScript now. For example, suppose Python had a WebAssembly engine. I bet that could replace a lot of C extensions, and it would be as portable/universal as pure Python code, so no need for C compilers, OS-specific binary packages, etc.

The Wasm tool chain is built around llvm. So, you can take some complex C code and target wasm instead of X86, ARM, or whatever. That works right now and you can already do things silly like compile emulators and vms to run in a web browser and get them to boot e.g. windows 95 or linux.

So, you could try to recompile the entire python ecosystem (interpreter, libraries, extensions, etc.) to wasm. This might be tricky right now because not all stuff readily compiles to wasm yet probably or uses gcc instead of llvm. Als, python has its own vm and compiler that would need to be reengineered on top of wasm.

Of course people have been working on moving python to llvm for some time so this might actually become feasible.

I totally agree with what you said. Currently I'm loading compiled C code with the Python foreign function interface (often not (solely) for performance reasons, but because it just so happens that I already have a C library that solves a particular problem). It would be great if I wouldn't have to worry about providing a shared library for all possible target platforms.

In fact, when I searched for a Python WebAssembly interpreter a few weeks ago I stumbled across this project [1]. So rest assured, people are working on this already.

[1] https://github.com/kanaka/warpy

You'll never be as fast as compiled, unless you're thinking this engine would JIT at which point your "no need for C compilers" became "carry around a WASM compiler". The more rational approach might be to transpile into the target lang, but there are two primary reasons for C extensions, performance and/or FFI, and neither is accomplished via the transpile route. If it's the third, less oft-cited reason for C extensions, avoiding rewrite and/or reuse existing C code, then yes it has value.

In such a world we'd still need compilers to compile code _to_ WebAssembly -- it isn't really a great source language to work in.

I think that will happen actually. It would open some some interesting possibilities.

It would certainly make "application level code" more portable (which is still a big win) but some sort of OS specific library still needs to talk to the filesystem, network, etc.

While this would supplant "C for speed" libraries, it wouldn't supplant "C for OS access" libraries. At some point, system code needs to call the OS.

Sure, replace "C" with whatever OS language is appropriate. The situation is still the same: wasm doesn't talk directly to the host interfaces, regardless of it being low-level. You'd still need another FFI layer somewhere to talk to those.

I liked this bit, using the fastest compiler for each primitive:

> ./do tries a list of compilers in compilers/c, keeping the fastest working implementation of each primitive. Before running ./do you can edit compilers/c to adjust compiler options or to try additional compilers.

It is sadly necessary; 30%+ performance regressions from, say, gcc 4 to gcc 6 are not uncommon w/ vector intrinsics.

A dependency for uuid4 is hardly needed:

  crypto = require('crypto');

  function uuid4() {
      const bytes = crypto.randomBytes(16);
      bytes[6] = (bytes[6] & 0x0f) | 0x40;
      bytes[8] = (bytes[8] & 0x3f) | 0x80;
      return bytes.toString('hex').match(/(.{8})(.{4})(.{4})(.{4})(.{12})/).slice(1).join('-');
  }

I mean sure. But I also need to parse UUID. And do other things with it. Even if I didn't need to, I'd still likely use the uuid-1345 crate for it.

Here's the thing: If I import this code in my codebase directly instead of using a library, it suddenly becomes my "responsibility" if it breaks. And when we're talking about a FOSS side-project, I don't have that kind of time. Third-party libraries means I get any improvements and bug-fixes for free. And if it breaks, I get to talk with the original maintainer to figure it out, and we're suddenly two people, with one hopefully knowledgable enough on the topic, working on the problem.

Importing this kind of thing in make codebase makes it an ugly unwieldy mess that will inevitably break, and I suddenly will be alone trying to figure out what I did wrong. This is what's good about npm and libraries: the community that's built around it.

Well, surely you put the line somewhere? Would you depend on `leftpad`? How about `is-odd`?

Your view of dependencies is very idealistic. And if I'd venture to guess - apologies if I'm wrong - young, at least to programming. I'm saying this because you don't tend to hear such phrases once reality hits.

Everything you said can be flipped:

> If I import this code in my codebase directly instead of using a library, it suddenly becomes my "responsibility" if it breaks.

I have full control & understanding of the code; I can adjust & trim so it fits as much as possible. If it breaks, I can fix it directly.

> And when we're talking about a FOSS side-project, I don't have that kind of time.

Copying/hand rolling some trivial code is often faster than deciding among a dozen libraries which do the same thing, reading their docs, their issue pages and open PRs, adding and integrating to my project.

> Third-party libraries means I get any improvements and bug-fixes for free.

I must keep the dependencies updated. I must read changelogs and hope nothing breaks.

> And if it breaks, I get to talk with the original maintainer to figure it out

I must use inefficient communication with a more-often-than-not absent maintainer in order to resolve my problem instead of fixing it directly.

> I suddenly will be alone trying to figure out what I did wrong

I am able to be self-reliant in fixing the problem, because I wrote the code and I understand it.

I do not have to trust the maintainer of the package or the maintainers of any of its transitive dependencies to be competent or non-evil.

---

For some things this is worth it. IMO for generating 16 random bytes it is not worth it.

Well, everything I've said here are grounded in personal experience working on FOSS projects. They're also grounded in trust of the maintainers. In 5 years of full-time programming as a job and a hobby, I have found that to work to my advantage. I can understand that this might not be everyone's experience. I also understand that different projects have different needs - some might simply be too sensitive to depend on external code if they can help it.

To answer your rhetorical questions: I would certainly depend on leftpad, as it allows me to free my mind to something more useful. I probably wouldn't depend about is-odd because I intuitively know how to make it work. That's pretty personal. The line is basically drawn at "do I need to think to figure this out." Yes, leftpad is trivial. But this is death by the thousand papercuts: When I program something, I'm solving a problem. Having to solve a million other problems at the same time - no matter how trivial - is going to take me away from what I'm supposed to actually doing. It breaks my flow. I don't like that.

> Copying/hand rolling some trivial code is often faster than deciding among a dozen libraries which do the same thing, reading their docs, their issue pages and open PRs, adding and integrating to my project.

I have found this to not be the case. In the JS land, depending on a library is beyond trivial. Especially for those "simple" libraries that simply export a function. Yes, I do need to read the docs, but there isn't a million ways to do leftpadding, nor is there a million ways to do UUID generation. Copy pasting code might require playing with requires, figuring out transitive dependencies, and just some manual work that take time away from actually thinking about the code I'm working on - again, breaking my flow, forcing me to context switch.

> I must keep the dependencies updated. I must read changelogs and hope nothing breaks.

Semver takes care of that for you. And yes, I trust maintainers to follow semver. Again, that generally works. I only had a single case of semver-breaking release in my life, and that was in the Rust land - docopt.rs 0.8.2. https://github.com/docopt/docopt.rs/issues/235. Debugging the issue took me at most an hour, reporting it to upstream took seconds, and the fixed version was released literally 10 minutes later. In the meantime, my install still worked due to the lockfile pinning the previous docopt version. I could easily continue working normally.

Breakage happen. I've found that breakage also happen internally. Sometimes I change my code and break my own invariants. Refactor and forget to fix an instance, which breaks the code in subtle ways. Bugs happen. I accept that.

> I have full control & understanding of the code; I can adjust & trim so it fits as much as possible. If it breaks, I can fix it directly.

This is where I totally disagree. Depending on a third-party package does not deprive me of the ability to fix code when it breaks. And in fact: it empowers me. Again, the major advantage of dependencies, in my view, comes from the community. And if it needs adjustment that could be beneficial to others, I can PR it. I can fork, and npm has tools to make it easy to inject a fork into the dependency tree, replacing all instances with my own. This lets me experiment with potential fixes with ease, as if it was my own code.

Sure, sometimes, the library might not do exactly what I want it to, exactly how I want it to. Maybe what I want to do is incompatible with said libraries. In those cases, rolling my own might make sense.

In the end, it comes down to this: I trust the community, and believe in taking and giving back. If that's a young point of view, then so be it. Maybe I'll learn the hard way that reality is not so forgiving, that my trust was misplaced.

v1 and v2 UUIDs are derived from a MAC address by specification, the uniqueness of the v1 scheme in particular depends on it. Whether that's a good idea or not is another topic entirely, but if you want to conform to spec, an implementation needs to be able to read MAC addresses

Please see the comment I replied to.

A buffered channel can be implemented with two unbuffered channels + a goroutine + an array.