zenhack

I suppose that depends on what your skill set is.

At some point the project would greatly benefit from some attention from a UI/UX specialist -- I'm doing my best, but it's not what I'm an expert at. Though right now I'm mostly focused on getting enough stuff to work for it to be of interest, and someone fussing with the UI might just be distracting.

Doing app packaging for Sandstorm might be the most accessible way to help for someone who's not a Go dev -- Tempest will of course benefit from more apps when it's ready to run them, and it'd be a high impact thing for the community right now.

> Replacing pointer arithmetic where it's needed with array indexing stands out the most but there's other issues.

What situations do you run into where array indexing is not an acceptable substitute for pointer arithmetic?

There's an opportunity cost. There has to have been a better use of that person's time than taking a tool designed to say yes to repetitive "are you sure?" prompts, and get it to keep up with memory throughput. The throughput of a tool like that does not matter.

> Of course, there's a very conscious tradeoff being made here. In rust, "cargo build" allows arbitrary execution of code for any dependency (trivially via build.rs), while in go, "go build" is meant to be a safe operation with minimal extensibility, side effects, or slowdowns.

I've been working off and on on a language that tries to get the best of both worlds to some extent. The whole language is built around making sandboxing code natural and composable. Like Rust, it has a macro system, so lots of compile time logic is possible without adding complexity to the build system, but macros don't have access to anything but the AST you give them, so they are safe to execute. There's a built in embed keyword that works like Rust's include_bytes, which runs before macro expansion, which you can use to feed the contents external files to macros for processing. At some point I'll probably add a variant that lets you pass whole directory trees.

The trouble is that this assumes pre-determined quantity of work. The reality I've seen most in places is that there's no end of stuff to do. The work is never "done."

What there is instead is an expectation of how much work you're supposed to get done per unit time (albeit calendar time in shops that have things more together). But this is in turn informed by how much time you are expected to devote to work vs other parts of your life.

I think grep is a compelling example of when it makes sense to do the extra work here. But I'm more dubious of the idea that carefully optimising yes was a good use of engineering time.

It's always amazing to me how much performance work the basic gnu tools have seen in general. Grep makes some sense, but even yes(1) is fairly carefully tuned; in some cases it actually strikes me as kindof excessive, and not clearly worth the readability drop.

The package they passed in March was $2 trillion. That's _five orders of magnitude_ difference.

$75M is rounding error compared to anything being discussed in the vicinity of the pandemic; I wouldn't really expect it to enter into the conversation.

Can't speak for the OP, but for myself: I am not qualified to evaluate the evidence in this case; I just don't have the biology background. But sometimes when you get some out-there questionable sounding stuff research, and you spend a minute googling, you quickly find out that the journal the thing is published in is chaired by the author and itself has no credibility, the author is selling some form of snake oil directly supported by the dubious claims, and similar. Sure technically their argument ought to stand on it's own anyway, but there are so many quacks out there and so little time. It's a useful optimization.