My Coding Cult

I made a few improvements to Eden platform as it will be almost two years that I'm running in production. No matter how many compile time errors you add not everything is testable in compile time. Say, for me it took half a year to get lets encrypt certificates working correctly. Not that I was debugging half a year, but one certificate issuance is valid for three months I think and not all steps in the pipeline succeeded in updating the certificate, hence it didn't refresh automatically. So after couple of failed auto refreshes and painful debugging sessions certificates have been working automatically for I think at least a year now and I forgot them.

And that's the path of most software. Regardless of the programming language. If you put n iterations to your library/package/executable it will have less and less issues.

Well, why use Rust then? For Rust path to maturity is much faster. Even though Eden platform executable and EdenDB compiler are written in Rust they do generate a lot of shell scripts. Needless to say there can be bugs which then I stamp out. But just like with automatic certificates example I get less and less of these and everything getting better and better.

I remember even with some crappy scripts for some company I maintained reasonably complex shell scripts before, which is a pain needless to say. However, after bloodied knuckles and hundreds of iterations of provisioning eventually things become quite stable.

Say, this forum, I didn't look for an implementation of forum in Rust. Simple machines has a lot of battle scars and frankly I don't need anything super complex to publish my thoughts. The blood and sweat and tears which made simple machines forum are other people, not mine.

That being said, I'd never start any new and ambitious project like Eden platform in any other language but Rust. Since this is a compiler that should blazingly test a lot of stuff I had to use Rust to never be limited by the language's performance ceiling. I knew I would get to my goals a lot faster by using typesafety of Rust. Even now when adding features, as I can't keep everything in my head, I forget the parts of code but once I browse around, all the types are clear and I can keep building stuff. If I add enum invariant I'll have to cover it. If I use non existing field that is a compile time error.

I can't imagine writing Eden platform in something like ruby. Just using the tooling of the language makes me feel disgusted. If you install a bunch of packages with opam in OCaml you just feel quality, a bunch of green lines finish building stuff and off you go. Same with cargo in Rust. When I had to use Ruby at work before I was appalled - some package needs some native dependency, or some config is incorrect and I get cryptic errors. Even worse it becomes when I actually need to use the tooling and I had to call a ruby priest who memorized all the errors by heart so he could translate it into actions of what was needed to be done to make it work. Ruby people are absolutely crazy.

Hence I'm also a little bit ashamed because there are still rough edges in Eden platform itself. However, these days mostly shipping product and from time to time I do get to iron out issues which make life better overall.

For instance, I incorrectly assumed that Grafana Loki and Grafana Tempo are good products. After operating them in production turns out they are horrible products, they use too much bandwidth, processes OOM crash often and the products themselves are slow. Turns out the only good product grafana labs ever made was... grafana. You see, I don't have every tiniest detail figured out. I hope to get there, but I don't know everything about underlying components. But I do know one thing for sure - I want to open grafana and see my goddamn logs and traces to work reliably. That is my vision. That is not some brilliant insight - I just want things to work. That's why I plan in future to replace loki and tempo with VictoriaLogs and VictoriaTraces, same guys that made VictoriaMetrics with which I never had any issues. I made a rule in my mind to just run away from any garbage that claims "bottomless storage" (code word for s3 lock in and inefficient querying).

Eden platform is a complete attempt at just providing everything lazy developer needs to run his infrastructure for any project where he wants to serve http requests to the user. Lazy developer (like I want to be) is assisted by compile time errors and if infrastructure compiles it will have to work. I don't want to hire infra guys to do the work of the compiler. Lazy developer just wants high availability, knowing that any server can go down and stuff will still work. My idea is that all of the services provided are just software and we shouldn't pay anything extra to predators like AWS or Vercel. We should just have a few bare metals at start and have everything we need already, deployments, backend services, monitoring, tracing, logs, typesafety, queues, databases and so on.

I imagine only adding very few more features now upon the top of everything that is working already:

• Self hosted email

We have S3 and we have Postgres. We own our DNS. All these services are highly available. Why should we pay extra for email providers? We shouldn't. We could just host something like stalwart email (written in Rust, yay) and be completely free from any more extra email providers might charge us.

• Automatic OpenAPI imports, we should just import the goddamn yaml, it is parsed, analyzed and we could expose the api to our Rust services and just be able to use them in a typesafe manner. That's it. We shouldn't need to open manual reqwest calls.
• Generate and expose data about database schemas to blackbox deployments for typesafe database querying, like if you want to use third party frameworks that would be respectful of database types
• Scaling strategy across datacenters if we need more than two bandwidth nodes - didn't need yet, will cross that bridge once I'm out of bandwidth

I'm not sure if I'll need to add more databases to the mix, there's Postgres already. Maybe for hyperscaling FoundationDB will make sense at some point, but I don't have any scaling issues on modern hardware as of yet.

Once all these features are added then I can just keep maturing them. So, if I define scope as finite and I can stop adding new stuff at some point that means eventually I should fix all the issues as well so Eden platform could be nearly flawless (as long as underlying components used allow it to be flawless).

Going on a tangent here, I'm glad that the shitstain of ruby on rails is now losing popularity and people are massively realizing that no typesafety is killing their productivity. DHH claims this is cock shanel of languages (how much of a homo should you be to know about perfume this much?) because muh we use sharp knives and we write little code. I understand where he's coming from, I'm using lucky framework which is in crystal (typesafe and blazing fast ruby) for one project and productivity is amazing. You know when I feel most productive in lucky framework? When I define endpoint and it generates automatic frontend typescript definition for calling it and I don't need to do anything else. When I, or mostly coding agent these days does initial implementation and has to fix all the typesafety errors and things just usually work. I don't spend times in long winded debugging sessions of what dynamic variable has become now and how did it get there. That is productive.

