Your comment feels like one I would have written in my past, but I think there is some possible context or understanding I might be able to share based on some

Your comment feels like one I would have written in my past, but I think there is some possible context or understanding I might be able to share based on some of my XP. >No bigint OID, or worse, not UUIDv4, because even int64 will overflow, maybe not on their platform, but on a platform with millions of new inserts a day, despite being a large number, isn't future proof. If anyone knows a better 128bit alternative to UUIDv4, please respond. Sane defaults are important. If the DB defaults to a particular value it's likely because it's fine for most use cases. It's an excellent thing to have enough customers and utilization to require something more than int for an ID. That said if there is little to no performance difference, I'd argue that this should be made the default upstream rather than the default recommendation or "best practice." >Thinking 5 steps ahead is what I had to learn along the way, because if you don't you end up with problems like these. Not every one is able to do that kind of systems level thinking across an entire product stack, and that's OK. What's more important is not building things you will never use, or might use one day but don't need today. >I'm a follower of the holy church of K.I.S.S. keep it simple, stupid. Simple and organized, the 2 key pillars of good design. As simple as possible, but not more simple. Thinking 5 steps ahead is the hard and time consuming part. I would spend more time thinking about how to market to folks who want to reduce their cloud investment. My current org is way over engineered both in infra and engineering in general. We have been working to reduce complexity and cost and it's had real big wins for us as an org. KIS is an excellent philosophy when applied pragmatically. >I know this article is about Ruby. The author could have replaced ruby with "Language-X" and the article would have been just as accurate. It's often not the language that's slow, more often it's the DB schema, data models, and business logic. > But as a Go zealot, which can handle 500 million visitors per month or over 5000 concurrent http1.1 connections on a 13 year old 4 core 32gb ram computer If all it has to do is reply "Hello World" plenty of languages and frameworks could hit similar numbers. But if all those frameworks are blocked by a de-optimized external request, it doesn't matter. Here, the authors app was def having DB scaling issues, this could happen with any language, runtime, or framework. It will happen sooner with certain combinations than others yes, but utilization and customer feedback are more important than early optimization. >This guy's problem is that he believed the hype, picked the wrong tool for the job and had no clue about infrastructure/operations. I think that's a harsh assessment. We all buy into some hype, and we all generally try to make the best decision with the information we have at the time. Instead work backwards, put yourself in the authors shoes, assume the idea at the time made sense, and then ask "What had to be true, or seem true at the time, to reach the conclusion they did?" >There's a reason why Ruby isn't as popular as it was 10-15 years ago. Performance matters. It matters, until it doesn't. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/ as an example, we see top spot held by a known "slow" language (certainly comparable to Ruby). JavaScript, PHP, and VB all beat out Go in utilization. Performance matters, is a statement that requires context. Sometime the "performance" of your developers matters more than your runtime. >With Go and ent I start wherever I want and I get ×100 the performance. If I need to consume the data, if I don't care about SEO, I can write a SPA easily and the load is on the client. And now the current trend is to start to reduce the amount of load on the client because turns out 2Mb of JS to render an SPA is not the best XP on a lot of devices and networks. It's important to understand who your users are, and the operating context they bring. >And should you magically expect more than 500 million visitors per month, simply adding load balancing and doing this for the database as well would do the trick, BAM, you've now tripled the amount of backend requests you can handle. Horizontal scaling isn't dependent on language. You need to design your API and choose your persistent storage correctly to make this task easy. But in reality, most folks could just use caching and be fine. >Your Ruby on Rails app might be good enough for a PoC, but that's about it. Based on what, your personal opinion? It's a perfectly fine language for a back-end service and I say that as someone who has no interest in learning Ruby. >If you really expect large volumes of traffic, better pick a well performing language from the start and think about infrastructure. Maybe. We use scala at work, because "it can handle large volumes of streaming data" and yet it's some of the slowest parts of our stack because it's hard for folks to "do right." Sometimes you need a language who's feature is easy to use and hire for. >And for the love of god, don't pick k8s. Because when shit hits the fan, you won't be able to debug it. Keep it simple and transparent. Yes and no. K8s is basically the next generation of LAMP for the cloud. It's fine, just understand what you are investing in and what it isn't. We use aws at work w/o k8s and it's a complex nightmare to manage in some respects. My k8s cluster at home however is fantastic and fun to tinker on, and causes me less stress with more uptime than my AWS clusters at work. I think it's more important to understand the problem space, and how a tool might fit in or not, than to hope it just solves problems magically. The cloud isn't magic, it's just someone else's computers.