Scalable, Resilient Brainfuck(zserge.com)
zserge.com
Scalable, Resilient Brainfuck
https://zserge.com/posts/bfaas/
46 comments
F#ckernetes maybe?
Ideally Clusterf#ck should use f#ckf#ck.
>B**b!!!!!!!!!!!! A R S E feck kn*b c* ksh ag t*ts butt
>The above example will echo the first twelve characters from a file/stdin.
https://web.archive.org/web/20050207213934/http://chilliwill...
>B**b!!!!!!!!!!!! A R S E feck kn*b c* ksh ag t*ts butt
>The above example will echo the first twelve characters from a file/stdin.
https://web.archive.org/web/20050207213934/http://chilliwill...
If this isn't a thing already it should be.
HR will make them rename it to something like HiveMind XD
Google has a testing library called Karma that used to be called Testacular...
https://github.com/vojtajina/testacular
Google has a testing library called Karma that used to be called Testacular...
https://github.com/vojtajina/testacular
You can curse here
I assume he is writing in https://fsharp.org/
Drumrol... Wait for the release of Brain#
I did write a .NET compiler a few years ago for a procedural variant of Brainf*ck: https://www.parkscomputing.com/applications/pbrain/
Google App Engine originally used a custom containment strategy.
Back in the day, I was on the team that added Python 2.7 support to App Engine and we were experimenting with a different containment approach.
But Python is a complex language to support - you need to support WSGI, to support dynamic loading (for C extensions), a reasonably performant file system (Python calls `stat` about a billion times before actually importing a file), etc.
So our original runtime was actually Brainf#ck. So, at once point, if you had guessed that Google supported it, you could have written your (simple) webapp in Brainf#ck and Google would have scaled it up to hundreds of machines if needed ;-)
Back in the day, I was on the team that added Python 2.7 support to App Engine and we were experimenting with a different containment approach.
But Python is a complex language to support - you need to support WSGI, to support dynamic loading (for C extensions), a reasonably performant file system (Python calls `stat` about a billion times before actually importing a file), etc.
So our original runtime was actually Brainf#ck. So, at once point, if you had guessed that Google supported it, you could have written your (simple) webapp in Brainf#ck and Google would have scaled it up to hundreds of machines if needed ;-)
Aw darn! Around that time, I was at Google, and there was a thread on eng-misc (or possibly eng-misc-mtv; it's been lost to the sands of time) with people contributing programs that would flip a virtual coin 50 times and output the sequence of heads and tails. I contributed one in BF because I had some spare time waiting for a deploy job, and I've been joking since that I've "written BF code professionally".
And now you tell me that that could have been for real. :-(
And now you tell me that that could have been for real. :-(
What?
I was also really confused by this comment until I re-read it later.
At first I thought OP meant “we wrote out container runtime in Brainfuck,” but what I think they meant was “we first deployed Brainfuck support in order to test our new runtime on something simpler than Python.”
At first I thought OP meant “we wrote out container runtime in Brainfuck,” but what I think they meant was “we first deployed Brainfuck support in order to test our new runtime on something simpler than Python.”
[deleted]
Why though?
great news! the business is delighted by the scalability and resilience demonstrated by this proof-of-concept and alignment with cloud-native strategy. the business has decided to use this as the platform to deliver the new "hello $customer_firstname $customer_lastname" product to production.
since we'll be executing brainfuck programs containing customer PII, the design may need a few standard technical enhancements to implement an acceptable level of controls to reduce the risk of customer data breaches.
each edge in the design must use transport layer security (either using built-in service capability or, preferably, by addition of a service mesh to the architecture).
use of plaintext database passwords in deployment configuration is unacceptable. fresh secrets need to be generated and the deployment configuration needs to be modified to read secrets from our existing secret management platform. please follow least privilege principles and define minimal roles & access to secrets for each service in the cluster.
since the brainfuck machine will be processing workloads for multiple customers, in addition to coarse-grain service-level access control it will also need to enforce finer-grain access controls to restrict which parties can read from or write to which ranges of brainfuck memory cells containing information of distinct customers. this must follow our established standard by adding authentication and authorisation to each service based on stateless access tokens. please update the design to integrate with the existing token issuer.
since we'll be executing brainfuck programs containing customer PII, the design may need a few standard technical enhancements to implement an acceptable level of controls to reduce the risk of customer data breaches.
each edge in the design must use transport layer security (either using built-in service capability or, preferably, by addition of a service mesh to the architecture).
use of plaintext database passwords in deployment configuration is unacceptable. fresh secrets need to be generated and the deployment configuration needs to be modified to read secrets from our existing secret management platform. please follow least privilege principles and define minimal roles & access to secrets for each service in the cluster.
since the brainfuck machine will be processing workloads for multiple customers, in addition to coarse-grain service-level access control it will also need to enforce finer-grain access controls to restrict which parties can read from or write to which ranges of brainfuck memory cells containing information of distinct customers. this must follow our established standard by adding authentication and authorisation to each service based on stateless access tokens. please update the design to integrate with the existing token issuer.
Somebody pay this person more money to not quit.
> Most of the code there was copied from StackOverflow, proving that it’s correct and we can skip writing tests and save us some time.
So perfect!
So perfect!
More than half of the HN crowd refrains from commenting in order to not inadvertently break their NDA.
I cannot name my supplier (very well known company) that is pushing something like this and I am already the black sheep in this area of business for being against it. As our top directors already bought the dream, we will get it.
This is gold. It reflects too many real engineering projects so well. Sometimes I'm the guy to point this out, but too often I catch myself arguing for adding unnecessary complexity (unfortunately usually in hindsight).
There should always be one engineer playing devil's advocate and at least try arguing why a new system/service isn't necessary.
There should always be one engineer playing devil's advocate and at least try arguing why a new system/service isn't necessary.
I came onto a team to support such an overengineered project. On the plus side it keeps me busy, and teaches me new skills. On the negative side my job is to keep the plates spinning on a rube goldberg machine.
The 10th man rule
Our Brainfuck cluster is invaluable to our research at Synergistic Associates. This is an endorsement from our umbrella of companies, since I own them all and have placed my Amazon Echo robots on the boards (after I downloaded my AI written in Brainfuck into each of them!).
Our support incidents dropped to ZERO, when we switched to using Brainfuck on the back end. Prior to Brainfuck, we had used Rust, Go, Python, and even Bash on the backend to implement our proprietary secret sauce.
Truth be told, we actually rewrote our entire backend infrastructure in C from that earlier sticky mess of glue languages holding together the object oriented stuff. C gave us a lot of flexibility, but I started to receive mountains of sales calls and emails from people wanting to sell me security products and internal trainings for how to write secure software. That was sort of okay, but the calls about my expired warranty were just too much to handle.
Somehow, those security research companies knew we had started using C!
Well... Let me tell you, once I switched over to a few one-liners of Brainfuck on the backend, I deleted all the other servers and software. We no longer needed them. Brainfuck really has solved all our problems, IaaS is no longer needed, SaaS is a moot point, DaaS is gone since my users now don't even get remote CLIs, etc. Everything is good for us with Brainfuck!
Oh yea - the money is great, since I fired everyone else. Only me and my army of AI workers written in Brainfuck, downloaded to Amazon Echo devices, remain.
Our support incidents dropped to ZERO, when we switched to using Brainfuck on the back end. Prior to Brainfuck, we had used Rust, Go, Python, and even Bash on the backend to implement our proprietary secret sauce.
Truth be told, we actually rewrote our entire backend infrastructure in C from that earlier sticky mess of glue languages holding together the object oriented stuff. C gave us a lot of flexibility, but I started to receive mountains of sales calls and emails from people wanting to sell me security products and internal trainings for how to write secure software. That was sort of okay, but the calls about my expired warranty were just too much to handle.
Somehow, those security research companies knew we had started using C!
Well... Let me tell you, once I switched over to a few one-liners of Brainfuck on the backend, I deleted all the other servers and software. We no longer needed them. Brainfuck really has solved all our problems, IaaS is no longer needed, SaaS is a moot point, DaaS is gone since my users now don't even get remote CLIs, etc. Everything is good for us with Brainfuck!
Oh yea - the money is great, since I fired everyone else. Only me and my army of AI workers written in Brainfuck, downloaded to Amazon Echo devices, remain.
It's a shame that looping and parsing is so tightly coupled.
Also you should add an ELK stack to centralize your logs and add some correlation ID to your instructions if anything goes wrong.
Also you should add an ELK stack to centralize your logs and add some correlation ID to your instructions if anything goes wrong.
Nothing says “I treat my software seriously” better than paying for its CPU usage from your own pocket.
> If you want to start learning a programming language - write a BF interpreter in it.
> [172 bytes minimal C implementation]
> Well, or something a bit more readable in ~100 lines of code.
Or something a bit less readable in under 104 bytes of binary lambda calculus [1]
[1] https://tromp.github.io/cl/Binary_lambda_calculus.html#Brain...
> [172 bytes minimal C implementation]
> Well, or something a bit more readable in ~100 lines of code.
Or something a bit less readable in under 104 bytes of binary lambda calculus [1]
[1] https://tromp.github.io/cl/Binary_lambda_calculus.html#Brain...
I've done one in Common Lisp, but compared against ~100 lines / bytes,it is obviously bloatware:
http://www.faoileag.de/fn/software.html
Pfft. Imagine creating a BFIaaS that doesn't involve a single message queue for token parsing. What a joke!
That's not enough, you should include a cache layer which key is the neighbor memory state of length 2k (give or take) and the instruction pointer. You can then simulate at most k instructions at once when hit, a steady improvement over non-cached verseion!
The authors twitter bio:
> Turning complex problems into a lightweight and simple software solutions.
> Turning complex problems into a lightweight and simple software solutions.
It's funny because it's true :D
This is very unprofessional. Should use k8s instead of docker-compose.
/jk
/jk
[deleted]
:D
Quick nit - "for may years" -> "for many years". Had to stop reading, basically unreadable.
How do you get anything done thoughout your day, if this typo made you stop reading?
How do you get anything done throughout your day, if you took that joke so seriously?
I think this can be legitimately called a Clusterf#ck.