And its very funny, because when DHH mentions that static types are no good and that ruby scales because shopify uses it, he completely "forgets" to mention these points:

• shopify is adopting sorbet for typesafe ruby
• shopify has roughly 4000 engineers
• shopify codebase is 2.8 million LoC

Now, let's divide lines of code per developer 2_800_000 / 4000 = 700.

700. 700 lines of code on average per developer. DHH would never mention this, so the long haired hippy fag claims that ruby codebases can scale, that is funny.

If we're measuring length of our pride now, EdenDB implementation without examples and tests is 12k lines of code, Eden Platform lines of code without tests is 79k. So total 91k lines of Rust code by me - one developer without using LLMs, bulk of implementation before even LLMs of today existed. I only now sometimes use LLMs to generate parts or proof of concepts for scripts or regexes, but everything else is by me alone. I guess then I'm 130x more productive engineer than an average monkey in shopify, which is not suprising for me at all.

Now I want to analyze also that in Eden Platform 24.4k lines of code are for pure code generation (/codegen/ module). So, little bit more than 30% of all code in Eden Platform is a code that writes code. Imagine if 30% of code in your project were Rust macros or ruby metaprogramming - project would be unmaintainable. But because my codegen is simple, I just create strings and I can generate any code, not just rust but Makefile scripts, nomad job declarations, sql migrations, anything really, then my approach becomes a lot simpler and the only reason why Eden Platform as a project is possible at all.

Now I want to analyze my actual production project which uses Eden Platform. All the lines of code in the repo are 154719 - let's rough it down to 154k lines of code. Here's the kicker, of these 154k lines of code I wrote with my hands... 11402 lines of code. I wrote 7% of code in my eden platform project, the rest of code like nomad job declarations, provisioning scripts, nix configurations is autogenerated. I do deploy stuff out of tree of eden platform though via blackbox deployments so that source doesn't end up in eden platform project code.

So say, even if I'm already roughly 130x engineer to the average communist fag at shopify Eden platform still makes me 13x more engineer (1690x total, lol) by the code that it generates for me and everything is type safe and I have no fear deploying to production.

So, of course, there are tons of success stories of using Rust for large projects with small teams, tons of blockchains (think Solana, Polkadot) but there are very few high LoC ruby projects and all of them have the same symptoms:

• You need to hire tons of communist fags to maintain all that mess
• They tend to be adopting some typesafety primitives anyway because it is obvious that code is unmaintainable once it becomes large in ruby

So unless you can hire or groom thousands of commie pink haired homos that like ruby good luck building your project with rails in 2026, lol.

Have a good day bois!

Hey boys, I've been using Eden platform in the background and kept adding more and more things that I needed.

As I predicted before, now I need to modify Eden platform less and less as I rough it out and is now reaching maturity, so this time I added these features:

typesafe Postgres query notifications

this natively supports pg_notify in your backend rust applications, just define pg_channel in pg_schema table and use it in the backend application via used_producer_channels if you want to send typesafe notifications or if define used_consumer_channels if you want to receive typesafe notifications. I made this when I wanted some backend service to instantly be notified about net work in postgres

// define the type with pg channel
DATA STRUCT versioned_type {
  type_name: some_type
  WITH versioned_type_snapshot {
    version: 1,
    snapshot_source: '{
      instrument @0 :String,
      size @1 :F64
    }'
  }
}

DATA STRUCT pg_channel {
  schema_name: my_db_schema,
  channel_name: the_new_channel,
  payload_type: some_type
}
Then you can modify backend_application_pg_shard to use the channels for production and consumption (even in the same service)

DATA STRUCT backend_application_pg_shard {
  ...
  used_consumer_channels: '
    the_new_channel
  ',
  used_producer_channels: '
    the_new_channel
  ',
  ...
}

And just like that you'll have typesafe definitions in your rust backend application generated to use channel with typesafe structs for production and consumption (for consumption you'll be forced to implement the consumer of typesafe messages).

MinIO publicly exposed bucket ingresses

I was shocked how little work this was to do because all the building blocks were there. Just define minio_public_ingress row like

DATA STRUCT minio_public_ingress {
  bucket: my-minio-cluster=>my-minio-bucket,
  subdomain: muh-cdn,
  tld: my-awesome-domain.net,
}

Compile project, run l1 (for DNS records) and l2 (for load balancer update) provisioning and that's it, you're done. Your MinIO bucket is publicly exposed at https://muh-cdn.my-awesome-domain.net/my-file.jpg for reading.

• Let's encrypt certs are auto generated (we already had them for your TLD)
• DNS records are automatically added to external load balancer
• Nginx external load balancer rule is already generated

That's how we roll in Eden platform, few lines and amazing power.

Monitoring of certificate expiration for consul/nomad/vault certificates

This is a small change but I exposed metrics of in prometheus node exporter for certificates of consul/nomad/vault so we could monitor yearly expirations as I'm already running in production for nearly two years now, up to you to set up the alerts for those.

Zero downtime certificate reload for vault

