nickmonad

> The part of programming that sucks the most is untangling ambiguity.

I think it could be argued this is exactly what programming _is_.

  Location: Midwest, USA
  Remote: Yes, preferred.
  Willing to relocate: For the right position and location!
  Technologies: Golang, Zig, Rust, C, Python, SQL, cloud infrastructure, observability tools (Prometheus, OpenTelemetry, etc)
  Résumé/CV: https://nickmonad.blog/about - Can provide full details on request!
  Email: my username @pm.me

Experienced engineer interested in all things deployment infrastructure, systems programming, observability, performance analysis, and advanced testing methods. I would be particularly interested in positions that involve systems programming (preferably with Zig!) and would welcome the chance to build out advanced testing infrastructure (fuzzing, deterministic simulation, etc). I have a lot of experience with cloud deployment infrastructure and love making complicated processes understandable, reliable, and repeatable. Most recently I've spent the past 2 years scaling out a complex BYOC/self-hosted deployment, building automation for packaging and verification. If you've got problems to solve at any intersection of the areas above, happy to chat!

My first exposure to Neal was through Reamde and it's definitely the fastest I've managed to get through a novel relative to length. I really enjoy his style.

Where is “soul” coming from here? It doesn’t appear once in the post.

While it may not actually matter for liability, it must be stated if labs are going to attempt avoiding penalties by hinting “oops we created a super intelligence we don’t understand, nothing we can do!” Repeatedly stating the truth must continue, especially to remind those who aren’t technologists.

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.

Speed doesn't mean anything if you end up driving off a cliff.

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.

If anybody is reading this and wants to hire somebody with said Zig experience, call me. (Link in bio)

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.

He's not.

> "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".

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)

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.