Incredibly happy to see this series of CF articles. I was always so proud of devs back in the days where RAM and processing were scarce and who had to get creative to fit even the most basic stuff in the budget. It seemed to me that after RAM and processing became abundant, most gave up on optimization and focused on shipping instead which meant now that even with several cores, a basic notepad or music player failed to work. In a way, RAM becoming more expensive has ushered in a new era of forced optimizations, which I'm really happy for
I don't remember those days with a ton of fondness. Yes, the challenge was fun, but I really wanted to ship it and get my product in the hands of customers. Now I can spend more time thinking about what they want and less time about what the computer wants.
The world turned millenia ago and will turn millenia later.
The problem statement is of applications using up expensive RAM. Incidentally, expensive RAM is just one of the problems we face in the computing space. Forced obsolescence is another, when running hardware needs to be replaced because software is built for only newer CPUs.
> The problem statement is of applications using up expensive RAM. Incidentally, expensive RAM is just one of the problems we face in the computing space.
You need to stop and think about the problem. Nowadays RAM is expensive because many people now want to max out their computers with RAM to run LLMs and AI coding assistants. Today's software is still the same software that ran perfectly well half a dozen years ago. Cloudflare happens to operate a large global computer infrastructure, and it's scale is such that 1% gains are lauded as fantastic cost savers. But that's the bean counter's perspective, pointing out that they saved a bean.
> Nowadays RAM is expensive because many people now want to max out their computers with RAM to run LLMs and AI coding assistants.
Source? I imagine the amount of people trying to run local LLMs is miniscule. RAM is expensive because a handful of companies have spent billions buying all of the compute.
> Today's software is still the same software that ran perfectly well half a dozen years ago.
This statement is quite honestly not true at all. Just take the two largest OS from 6 years ago and compare resource usage between them and you will find you are incorrect, never mind the software running on it.
You are right, but it reads (to me, could be just me) you mean newer specs which used to be true when I shipped software in the 70-90s; you mean faster machines / more memory right? Like installing a new version of software or OS and suddenly all memory is used, system is swapping and you did not ask for that but some obscure feature you didn't need needed to be shipped fast.
That statement can be used to justify anything, to the point it is utterly useless.
— Humanity has been on the decline. People are hateful towards each other, striking their fellow man and poisoning the environment. Despots eventually launched nukes which killed everyone but the cockroaches.
On the contrary. Industrial developing countries saw bigger % increases in their economic growth in the last couple of decades than the fully developed "old" western ones. Mostly due to "the rich" shipping western jobs there to cut costs and increase their margins.
For example the likes of Poland, China, India and Vietnam were and still are growing like crazy when you compare to the likes of UK or Germany.
> And its this obsession with shipping things as fast as possible quality be dammed (...)
You seem confused. Allocating more memory than optimal levels is not a measure of quality. Similarly, a web page is not suddenly lower quality if an image asset is 50kb instead of 25kb. And how much complexity and engineering effort and bugs are you willing to tolerate to halve your memory allocations?
You are conflating quality with mindless minimization, not even knowing or caring that are the tradeoffs. The blog post you're commenting on starts by presenting the case for celebrating small improvements, even 1% improvements at a time. A similar 1% improvement in a mobile app is at like 1MB. Do you ever notice it? How many hours of engineering effort are you hoping to spend on this nonsense? And you prefer to spend it on this or in actually fixing a bug or implementing a feature?
This puerile conflation of minimization with quality suggests your personal notion of quality has no bearing on what quality actually is.
> And how much complexity and engineering effort and bugs are you willing to tolerate to halve your memory allocations?
You seem to be confused about this relationship. It's usually exactly the opposite.
The wasteful applications are generally not well reasoned about and half assed implementations. That's why they're guzzling resources
There is ofc a middle ground, because targeting eg incredibly resource constrained embedded systems will naturally increase complexity, but that's something entirely different to the scenario this discussion was about up to this point.
Exactly, that`s why i refuse to call 99.9% of "software engineers" engineers. Imagine you optimize a aircraft turbine 1%....man you get to drink a pool of champagne with the highest ceo's and aircraft carriers try to buy that turbine as fast as possible.
But with software and a install base of some millions 1% optimization is seen as wasteful, its like software slop is acceptable since forever because hardware gets faster, and electricity is "green" anyway.
Resource constraints have historically been a bastion of quality engineering, though. The relationship is not directly causal, but any time an engineer must not only solve a problem but _fit it within some kind of a budget_ vs having an unlimited budget, it forces them to slow down and think more carefully about what they are producing and how well it actually functions.
Ultimately it is an expression of anti-fragility: some minimal challenge must be met and conquered on many different axes of a production in order to help the full production itself mature to the best possible quality.
It is the same reason we exercise, the same reason that cars and toilets and so many products greatly increase in quality after emissions and usage and waste-related regulations get applied from above, etc.
The appreciation of the refining force of outside limitations is not about min-maxing, but it is at least partly about curbing the min-maxing of other concerns such as "ship the fastest garbage possible to move on to the next opportunity to repeat that process".
Yes, I remember those too. The costs of manual memory management were real and were not low.
But costs on the cloud are real too, especially now. I’ve been living in JVM land for a very long time, but now it’s especially clear how important lean services are. Especially now that the bar for writing lean code is so much lower: let the borrow checker figure it out, etc.
I just spent a couple days wringing out more performance/memory efficiency for our services. Nice gains to be sure, but it’s still so immensely wasteful compared to something well written running native. If it was my money, I’d be going native for sure.
> But costs on the cloud are real too, especially now. I’ve been living in JVM land for a very long time, but now it’s especially clear how important lean services are. Especially now that the bar for writing lean code is so much lower: let the borrow checker figure it out, etc.
I don't think even Cloudflare bothers with this waste of time. If they did, they would certainly not have built their global infrastructure on JavaScript running on V8. They'd have done what Google and old-time Facebook did and built their whole infrastructure on low-level system languages, and hiring the world's leading minds on the subject to milk the last drop of performance from their hardware.
Even Google stopped to look at the problem and came up with Go. Not V8.
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
All those things happened before the era of decent AI.
Also, it really does matter what you're building. Yet another CRUD app? Don't waste time on (super) lean languages - use Go or something else you like and move on.
Building a Kafka replacement? Making something that processes gobs of data quickly? Perhaps think about using something lean and efficient, as the economics have changed. "waste of time" (or memory) also applies to the cloud and your (or your company's) bill. And if you haven't noticed, you're being ripped off on the cloud, running something 10-50x less efficient has real bottom line impact.
The vast majority of people do not care about memory efficiency on the levels we're talking about. I've never met a non-technical person who has cared. And out of the technical people that I know (which represent less than 5% of the population), no more than half of them have complained about the memory usage of an electron app.
Or, they care but they lack the vocabulary to express what they care about.
You can get a new laptop to run software A or competing software B.
You can pay $1000 for the laptop with 4GB of RAM, and software A either can't run on that or will act like pulling teeth, so that software requires you to upgrade to 16GB of RAM which will put you back another $2000.
Or you can run software B which will hum along perfectly smoothly on the original $1000 laptop.
(All of that of course simplifying right past "everyone runs every app 24/7 with five trillion browser tabs open")
Are you honestly suggesting that the end user doesn't care about having to throw exponentially more money at stuffing RAM into their PC just to make the game all their friends are playing online function?
> Or, they care but they lack the vocabulary to express what they care about.
That's speculative to the point of being conspiratorial.
> Are you honestly suggesting that the end user doesn't care about having to throw exponentially more money at stuffing RAM into their PC just to make the game all their friends are playing online function?
I'm extremely clearly not suggesting that. Don't make up things and pretend that other people said them. Engage honestly or not at all.
Customers often want to pay less, and shareholders often want lower capital costs. A tasteful optimization is a win-win. The opportunity cost should be traded off against new features of course, but tasteful optimization is a good thing for customers.
> In a way, RAM becoming more expensive has ushered in a new era of forced optimizations, which I'm really happy for
Isn't this mainly Cloudflare's scale though? That's literally also what's in the introduction written as the reason why they are doing the optimization
While it's nice to see this focus, while they highlight absolute figures, we are still talking about 1% improvement. For most other software systems, nothing worth putting effort in for.
During the Moore's Law years you didn't have to optimize much, if you did a significant release yearly computer hardware grew faster than your optimization problems.
I disagree. A lot of people do not care about public facilities. They do not believe in leaving things better than they found them. You've seen these people around, you know who they are. These are the same people that don't rerack weights at the gym or don't put the cart back at the supermarket. That attitude has nothing to do with income, housing, race, or activity they are interested in. It's simply a result of narcissism. The only way is stopping excuses and enforcing the public etiquette. The world will be much better off.
Sure, and thankfully there aren't nearly as many of them out and about abusing more things if they have a private place always available to spend their time. Conscientiousness is one of the handful of measurable personality traits, and there's a scale to it because some people have more of it than others. That's not going to change. What we can change is the degree to which less conscientious people are forced to lean on the conscientiousness of others around them in order to live every moment of their lives. The collapse of social safety net—pilfered in order to pay for mega yachts and renting entire cities for a wedding receiption—in the West and particularly the US pushes those less conscientious people out into the world all the time.
Super fun! Interestingly, this is how JPL was able to significantly reduce the Mars 2020 landing radius on Mars. Cameras onboard take pictures of the terrain and match that to maps to figure out where the lander is. https://www-robotics.jpl.nasa.gov/what-we-do/flight-projects...
Thank you for building this, looks like it could be really helpful. We've been running our self-hosted GitLab with almost 99.99% uptime and a few runners but the configuration and update process has been a bit cumbersome. Will take a look at rocket runner.
99.99% uptime is impressive! So far our runners are likewise very reliable! It's just a Hetzner machine with our stack on top after all. Thanks for trying us out and please drop us an in-app message for any questions or comments!
Yeah I don't really understand their insistence on these videos. I don't have the time to watch an incredibly hard to watch present babywalk me through the code, hoping I'd catch one modifier I missed that fixes the issue. Just write some docs for god's sake.
They update the docs every year. The videos are for people who want a demonstration instead of reading docs and trying things manually to see the result.
SwiftUI was doomed from the beginning. Not only Apple completely blew the implementation, it was actually DoA by a bunch of super bad decisions that ultimately make it incredibly hard to work with and manage, especially on bigger apps.
1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each modifier doesn't actually modify the main view but it modifies what the modifier before it decided to return. This makes no sense as the modifiers should each be modifying the main view to make everything predictable and easy to debug. I'm convinced no one (not even senior devs with 5 years of SwiftUI experience) understands how the ordering of modifiers works. It's just swap them until it does what you want it to.
2. The view lifecycles and code execution path seem random and hidden behind layers of "magic," making it incredibly difficult for developers to trace and debug issues.
3. It is practically impossible to set breakpoints for rendering and view construction, it's impossible to really figure out when re-renders happen and what drives them. I'm convinced SwiftUI apps are incredibly slow not because the SwiftUI implementation itself is slow, it's because, even Apple's own apps probably do a bunch of unnecessary re-renders and one no one seems to have any idea. This is unfortunately another design issue that can't be solved by just making SwiftUI more efficient. It requires simplification and tooling to help developers not footgun themselves.
4. Lots of issues start appearing later on in the development cycle because, for simple apps, bad SwiftUI design decisions and footguns have unnoticeable effects, until the apps gets more complex and things start breaking. Fixing these issues sometimes requires rewriting whole features or spending hours debugging.
5. There seems to be almost no documentation on Liquid Glass. It's laughable that after more than 1 year, Apple has simply refused to document or provide good examples for Liquid Glass, except for maybe couple pages that resemble the brain dump of an engineer that has never passed a writing class in college?
6. Stuff seems to be rapidly changing and breaking from version to version. It took days to make my app look and work the same in iOS 27 as it did on iOS 26, even though iOS 27 is supposed to be a minor bug fix release. We don't even use anything non-standard and don't do any hacks. This defeats the whole purpose of a simple UI framework that can be easily adopted to different platforms (this never used to happen with UIKit).
7. View debugger still has no SwiftUI equivalent. It used to make things so much simpler in UIKit when you could just see the view bounds, pick views apart and understand what's actually happening. SwiftUI has no equivalent other than `.background(.red)`. Terrible.
I don't know how Apple can salvage this beyond just undoing some of these terrible design decisions and making it 1. super simple to work with, 2. stop relying on magic, making things more explicit, and 3. providing actual 1:1 UIKit feature parity.
1. It's not really the builder pattern, which, in Java, is what you describe as wanting: mutating a single instance. SwiftUI uses result builders to compute a single generic View from the "DSL", but you could do the same thing without the custom syntax, it would just be more verbose.
2. Documentation issue. The lifecycle is standardized, but Apple is terrible as documenting it all in one place. I found this year's "Dive into lazy stacks and scrolling with SwiftUI" WWDC video actually had a pretty good explanation, at least for the lifecycle within lazy containers.
3 and 7. Yes, Apple's tools suck pretty bad. Preview canvas is also still terrible, despite multiple attempts to improve.
4. Not something I've experienced, not sure what you mean.
5. Yeah, Apple's docs suck.
6. Not sure what you mean here either, our stuff looks pretty much the same.
Apple seems to be loved by users, but hated by developers (and for good reasons). They just seem to not give a shit about the developer experience.
You mention some examples, I have experience with lower-level stuff: terrible. Poorly documented, and actually not really working well.
IMO they should focus on improving the developer experience instead of wasting money on the joke that is Liquid Glass (even users don't like it, right?). But anyway, too late for me: I'm soooo happy that I can develop iOS apps in Kotlin now, and just endure Xcode for building and occasional debugging.
They used to care about developers. Peak cocoa and uikit was a thing of beauty and objc remains my favorite programming language of all time. When Swift came along i tried and was dissapointed and then a decade later i gave it another whirl and was shocked it was still so bad. The hardware has gotten better, but the software clearly not.
Just a couple points because your opinions aren’t wrong, they’re just your lived experience.
2. There’s no magic here. There is poor documentation. The biggest trick — small views, think about what values are going to trigger a refresh. Avoid cascading view refreshes.
6. You might have missed a couple big iOS releases (iOS 7 was one to remember) where many of our apps fell over in UIKit. Swift was another ‘DOA’ for YEARS with the same issues you’re making here, each new version broke the old, but here we are in a day and age where it’s the standard.
The magic is when you use things like @State or @Published and system does bunch of things hidden behind the scenes that the developer has no idea about. Then, when issues arise, the developer is unable to debug because they have no idea how these things work and what they really do.
The author spends the first paragraph of the article talking about how n number of users bet x on a specific outcome and they won. They fail to account for the many others who bet on a different outcome and lost.
I watched polymarket like a hawk for weeks before the attack and am incredibly familiar with the numbers. Fact is, there were no indications on Polymarket that an attack was happening that morning. The chances of an attack was like 10 percent if I remember correctly.
Right, the probability pre-attack never broke even 30%, which was basically in line with the most prominent opinions. The market consensus had been for a long time that there would be an attack by this summer or the end of the year, but probably not near-term. There will always be some bull traders who buy just before a big move in the market, that's no proof of insider trading.
Give people enough time, and they'll start figuring out more and more ways to try to predict the markets given observations of the real world. Some will fail, but some will definitely succeed.
reply