Other services like consul/nomad we can just restart, but if we restart vault we must reflash keys, so in case certificate is changed we'll just softly reload vault. It will use the new certificate but we will not cause downtime for vault node.

Some NATS hiccups fixed

Nats didn't have correct disk usage reported in the jetstream system and stopped receiving messages unpredictbly for me, so I just made it assume there's a lot more free space to resolve the issue because I see when disk is about to run out from alerts anyway, I don't need NATS to stop working.

Expose NATS message ids for NATS native deduplication

Preferred master replicas for postgres

I exposed patroni functionality to set failover priority if you want some node to be preferred as a master, say I had couple servers with blazing fast nvme drives

Fixed bug that nomad client starts earlier than zfs datasets are decrypted and mounted (useful post restart not to blowup root dataset disk space usage)

DateTime64(9) and UUID are supported in clickhouse

Rewrote NATS consumer in backend application to make it more reliable and auto retry consumption

When importing data from nats to clickhouse using stream mirroring you can ignore extra source fields from nats stream

Added 17.2 version of postgres

Expose more metrics in NATS jetstream system

Fixed patroni haproxy failover to the master node

Have a good day bois!

Commie pagan bastards as usual are trying to pervert the truth. Jesus principle ( But other fell into good ground, and brought forth fruit, some an hundredfold, some sixtyfold, some thirtyfold. Matthew 13:8 ) or for pagans also known as Pareto distribution, that 20% of the people do 80% of the work is again fought once more by the pagan monkeys.

There's no 10x engineer! Communication is important! Teamwork is everything! Schedule that kick-off meeting instead of actually working!

Frankly, you make me sick. For myself, I lost a count how many sprint plannings I have had where more than half the tickets were done by me alone in a 5 person team. And you shitheads if you had any shame would feel embarassed but no, somehow in your degenerate world its not your fault that at work you spend most of the time doing meaningless meetings, smiling, waving, sipping soy lattes or playing playstation instead of actually getting things done.

In a commie bastard mind, they cannot imagine that there is someone superior to them. Communism can only work if everyone is equal and there's no mastery, no competence of anything. Communism only works if all innovation is halted and there's only one poor way to do things that everyone knows which makes everyone replaceable hence easily controlled with group think shaming tactics.

They think that if they're eating cheetos and having man boobs they're the same value person as someone like me who actually puts effort and exercises two hours daily. Entire christianity is based. That was a good sentence, so I ended it there, but I'll continue. Entire christianitty is based on a God that is superior to all of us and has created everything and knows everything. And he hath on his vesture and on his thigh a name written, KING OF KINGS, AND LORD OF LORDS. - Revelation 19:16. That is humbling - there is a God that is infinitely better than me at everything, infinitely smarter and infinitely more powerful. That commands respect. That inspires love. That inspires me to resemble his image to the best of my ability.

While the rest of you soy man boob fags who visited the no kings protest deserve 40 stripes with a whip. You do deserve at the very least feces thrown on you by a jet with Donald Trump inside it. Any man that strives to achieve something in his life is already better than you. I'm not even talking about ancient kings which would likely order you to be beheaded and forget you ever existed.

Anyway, these shitheads software "engineers" would make me so sick that I devised a strategy against them. If there's an upcoming project, instead of waiting for the dreaded meeting of everyone letting out their period blood on how they feel about the project I would just start implementing it. I don't know some implementation detail, config, or parameters? I'd just guess, implement everything and then say, here it is 90% of the work done, we can iron out the details. I avoided all of the tug of war of bullshit discussions involved on approaches and the upper management is happy to see the initial results already delivered. I have a mind and I can implement everything on my own from scratch and your inputs, blood sucking parasites that don't get anything done by the way are of low importance for me.

Its usual thing with leftist fags, they just love to blow against the stream. Like, am I the one that created stereotype that niggers are less intelligent? Or that asians have smaller thingy? Niggers have bigger thingy? Asians are better at math? White men are better at everything? Certainly no one could ever independently come to such conclusions, the blasphemy! How can people be so racist. I'm not racist, I never worked with a nigger programmer in my career but I think it is okay if they do things they're better at, like picking cotton. All of us are needed to do our part in society at the end of the day. So all these stereotypes that originate naturally have no basis at all, 10x engineer also?

So, if 10x software engineers don't exist, how about overemployed subreddit, where people work multiple software engineering jobs? If someone does two jobs and other engineer would be too overwhelmed to do more than one job, isn't he at least 2x engineer? I had a time in my life where I was doing 4 jobs at once (all of them at startups and young companies, not some boring enterprise where ticket to fart is valued 2 weeks) but I did feel stressed out. For the first time in my life it felt like I actually worked 8 hours per day. My wife would bring me lunch to my desk so I wouldn't need to go anywhere. I don't want to get back to such stress though again. So at least in this context am I not at least 4x engineer then?

That's why I can't stand working with modern faglet software engineers and never plan to work with them again. Not a single time in my life I ever felt more productive and happy in a team versus me working alone. I'm sure someone of my level will feel similar that they can get so much done themselves why do they need to bother with someone else for the engineering part? When I think about how much stuff I'm shipping daily for my own projects, I think of any other company and the people working there of how much it would take - I cannot believe they're getting anything done at all. Some bugs I push changes to fix in 2 minutes after noticing them. There are no tickets, only goals and nothing is blocking me from hacking through the forest of trees to get there.

