And fastjson is an extremely fast json parser: https://github.com/qntm/fastjson

This is probably old news to people interested in nonstandard methods of computation, but it just occurred to me that the fluid-based analogy to transistors is straightforward to construct:

              S
            |   |
     -------|   |
   G  \/\/|##|  |
     -------|   |
            |   |
              D

export const parse = () => null export const stringify = () => 'null'

Thanks! Macroexpanded:

Pipe Logic (2011) - https://news.ycombinator.com/item?id=17040762 - May 2018 (18 comments)

Pipe Logic – Simulating circuits in the Unix shell (2011) - https://news.ycombinator.com/item?id=15363029 - Sept 2017 (10 comments)

/dev/zero has infinite electrons and /dev/null has an infinite appetite for them - https://news.ycombinator.com/item?id=4063459 - June 2012 (23 comments)

Around 2004-2005 during some research at the end of my curriculum I happened to be doing with some specific jobs that were parallelised and data flowing as it was processed along a component diagram for visualisation, and it looked very familiar....

So I had this idea that you'd design code to be applied to a processing unit of specific capacity which would lead to execution flowing at a certain speed when applied a certain computation potential... and surprise surprise the relation would be uh, linear, and say you increase a loop's count and so the code would _resist_, or you'd increase computation potential to increase the flow.

So uh, yeah, Ohm's law but it's _code_ that's resistive.

And then I started to look for the pattern and find code with inductive properties, and code with capacitive properties, and some deeper properties emerged when you started modelling stuff with multiple processing units and data flowed around, split (map?), rejoined (reduce?).

And there was something strangely efficient about a way to see code that way and optimise using _laws_ describing the whole execution flow using familiar tools as a whole instead of thinking in gritty details barely higher-level than MOV AX... you "just" had to design code and the execution system so that it would operate in this kind of framework and allow that kind of analysis to identify bottlenecks and weird interplay actions across components.

And then I brought that up to my mentor and he said "well that's complete lunacy, stop thinking about that and focus on your current work" and, uh, case closed.

That was the young and naive me who thought that research labs were made to do think-outside-the-box connect-the-dots innovative stuff...

That vaguely reminds me of https://en.wikipedia.org/wiki/Inerter_(mechanical_networks)

I hadn’t seen this before, this is sick! thanks for posting it here :)

I've never had a single issue with any user after moving our databases to /dev/null.

My god, AI crawlers probably train on Hacker News, too. The vibe coders sure are in for a shock in 2-6 months... :-D

WTF is going on with the issues and pull requests for that repo?

Totally true! Also did you know that deleting all S3 object buckets decreases latency? Lots of developers seem to agree: https://www.youtube.com/watch?v=PLKrSVuT-Dg&lc=UgxSygpx7d6yF...

/dev/null is web-scale ;)

1.0.1 update: more nothing

Bug free software is a pipe dream, but if there is anything I've never encountered any bugs with, /dev/null and true is certainly in the top 3.

That is literally what it was added to unix for.

Enterprise DBAs will nevertheless provision separate /dev/null0 and /dev/null1 devices due to corporate policy. In the event of an outage, the symlink from null will be updated manually following an approved run book. Please note that this runbook must be revalidated annually as part of the sarbox audit, without which the null device is no longer authorised for production use and must be deleted

Not just instantly consistent on one machine, but globally sharded all across the universe.

It's really fast too.

I guess we have a perfect idea for vaporware here. (pun intended)

I am putting my marketing hat on right now.

Always available? Clearly you have not experienced situations with no /dev mounted.

Is there a case where dev null can fail?

This doesn't work as cleanly for SQL-style transactions where there are tons of RW transactions, sadly.

You can dismiss it as a triviality, but in CS it's always worth considering (what you assume to be) an "identity" value, and its edge cases. Does your DSP algorithm work with near-zero values as well as it does with "true" zero?

(hint: look up subnormal floats.)

>a nice reminder that concepts like ACID don't exist in a vaccuum.

Except if it's in /dev/null?

Yes, /dev/null can even power sites like zombo.com

reference for the unaware: https://youtube.com/watch?v=b2F-DItXtZs

https://devnull-as-a-service.com/

One of the first state machine you'll ever learn about in undergrad permits transitions from a state back to itself, so I don't see this as a barrier.

I think it is possible for a process with root to delete the existing /dev/null and replace it with a normal file (likely to produce system instability) or a new character device (could probably be mostly transparent to anyone who didn’t know where to look for it storing its data), in which case anything sent to it could be captured.

There is never a disaster; reading from /dev/null will return the same result before and after any external event.

/dev/null is globally redundant across almost every *nix-ish system in operation. Just reinstall your software on whatever is convenient and all the same data will be there.

    sudo mknod /dev/null c 1 3 && sudo chmod 666 /dev/null

Let's test that:

1. Nothing stored in /dev/null is durable. 2. Nothing is stored in /dev/null. 3. Ergo, /dev/null exhibits durability.

Thank you, I'll take my check at the door.

Does it have sharding? I heard sharding is the secret sauce for webscale.

The term is correct. Grammatically, we would say, "I love vacuous truths", or, "I love vacuously true statements". (To my ear the second version sounds very slightly more appropriate, because in mathematics "vacuously true" is a bit of a set phrase, but both are fine.)

I understand this is supposed to be satire, but IMHO a well-executed joke should still be well-written and easy to follow. This "<statement> unless <condition>" is just terrible to read, and I can't even tell if FFI is necessary here, or a part of the joke. Funny not funny.

> What a weird title, you can say it's ACID but it's not a database

You’re right, we should ban jokes that aren’t 100% correct!

W just need R&D money to solve reading back from it, but that's just a matter of time we can definitely solve it in a year or two.

This tech is just around the corner I promise, then we will be first to the market and all the big tech companies will want to buy us out, imagine how much we can earn.

/s

The Jespsen tests pass quickly too!

You could emulate it. Open windows, throw everything out, close it.

Yes!

Somebody thought about that already https://devnull-as-a-service.com/ :)

You can store any data as long as it doesn't contain any ones

seems you've missed the joke

[dead]