[HN Gopher] Scalable, Resilient Brainfuck
___________________________________________________________________
Scalable, Resilient Brainfuck
Author : stevekemp
Score : 220 points
Date : 2021-04-09 06:45 UTC (16 hours ago)
(HTM) web link (zserge.com)
(TXT) w3m dump (zserge.com)
| joisig wrote:
| It's funny because it's true :D
| junon wrote:
| Quick nit - "for may years" -> "for many years". Had to stop
| reading, basically unreadable.
| asadlionpk wrote:
| How do you get anything done thoughout your day, if this typo
| made you stop reading?
| junon wrote:
| How do you get anything done throughout your day, if you took
| that joke so seriously?
| TruthWillHurt wrote:
| I'll just put this here... {
| asadlionpk wrote:
| }
| tanbog2 wrote:
| Nothing says "I treat my software seriously" better than paying
| for its CPU usage from your own pocket.
| shoo wrote:
| 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.
| vonwoodson wrote:
| Somebody pay this person more money to not quit.
| lifthrasiir wrote:
| 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!
| pat-jay wrote:
| :D
| linkdd wrote:
| 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.
| [deleted]
| tromp wrote:
| > 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...
| faoileag wrote:
| I've done one in Common Lisp, but compared against ~100 lines /
| bytes,it is obviously bloatware:
| http://www.faoileag.de/fn/software.html
| IncRnd wrote:
| 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.
| fooblat wrote:
| > 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!
| TruthWillHurt wrote:
| This is very unprofessional. Should use k8s instead of docker-
| compose.
|
| /jk
| bquinlan wrote:
| 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 ;-)
| vangelis wrote:
| Why though?
| thequux wrote:
| 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. :-(
| crazypython wrote:
| What?
| [deleted]
| zibzab wrote:
| So he is running clusters of brainf#ck machines in the cloud?
|
| I think this can be legitimately called a Clusterf#ck.
| cdelsolar wrote:
| You can curse here
| nxpnsv wrote:
| I assume he is writing in https://fsharp.org/
| IncRnd wrote:
| Drumrol... Wait for the release of Brain#
| seangrogg wrote:
| #Mind
| stjohnswarts wrote:
| Wouldn't it be BrainFuck# ? or BF# ?
| IncRnd wrote:
| Yes, but I was going for a sharp brain :)
| conjectures wrote:
| If this isn't a thing already it should be.
| devoutsalsa wrote:
| 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
| linkdd wrote:
| F#ckernetes maybe?
| exdsq wrote:
| The authors twitter bio:
|
| > Turning complex problems into a lightweight and simple software
| solutions.
| Maakuth wrote:
| More than half of the HN crowd refrains from commenting in order
| to not inadvertently break their NDA.
| AdrianB1 wrote:
| 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.
| mekkkkkk wrote:
| Pfft. Imagine creating a BFIaaS that doesn't involve a single
| message queue for token parsing. What a joke!
| rswail wrote:
| There's no HA here, so we need a K8S/Fargate cluster and the
| Postgres needs to be multi zone.
| altendo wrote:
| > the Postgres needs to be multi zone
|
| we need it to be multi-master, clearly. those writes need to go
| somewhere!
| ascar wrote:
| 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.
| huachimingo wrote:
| The 10th man rule
| piyh wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-09 23:01 UTC)