I don't care what is the underlying issue with most of you modern fags, is it that you're a depressed nihilistic miserable shithead, is it your low testosterone, is it you daily filming your whore wife for her OnlyFans - you're a goddamn liability as far as I'm concerned. You're a blood sucking parasites feeding of the payroll and talking about meaningless virtues like getting more women into software development. AI is not that bad now and people like me will be able to accomplish more and more and more alone. We'll be able to run more and more one man army startups while you miserable shits will keep getting trimmed more and more as the fat that you are.

I'm so happy that God blessed me with being the so much hated 10x engineer and not some miserable unproductive soy latte man boob cuck. Thank you LORD!

I've worked on various environments over the years, bare metals and cloud. I'm not a huge fan of counting data and numbers. In fact, the entire whitepaper (muh scientific) industry is a fraud.

Basically, any time some scammer comes along, like AWS, they tout you all the imaginary advantages of the cloud:
- Scalability
- Flexibility
- Cost efficiency

And it looks modern, shiny, so for most people logic automatically turns off. People start loving cloud and they start hating on premise hardware.

And any suggestion that running your own bare metals might actually be superior solution in all ways will inevitably meet resistance, like:
- Your experience is anecdotical
- Everyone's doing it (no one fired for buying IBM)
- There's no yet wide data available to suggest cloud is inferior

It is extra annoying when people try to hide behind science, like "this is not researched enough".

So, for some reason, to go into the cloud you can go based on feelings, emotions, illogical reasoning and you need to collect data points and perform science to then convince yourself to get out of the cloud?

I knew AWS is a fraud by the time I got my first ever bill and I compared it to the costs of the normal hosting. I didn't need whitepapers. Just for fun I made Eden Platform to work with AWS, but I'd never suggest to run that setup, because AWS will simply drain you on egress bandwidth costs, even if you run only few servers there for quorum. Because, even if all the heavy lifting of monitoring is performed in bare metals, we still want to have metrics of our piece of trash nodes which run on AWS so AWS will still need to send some data out because we monitor AWS nodes in Eden platform.

And I see slowly the fraud unfolding before everyone, and by the time historical fraud of biblical proportions is committed, and someone crunches the data (assuming it will not get censored away) and finally when whitepapers after decades will start saying the truth, that yes, indeed cloud is utterly cost ineffective and doesn't make any sense AWS will already have accumulated unbelievable profits and the next fad will start.

Imagine, if you see some old pedophile giving candies to children, and you can't do anything unless the pedophile already victimizes the child? This is cloud industry, which will kill so many startups with its costs alone and only years later the reality will become mainstream.

Let's discuss party lines of the cloud vendors and deconstruct them one by one:

Cloud is cost effective

Nothing could be further from the truth. In fact, if you're talking about AWS and you're talking about cost you're an idiot already. Basically, I computed the infrastructure cost that I have, of beefy bare metals, to which I pay 200 dollars for hosting and my local datacenter to which I pay 100 dollars for electricity.

I calculated the amount of cores and gigabytes of memory that I have versus that infrastructure that we had.

For CPU cores AWS was 56.17$ per core, and 13.95$ per gigabyte of memory per month. My infrastructure is 2$ per core and 0.27$ per gigabyte of memory per month.

So, the ratios between AWS cost are:
- 28x more expensive in AWS for cores
- 51x more expensive in AWS for memory

Now, the craziest part is... The AWS setup is cost optimized, it has sophisticated system to run mainly spot instances for most workloads, there was a bunch of other work to reduce costs as well performed, and with all this work the most optimistic ratio is 28x for cores?..

And some idiot managers in the meetings say "there's no economy of scale advantage yet to run our own hardware". That's what happens when you get clueless managers that never probably replaced hard disk in their lifetime dictating business decisions.

We can scale instantly with a cloud

Yes you can. Now, let's use some of our brains, look at this one "anecdotal" cost difference ratio of 28x and think about something.

If we just rented bare metal servers, how much more hardware we could get if cost ratio is 28x for the same price? 28x more cores. 51x more memory.

How about this scaling strategy: we just buy 10x more hardware than we need with bare metals, don't give a crap about scaling at all for a while, and we're roughly still 3x cheaper than AWS?

Or should we run some virtualized garbage, barely breathing services in tiny VMs and just keep using hardware at 28x cost after spending effort to optimize it to the best of our ability?

Automatic updates and security patches

Since I'm running NixOS I only do updates once couple years or so. Some people might say software is too old, I'm like, whatever. If some breach is serious, like openssl heartbleed then you'll hear about it. Most of what people consider "security" issues are imaginary and in their head.

Are your servers only accessible through SSH keys you own?
Are your private connections secured through Wireguard VPN?
Are your ZFS datasets encrypted and all secrets in memory, in case someone tries to boot server through installer USB stick or CD?
Is swap disabled on your servers?

I can answer yes to all of these, so, for me, patching just because there's a new version - I don't care. I'm building products most of the time these days and Eden platform lets me focus on that.

In fact, I think I can write other post, that the update procedure itself is a literal attack vector instead - everyone is being told update update update ASAP. I'll let everyone else update with fresh code, test it out for breaches in production, hear stories about how they were hacked and latest data breaches and then decide to update or not and to which version.

So, again, this is a non issue, and if you'll run your virtual machines in the cloud (you 99% will) you'll be responsible for updating the OS anyway.

Faster time to market

