Then you'll modify it to be, "Have you heard of anyone running BrainFuck in production other than Nick P's BrainFuck-as-a-Service platform of questionable longevity?
You know what, since we're on HN, let's just apply to the next round of YC. They'd be crazy not to fund the first BFaaS in human history!
I already have a logo in mind. A cloud surrounding a brain, and inside the brain is "the finger".
Fast-forward time some to see it becomes a post-mortum, legacy system, or acquired by Novell as their entry into AI. They promise it will be the success of Netware all over again. Audience at conference pauses at the ambiguity of that statement unsure if they should cheer or charge out the door.
But it looks like there is a legitimate and interesting shift towards running stuff on FPGAs. Google, FB, and MS are all doing something with ML hardware acceleration.
I actually attended a talk a few weeks back by Microsoft's Doug Burger[1]. He has been leading a team that has created a low-latency FPGA network to accelerate stuff within MS. The eventual goal is to allow customers to take advantage of this distributed FPGA fabric to run custom firmware.
He said that FPGAs now run several of Bing's core search algorithms and Azure has some stuff running on FPGAs too. I forgot the exact performance gains, but it was somewhere around 2x for Bing with extremely stable response time even at insane server loads.
One interesting factoid is that they were able to translate Wikipedia in its entirety from English to Russian using 90% of the currently deployed FPGAs in around 100 ms. Insane stuff.
[1]: https://www.microsoft.com/en-us/research/people/dburger/
http://www.scottaaronson.com/blog/?p=1400
https://news.mit.edu/2015/3q-scott-aaronson-google-quantum-c...
In second, this jumps out at me: "The first issue is that the problem instances where the comparison is being done are basically for the problem of simulating the D-Wave machine itself. There were $150 million dollars that went into designing this special-purpose hardware for this D-Wave machine and making it as fast as possible. So in some sense, it’s no surprise that this special-purpose hardware could get a constant-factor speedup over a classical computer for the problem of simulating itself."
Actually gives me an idea. Instead of comparison to BF competitors, I could actually just compare a massively-parallel, BF CPU to 256 interpreters communicating with each other through IPC running on a general-purpose computer. I'd show the CPU performed many times better. It's the closest thing I can think of to how D-Wave is doing benchmarking. The difference is $150 million is not in either my bank account or addition of transaction history.
"One interesting factoid is that they were able to translate Wikipedia in its entirety from English to Russian using 90% of the currently deployed FPGAs in around 100 ms. Insane stuff."
Didn't know about that project. Pretty cool. Yeah, the FPGA projects have been doing all kinds of stuff like that going back to at least the 90's from my reading. The speedups could be over fifty fold. Some claimed three digits. Other programs harder to parallelize & reduce... which is basically what they do on FPGA... might have under 100% speed up, tiny speed up, or even a loss if it was sequential algorithm vs ultra-optimized, sequential CPU like Intel's. The latest work, which started in 90's projects I believe, was to create software that automatically synthesizes FPGA logic from the fast path of applications in a high-level language then glues them into the regular application on a regular CPU. You can't get speed-up of actual hardware design but makes boosts easier if problem supports good synthesis. Tensilica is another example of a company whose Xtensa CPU is one that's customized... from CPU to compilation toolchain... to fit your application. Container people are compiling and delivering containers. Tensilica compiles and delivers apps with a custom CPU.
That's a great expansion it being undocumented. Worked wonders for Microsoft's strategy of lock-in. We're going to have to make sure the CPU and platform's API's are considered copywritten on top of that so they might not be... legally allowed... to clone or port it without paying us. We could collect royalties on a BrainFuck CPU for our lifetime plus an arbitrary number of years decided by Congress reps collecting bribes.
I'm not sure it's worthy of a Bond villain but it's a start. ;)
Unfortunately, you can't outrun software's hidden assumptions behind correct functioning forever. There will come a time, much like Y2K for COBOL, that their critical database will just loose everything if they don't make an internal change that requires understanding all the Rust, BrainFuck, Verilog, and analog components I used "because I was learning analog at the time."
I can't predict what they will do facing such a situation. I can tell you to start a brewery of fine Scotch that sends flyers to them around the time of the feasibility study. You'll make a killing. :)
Honestly, it'd probably be worth the effort to just write the Rust up front. The kind of technical debt you'd land in otherwise... euurgh.
That's actually the point of my plan. :P