TigerStyle is strictly concerned about dynamic allocation from the perspective of the OS.
Once you have that pool of "objects" that can be recycled throughout the lifetime of the program, you have a guarantee that actual allocation can only be interpreted in a specific way, i.e. all objects have the same size, alignment, etc so you don't have nearly the same level of concern or detail of implementation as an actual allocator in the common understanding of the word. A simple free-list gets you pretty far.
Unless you explicitly prevent it, the kernel might swap out lesser-used parts of your object pool, dedupe pages, and so on. Accessing that page again may be much slower and potentially fail due to OOM.
To actually control all dynamic behavior you need to go deeper into the system, locking pages into memory etc.
Evidence so far does not suggest people driving off a cliff so while a valid concern it's not a likely one. We also acknowledged that the benefit of using a vehicle is such that it outnumbers the risks it may introduce. We never said there will be no risks attached.
We’ve only been on this train for 3-4 years, and in that period, we’ve already invented terms for this kind of vibe-coded, highly-breakable crud. We’ve also had a few, relatively high-profile in their spheres bugs come out and hurt people’s real, lived experiences.
And that’s just the stuff where the house of cards failed quickly.
Software by definition has always been and will remain broken in one or another way. AI makes no difference or whatsoever. Arguably, it will help raising the quality of software.
I work on a pretty large BYOC deployment that we market as such, but is squarely in the "self-hosted" / on-prem model. We don't maintain any connection back to our environment and updates are driven by customers. It's pretty difficult for all the reasons you can likely think of.
This space is quickly becoming a bit saturated, as these "BYOC enablement" tools and platforms are starting to crop up, and I can see the value in them, but my experience doesn't always line up with it. I'm actually really interested in hearing about a large enterprise running vendor code that would even entertain the idea the vendor could automatically update the entire deployment without their direct involvement. Our platform is quite load bearing for our largest customers, and in some cases directly in their revenue stream. There is no way they would ever let us push updates without going through their own internal controls of validation, testing, and sign-off. One could definitely argue these controls aren't entirely founded in reality, but corporate reality isn't always the reality you and I might share.
Besides the issue of automatic updates, we struggle with wild configuration differences that need pretty direct involvement with the customer. Security groups in AWS are just one example of this: some customers allow all internal VPC traffic between services, and others are quite strict in that every service needs a perfectly scoped security group with inbound/outbound rules. These have to be provisioned with their own tools built by their own teams under their own version control. We just ask for a configuration file in a well known location that defines these IDs we can reference in the CloudFormation.
So knowing that we essentially have to operate in the self-hosted model, CloudFormation becomes our mechanism for defining consistent deployments. For us to switch over to something like k8s just to fit into the model a BYOC-enablement tool like this wouldn't be worth it.
I think the most important aspect here though, and the most subtle one, is the issue of deployment and operational complexity. For BYOC to work well, the vendor really should be designing for it from the beginning. Taking an existing multi-tenant SaaS architecture and shoving it into this model, even with the ideal BYOC vendor-maintains-control-plane scenario is no small task. Even when you're talking about large enterprise BYOC deployments, you may only have a few thousand daily active users, which is dramatically less than what most SaaS vendors design for when operating in their own multi-tenant environments. ("Web scale" and all that.) At that point, I think engineering teams need to take a serious look at their architecture, and realize just how far they can get with fewer services, fewer machines, and fewer "event driven" architectural decisions. The deployment model _should_ be a forcing function for simpler architecture and system design, but I realize that's not a given. I think what I'm trying to say is that, knowing BYOC done well requires designing for it from the beginning, a well understood daily load profile and operational context kind of eliminates (or at least dramatically reduces) the need for tools like this, and that self-hosting isn't the worst possible outcome.
I agree, I work on an "airgapped" BYOC system as well, that runs on data lake providers mostly, and it's a bit of a nightmare because each customer has their own labyrinthine network setup, their own way of ingesting data (as much as we try to be prescriptive, some of them just insist on doing it their way), vastly differing scales and shapes, and sometimes their own secure communication tooling to even read the emails describing the problems they have. It's basically shrinkwrap software.
We're moving away from it as much as possible lately for all but the biggest customers with the strongest isolation needs.
I am also struggling with coworkers thinking they can cowboy code some LLM written features into these codebases recently, not understanding the level of human verified testing that needs to catch all the manifold edge cases and weird decisions in their usage. An update that causes crashes is much harder to catch when you can't do slick blue-green deploys and similar things to roll out updates.
> I'm actually really interested in hearing about a large enterprise running vendor code that would even entertain the idea the vendor could automatically update the entire deployment without their direct involvement.
A better word than "involvement" is "knowledge." We operate BYOC installations of managed ClickHouse and allow customers to pick upgrade windows. It's not that different from doing upgrades yourself. It's also important to remember that SaaS products upgrade without user intervention and often without user knowledge. That's one of the characteristics of the SaaS model.
> I think the most important aspect here though, and the most subtle one, is the issue of deployment and operational complexity. For BYOC to work well, the vendor really should be designing for it from the beginning.
This is definitely correct. We made a design decision early on that environments for managed databases (i.e., the data plane) are dedicated Kubernetes clusters for each tenant. Data plane services fit in the single K8s cluster and can be installed in 20 minutes or less over the network.
The Omnistrate article makes a great point that there are different flavors of BYOC depending on how much control users want. We have two variants: (a) fully managed stack in its own VPC where we install and run everything and (b) managed databases on user-supplied Kubernetes.
The operational challenges that you highlighted with BYOC makes sense and they need to be addressed.
- On upgrades, agree that “vendor managed” shouldn’t mean “the vendor can push arbitrary code whenever it wants” especially with the supply chain risks. Our experience is that vendor should make the new upgrade available and notify the customer, customer can run its change-control pipeline and approve the version, the control plane automates rollout/health-check/rollback, etc. To your point, automation only removes the operational toil but not the governance.
- Same with the networking, IAM, etc. A BYOC platform can’t always assume it owns the customer environment or one size fit all. Some customers will let you provision everything; others will insist networking/security infrastructure comes from their own Terraform/CloudFormation pipelines and give you IDs or interfaces to consume. I think a good BYOC model has to make that boundary explicit.
- Also, rewriting your app onto Kubernetes just to fit a BYOC platform would be backwards. Agree that the BYOC tooling should adapt to existing application architecture, not dictate it.
I am not sure if simplifying the application removes the need for this tooling as much of the complexity lies with establishing the enterprise trust boundary across accounts with things like identity, networking, permissions, artifact approval, upgrades, drift, auditability, governance controls, and eventually exit. This website tries to cover it in detail: https://byocanywhere.org/, WDYT?
Finally, I feel that there is a value in shrinkwrap software deployment model especially if one has the requirement of a relatively small number of very large, disconnected installations, and high-touch support. BYOC model make more sense if you want to scale or customers like to preserve customer control and managed experience like Databricks, Anyscale, Snowflake..
> Our experience is that vendor should make the new upgrade available and notify the customer, customer can run its change-control pipeline and approve the version, the control plane automates rollout/health-check/rollback, etc.
As it stands today, we have an AWS-only product (for better or worse) so we can accomplish this already with CloudFormation. It's not the best "control plane" as far as updates and rollbacks go, but it works pretty well for our needs. Obviously, trying to do the same across multiple cloud providers, would mean bringing in a different tool. At that point, the vendor's architecture would need to be neutral as well.
> I am not sure if simplifying the application removes the need for this tooling as much of the complexity lies with establishing the enterprise trust boundary across accounts with things like identity, networking, permissions, artifact approval, upgrades, drift, auditability, governance controls, and eventually exit. This website tries to cover it in detail: https://byocanywhere.org/, WDYT?
I think that website is a solid resource. Those are certainly important issues to solve that all surround the actual vendor code itself, and I can see value in making an attempt to solve it. It's just my experience that every customer wants to do it differently. I'm just not sure how much slower and painful our contract negotiation would have been if we had to also sell them on a particular process other than "you provision these things with your own tools, and we'll hand you CloudFormation templates". Maybe other companies offering BYOC are better at selling the whole package, not just the "platform" itself.
One nuance on the air-gapped / shrinkwrap end of the spectrum that I was thinking about afterward is that there is a difference between “no connection back to the vendor” and “just ship binaries and scripts.” One can also imagine shipping a local control plane with the product so provisioning, health checks, upgrades, rollback, etc. still follow a consistent operational model entirely inside the customer boundary. There are several examples in the industry that take this route as well. Obviously that doesn’t remove the enterprise change-control problem — updates to that local control plane still have to go through the customer’s own approval/import process. It just gives you a bit more operational consistency than traditional shrinkwrap software.
I'm not as interested in game development but I'm one of these web/cloud people who finds graphics work extremely therapeutic. I made a box move around on the screen with various easing animations and it was some of the most fun I've ever had programming.
I haven't written any serious Rust in a while, but I assume there is some kind of lifetime annotation involved. The "objects" allocated in the arena have to be explicitly given the same lifetime as the arena itself. I have no idea how that looks syntactically.
> "There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit. Quite simply they put in the time to find and eliminate the bugs, they make an effort to maintain a healthy relationship with ZSF, and Bun did not do that."
The reference to TigerBeetle is important, and a bit under-explained for the point he's trying to make. They have consistently attributed things like design and deterministic simulation testing to their success and reliability, which has nothing to do with Zig as a language. Some things might be _easier_ in Zig, such as static memory allocation, but ultimately, a holistic approach brings success, not one individual tool used "right".
Zig still offers a lot of great additions that make systems work more reliable. Optionals and comptime are two helpful things C does not have, and there are plenty others. One of their core devs addressed this in a thread over on Lobsters [1]
> Bounds checks, checked arithmetic, strongly-typed alignment, strongly-typed error codes, tagged unions, explicit undefined are some rather important language features. If Zig didn't exist, TigerBeetle would probably have been written in C, and the safety gap between C and Zig is just gigantic. And safety is one aspect of the language, Zig has a lot of going on for it elsewhere!
Andrew doesn't strike me as someone who does any marketing at all. He just wants to make the language he wants to use, and does it well.
Sometimes its just right time, right place. But also, Zig has received attention via projects like Ghostty, TigerBeetle, and Bun (prior to rewrite of course)
I believe I read a post by Andrew detailing how he intentionally did marketting in a way to attract users, the right contributers, and donations - he was quite intentional about making his full-time role sustainable (and now more roles).
They have definitely done a lot of marketing through social media and forums like HN. There have been large numbers of posts here by Zig's developers for years, and a few releases of LLVM even mentioned Zig prominently in their release notes.
Yep. He mentioned recently in his JetBrains interview he wants Zig to be a language for the next 50 years. Rushing 1.0 for the sake of signaling to the wider industry today would be actively harmful to that goal.
Too bad it will not be adopted for anything serious in the next 50 years. There is no reasonable value proposition from a business standpoint for picking zig over rust. It is already the reality in much of the tech industry that Rust is filling the space previously occupied by C++. The fact that there now exists a safe low level language is legitimately a paradigm shift. It doesn't matter how many shiny cool things zig adds, being unsafe means it a technology stuck in the past.
Once you have that pool of "objects" that can be recycled throughout the lifetime of the program, you have a guarantee that actual allocation can only be interpreted in a specific way, i.e. all objects have the same size, alignment, etc so you don't have nearly the same level of concern or detail of implementation as an actual allocator in the common understanding of the word. A simple free-list gets you pretty far.