I don't understand this argument at all from cloud proponents. Right now, I already own a lot of hardware for me, my servers are almost idle. As long as I'm not doing some business which would require training/inferring AI models (that's just a modest share of 99% businesses out there that actually make money and not just blindly splash VC funds to the left and right) I can build hundreds of different website ideas on the same servers until I code website or service that is used by enough customers that I'd need to expand to more servers. Once I've built Eden platform I'm spending most of the time building new businesses. Sometimes I need to replace a disk, but my servers keep running because ZFS makes disk failure undetectable to applications.

Managed services

In Eden platform I have managed:
- HA postgres
- HA S3 (MinIO)
- HA queue system (NATS)

Everything is setup in a highly available manner and compile time error will tell me that, say, I only have 2 NATS instances if 3 are needed for Jetstream quorum.
If I don't like anything about the managed service, I own it and can change it, make more things configurable and so on. I could even fork the underlying components if I wanted. Good luck to do the same with cloud services.

Better customer experience

This point makes me really pissed. As having been on the side of both trenches I can confidently say that managing even thousands of bare metal services is simpler than dealing with cloud bullshit.

I only remember something magical few times, like new batch of servers shutting down within 24h, but we did Linux update and the issue was gone. Other than that, it is much more easy to debug once you actually own your own hardware. I know physical limits of my network ports and switches, just put monitoring on if they're reached, server/hard drive temperatures and if you're running NixOS nothing really unpredictable will happen. Once I worked out initial issues in my infrastructure, adjusting ventilation for good server temperature I forgot I have these servers. They're just running. Sometimes there's electricity loss but I have monitoring for that, I know when to reload in memory secrets and my systems are highly available - any DC or server can go down and my projects still work.

Now let me talk about some of the biggest pain points I've been dealing with, and the root cause is... the goddamn cloud

- Some component is alerting, running unreliably. Root cause? Its running on spot instance to "save costs" and it gets often shut down because AWS is taking our spot instance from us.
In my infrastructure this will never happen. My servers go down very rarely and jobs are rescheduled to run somewhere else. Even a shitty, unreliable software will run a lot better if it os not shutdown hundreds of times per year because we run on spot instances. And even spot instances don't deliver any real cost savings we could get from bare metals anyway, so what was the point of running it in the cloud?
- Magical connection disconnects for one service. Root cause? Some AWS bullshit limit was hit.
Of course, we don't own networking of AWS. We can't easily monitor it. Our network is doing who knows what. It amazes me that open source people would move heaven and earth not to run some proprietary software on their servers and proprietary software components are becoming extinct. But for some reason, it is okay to host in the cloud, where now you need to face myriad of magical networking problems because you don't have access to their network? How is this a thing? In hetzner your servers just use the VLAN and you configure it. That's it, as long as you're below the limits of the switch and the network card, which you can benchmark with iperf you'll be good. No magic bullshit because this AWS instances happen to have specific stuff about networking or whatever.
- Server becomes unresponsive. Root cause? AWS instance reached memory limits.
You know what happens on bare metals when this happens? Just process gets killed, I get an alert that process is killed. Most of the developers are aware of this issue. Their server doesn't become unresponsive.
- Docker container doesn't start. Root cause? It was built on a newer server with newer x86_64 instruction set and our AWS server was ancient.
I'll be fair, this could happen in old bare metals. But why I bring this point to attention is, Jeff Bezos knows that every server is valuable. They'll never decomission old severs as long as there's any life in them. Think about this, if you saw an ancient server from 15 years ago you'd say "I don't want it, its old". But if the same dusty ancient server ends up as one of your instances - it is still good for Bezos to give it to you as a VM! How in the world does that make sense?
- K8S Pod doesn't start on a node. Root cause? Not enough elastic network interfaces on a node
Again, will never happen in Eden platform. Our networking is extremely simple and doesn't need bandaid services running besides the ancient routing protocols running the entire internet, written by old graybeards that were designed well before even AWS was a thing. Every server in Eden platform has its own ip and containers use host networking for maximum efficiency. Caveat is, for every service you have to pick unique ports. What happens if I pick duplicate port? Its a compile time error in Eden platform. I can even code with OCaml to automatically pick free ports like DNS names. Much superior to having ENI exhaustion alerts and debugging issues in the middle of the night...

Basically, all the worst magical crazy bullshit issues that I've had - most of it was in the cloud environment. If I'm doing NixOS on bare metals I'm learning about Linux and it runs on most of the machines on the face of this earth. If I'm debugging AWS networking I'm just learning about meaningless AWS garbage that might just be a passing fad.

In conclusion

AWS is an amazing business model:
- You pay a shit ton more for their services
- You get to debug all the bullshit problems with their infrastructure and prevent them on your own
- You're the one blamed in case things stop working.

AWS is like a pedophile that always gets away easily by blaming its victims for everything and is motivated to perform more and more crime without anyone to stop it. Amazing customer experience!

So, I guess at this point, there's clearly not enough evidence to prove that cloud is an absolute trash and no whitepapers are written and this is a pseudoscience. But of course, at the end of the cloud era there will be people who knew which was better without whitepapers and there will be the blind followers who will take in all the damage until the mainstream viewpoints have shifted.

Good luck with your AWS account, whitepaper faggots!

And the rest of you have a good day

Hello bois, I added more updates to the Eden Platform https://github.com/cultleader777/EdenPlatform/commit/f2121ba0b8fdb541e6aacc62651acdd8724c0235

Now you can add custom secrets to the secrets.yml and also use those secrets in blackbox deployments.

Another thing I added is support for custom MX/TXT/CNAME records served by our DNS servers, I needed those because I don't have self hosted email yet so for now I'll rely on third party providers. People usually need those for domain verifications and so on.

I did quite a few bug fixes, but I already forgot what specifically.

Seems like I have over half million views on some posts, although when I upgraded SMF in this forum (not because I wanted, hosting provider broke some php function with php version upgrade and forum was offline) online counter broke down, which I'm not interested in spending time to fix.

Getting that many post views I'm glad that calling most leftist software engineers a bunch of faggots finally paid off. Feel free to register for the third user in this forum, bunch of lurkers, lol.

Have a good day bois.

Hello bois, I keep adding features to the Eden platform, things are breaky in the beginning
https://github.com/cultleader777/EdenPlatform/commit/c2d048609fb697ff43b7ac2a0e7e4db9051eac04

Breaking change:
1. tld was removed from region
2. in global settings you must pick the tld to use for internal DNS names
3. tld table has expose_admin field removed because global settings tld exposes admin, things are simpler this way

I added:
- custom environment variables or secrets to the blackbox deployments. This is needed if you, say, want to host database in Eden platform, and you need to expose private environment variable to PostgreSQL from app that users the database, you can do so now
- support for multiple TLDs, you can host as many domains as you want. This was intended to be supported from beginning but of course, there are issues before you actually test it, now it works
- ingresses for blackbox deployments, basically, you can expose blackbox service like wordpress blog or self hosted Jira under any subdomain and host it under eden platform
- you can disable dnssec for tld if the provider you bought domain from doesn't support dnssec

Some fields might seem like ad hoc, like basic_auth file field in blackbox ingress, but that is because I'm deploying features I'm now actually using in my businesses. Inevitably, if someone wants to use Eden platform they'll have to get their hands dirty because I don't think anytime soon I'll start writing thorough documentation, although we already have 777 tests.

Peace bois.

Hello bois.

I started building out my products with EdenPlatform on top of AWS. I started with only 4 servers, two datacenters for quorum, modest 8GB machines while having beefy bare metals at local DC.

It started out with 1000$ per month, which is already unbelievable as any decent VPS provider would provide such hardware at laughable ~15$ per box, which would be 60 dollars total. But whatever, as long as I could get EdenPlatform working with multiple datacenters, including AWS I figured its a proof of concept that you can easily connect expensive AWS cloud to other clouds or datacenters.

The cost was starting to run at unbelievable 2000$ per month for four servers. Some AWS fag would scream "visit cost explorer, yoo moost bee doin sumthin wraaang!".

Yes, I was doing something wrong - entrust my businesses with AWS in the first place. I will not bother with cost explorer and complex AWS pricing rules - thank you.

So, I added hetzner bare metal server implementation to Eden platform, took a week. https://github.com/cultleader777/EdenPlatform/commit/6da40c742c118454310d66d8402d20789e566597

Then, once I got it fully working inside Eden platform, it took me a day to migrate all of my infrastructure from AWS to Hetzner machines for which I'm paying laughable 200 dollars per month for all machines.

I migrated:
- Nomad servers
- Consul servers
- Vault servers
- Victoria metrics servers
- Alertmanager servers
- Minio servers
- Postgres servers
- Clickhouse keeper servers - the only one that involved manual action of reconfiguring peers

And I said goodbye to AWS overpriced garbage VMs by running terraform destroy with a perfectly satisfied smiling face.

Mind you, these machines have twice the cores and 8 times more RAM than AWS pile of garbage small machines have. They perform much better and are always snappy, not at the modest RAM limit barelly chugging like they were in AWS.

So, in my case, price reduction for hardware as not just 90%, I got a lot more powerful and cheap machines and I still have all the properties of Eden Patform, cost ratio is more like hundred times more expensive in AWS.

And AWS faggots will start screaming "but your database is not scalable, your queues are not scalable, your storage is not scalable!"

First and foremost, if you use RDS instance in AWS it is not scalable either. If RDS instance breaks down due to traffic, guess who needs to resize it? You. If kafka instance is no longer handling the load, who needs to resize it? You. If ElasticCache instance is too small, who needs to resize it? You. Who needs to setup prometheus exporters to these services? You.

There are very few AWS services that scale out of the box, like S3 and SQS, but cost of running any server in AWS is laughable. And if you use something like DynamoDB, where you're literally raped for every single request, if your traffic bursts you'll never get better price proposition than if you ran bare metal Postgres instance to begin with.

And guess what? Since I have OCaml programming language that generates EdenPlatform code I could easily code OCaml functions that could burst up compute from any cloud at any time with regarding metrics. This is not just some basic autoscaling like kubernetes, I can write OCaml code spin up entire datacenters and terraform code will be generated and backend application scaled to only compute machines. I have all the power in my hands to do any autoscaling strategy I want with EdenPlatform, even querying moon phases during compile time.

In the context of EdenPlatform, clouds like AWS or Google cloud are legacy systems. Temporary stops. You already have managed highly available Postgres with Patroni, you already have S3 (MinIO), you already have Kafka (self hosted NATS), you already have Analytics database (Clickhouse), you already have DNS (Bind), you already have redundant links across datacenters (Wireguard + BGP routing) and everything is set up in highly available fashion, any server can go down and I'm still happily chugging along. Not to mention everything is using rock solid NixOS to have reproducible state on all machines where you can rest assured operating system will be running a long time without any problems.

In 10 years time Cloud will be looked into as the biggest fraud in the history of computing. Maybe AI will be the first and cloud second, both are unbelievable frauds. Startups that serve 10 requests per second spend 100k on AWS while they could be serving the same for under a thousand dollars on normal hosting (if they also adjusted their mindsets to never run garbage of NodeJS and to run Rust programs instead). Today's DevOps practices will be looking like a clown show 10 years from now, when most hosted services will be run in self hosted manner and where compiler like Eden Platform will check 99% of mistakes for you and deployments will work the first time.

Dear AWS, I always hated you. You were overpriced, useless garbage from day one. And people who praise you are mindless imbeciles. Goodbye, and I hope I'll never see you again.

Good day bois

Hello boys, the time is ripe to release initial early version of Eden Plafrom.

I don't have 7 clouds, I have two out of 7, AWS and Google Cloud because most people use AWS anyway.

It's been a while, and after 72k lines of Rust implementation code I'm finally running in production and shipping features.

Things are still very early, things are breaky, there's very little documentation. Although, if anyone wants to figure out how it works there are plenty of tests of every feature.

So, let's list things that work:
- Backend apps
- Frontend apps (not well tested yet)
- Postgres queries/mutators/transactions
- Clickhouse queries/inserters/mutators
- Nats queues
- Tracing with grafana tempo
- Log collection with grafana loki
- Alerting with prometheus
- Hashicorp Consul
- Hashicorp Nomad
- Hashicorp Vault
- Automatic TLS certs with certbot
- Automatic wireguard VPN across datacenters
- Exposing backend app to any DNS record via a load balancer

So far as I'm building apps I need to touch Eden platform less and less. The same happened with Eden DB compiler, last major feature I added to EdenDB compiler was OCaml data modules and I don't remember last time I needed to touch it. The same slowly but surely is happening with Eden platform, the more and more I work the more I work on my applications and less and less I need to touch Eden platform.

I can already serve any html imaginable for the users so I can implement most of the websites out there. However I think the current most major features missing are self hosted email. I also want to add FoundationDB next year just to have one fast and reliable key value store in those very rare cases where you need one.

I don't plan to spend too much time on documentation, if you want to figure out behavior of certain table or feature, read `wiki` directory and also read tests on how all the features work, there are over 750 cargo tests in initial release as I usually try to thoroughly test every new feature.

So, from now on I'll keep building applications (which I'll never open source) on top of Eden platform and Eden platform only needs to keep maturing at this point.

Have a good day bois

Sup bois, I've added extremely powerful feature into EdenDB: OCaml data modules. What this allows to do is to define data in OCaml using typesafe generated constructs.

I did this a while ago in this commit https://github.com/cultleader777/EdenDB/commit/9270c3e42ab28410e8ba3018f76b4eea0b586da4 , just didn't get around to describing it yet until now.

Motivation? Eden data language is fast to parse but will never be as powerful as standard typesafe programming language.

For instance, if I want to define 10 similar nodes in a cloud, doing it with OCaml is trivial, run a loop and you're done.

People write an utter abominations like jsonnet, or they add hacks like count variable in terraform or for_each in terraform.

In reality we just need a good programming language to define our data and we don't need to learn useless garbage like jsonnet, or how to program in terraform (which is nightmare). Terraform output is just an assembly compiler later, we don't deal with it directly.

Here's an example.

Say, we have main.edl file


DATA MODULE OCAML "some-module"

TABLE test_table {
    id INT PRIMARY KEY,
    some_text TEXT DEFAULT 'hello',
}

And we have OCaml file at some-module/bin/implementation.ml

open! Context
open! Db_types

let define_data () =
  mk_test_table ~id:123 () |> def_test_table;
  mk_test_table ~id:123 ~some_text:"overriden" () |> def_test_table;
  ()


So OCaml allows us to define table data in OCaml. We didn't write mk_test_table function (generated). define_data function is required in the generated code. There's a some_text column that has default value if unspecified. If your OCaml file implementation mismatches schema it's a compile time error.

To someone who's used to the standard implementation of compilers that do very boring stuff, linking executables from explicit outputs this might not be trivial how it works. In fact, I don't recall any compilers that do anything similar to what is done here. If codegen step is performed, it is usually performed in some Makefile task before compilation.

So, this is how it works:
1. EdenDB compiler parses all .edl sources with includes
2. We first process table schema and their interconnections, any error there (non existing foreign key column and etc.) is EdenDB compiler error
3. Now we know all the schema that will be in EdenDB, we just didn't insert any data yet and didn't check foreign keys, constraints and etc.
4. At this point we actually run OCaml codegen for the OCaml data module defined at some-module.
   We generate: dune, dune-projec, context.ml, context.mli, db_types.ml, implementation.mli, main.ml and dummy implementation.ml if it doesn't exist yet.
   User is responsible for modifying implementation.ml file with his data, he can have other OCaml files with utility functions and everything.
   We assume that we use dune for OCaml.
5. Now we insert the EdenDB data that is defined in EDL
6. At this point, EdenDB compiler runs dune exec for data modules, reads json dump of defined data, and inserts data into EdenDB state according to the schemas
7. The rest of EdenDB checks are performed, like checking duplicate primary keys, foreign key existance on all of the data, whether it is defined in EDL, Lua or OCaml

I haven't seen any compiler do something like that so I thought it is interesting design. And I'm 99% sure, being 70k lines of code into Eden platform that this is how I will define my data at the end of the day.

So, Current eden platform pipeline:
1. Run EdenDB compiler, which runs OCaml data modules and defines data of all of our infrastructure. Basic database correctness checks are performed here
2. Eden platform analysis step, here we perform all the checks regarding our infrastructure, say if defined node ip belongs to the DC subnet, that we have 3 or 5 consul servers per DC and so on
3. Codegen step runs which compiles the rest of our project, including provisioning, postgresql migrations, nix configs, and gazillion of other stuff. There are files that user can edit manually in Eden platform in their project directory (mainly business logic of EdenDB applications).

Have a good day bois!

Working on Eden platform (at this point I have AWS and Google cloud talking together, and I did bunch of internal refactorings, NixOS root on zfs and etc. anyway, 5 more clouds to go until release), I thought, could ChatGPT ever be productive enough in maintaining infrastructure? Not that I haven't heard of it, I'm user of ChatGPT it as everyone else, but when I had actual problems in infra, I even tried giving it as much context as I could and it was next to useless.

In linux when running virtual machines, by default iptable rules apply to the vm guests, which should be disabled if you want your sanity. I've been debugging this for a day, and asked ChatGPT to guide me, with logs all server topolgy and contexts. For crying out loud, I've even pasted in the culprit - the ipables rules which were blocking the traffic and it didn't suggest me that iptable rules were at fault.

When I think about it, programming is extremely precise. Having never used FRRouting before to implement routing for Eden platform it was quite a pain to get networking working across clouds. For google faggity cloud I've spent a lot of time debugging why in the world L2 frame doesn't travel between the hosts only to find out google implements its own faggity andromeda abomination network which doesn't even support L2 traffic. Meaning, in google cloud you have to rely on their slow router garbage which can never be adjusted realtime in terraform and they suggest your to run your own bgp node to interact with their faggity router! All because they don't do L2 traffic. I cannot spend bunch of time dealing with faggotry of google cloud so I simply enapsulated traffic between eden platform datacenters (which could be any datacenter implementation) in IP GRE protocol so it would fly as L3 traffic.

I will not treat any cloud specially and use their special faggotry nonsense just to make nodes across clouds talk when I have public ips in every cloud, so I should be able to implement my own routing, no? Google cloud faggots...

So, anyway, when doing this complex networking, usually, a single configuration misfire and traffic is gone. There's no leeway for error. I even had to redo networking, abstract it to have attributes for datacenters and I had to write configuration simulation in tests so now that I have got to a working state I could freeze the configuration to know for a fact I didn't break anything.

Maybe I just like the pain, but I can't wait until the day emerges where all of the issues I've been dealing with simply become compile time errors in high level Eden platform data and I don't have to deal with such low level details and can focus on finally shipping suite of applications I want to build on top of Eden platform.

ChatGPT, even given all of the context, if it makes mistakes in single place things don't work. And every time I used it to generate even skeleton terraform configs I always have to run it and debug. There was not a single time where I pasted code from ChatGPT and it would just work, except for simple queries like write lua function that sums 1 to 10. Apart from these toy examples AI is next to useless.

So the only use for AI seems to be when you need to write a polite email, generate a picture, rewrite some sentences - anywhere where precision is not important. In software engineering precision is crucial.

Let me ask you one thing, would anyone use a library that does a memory leak one in a million times? No, it would be dismissed as garbage. You have to rigorously test it to make it usable in real world in production.

Some indian faggot said with a smug face "there are no programmers in 5 years". Sure, I guess there will appear a batch of people blindly copy pasting things from ChatGPT and they'll eventually still need a programmer to fix/debug the mess which they have made.

AI coding monkeys think from a very narrow short perspective. For some reason, AI fags cannot imagine producing programs any other way than there are gazillion repositories with different programming languages and you MUST parse and process all of that context before you can contribute. Someone is doing JavaScript with NodeJS? Parse and analyze that faggotry! Someone is doing Ruby, their app is full of bugs? Parse and analyze this faggotry too!

What I do with Eden platform is radically different. I'm looking down like I mentioned in another post. My data is defined in tables and columns. All columns are sequential in column store provided by EdenDB so analyzing data is blazing fast and can be parallelized to all cores. All applications are in Rust (I'll add OCaml if there is ever NATS support added, or I might expose Rust C library for OCaml to talk with NATS). So, in Eden platform you just add high level data, it is all compiled and analyzed and every application interacts correctly from day one. There is no longer need for NodeJS faggots or ChatGPT. To tell you whats wrong or to write many tedious tests. Currently, when writing app in Eden platform literally 900 lines of Rust get generated and I write 100 remaining which interact in typesafe manner with the rest of the ecosystem, making me literally 10x developer. I don't fear to interact with database/queues or other apps even without tests.

That is much more useful than some garbage generated by ChatGPT which may or may not work (usually didn't work for me). I want things to work the first time, with compile time errors knowing everything will work. I'm not interested in some probabilistic vomit I need to debug again and again and again.

Even if I'd let ChatGPT to write documentation I need to proof read it again anyway, but hey, at least it sticks to word vomit now!

Now, I still believe Eden platform will drastically reduce engineering power needed, but it will not be by producing random vomit that doesn't work - it will be code generation and compile time errors before shipping to production. That will be the big firing of Ruby and JavaScript monkeys, not ChatGPT.

Have a good day bois!