6 ms·
// ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE
by jftuga 2y ago
// ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ==================================================================
//
// This controller is intentionally written in a very verbose style. You will
// notice:
//
// 1. Every 'if' statement has a matching 'else' (exception: simple error
// checks for a client API call)
// 2. Things that may seem obvious are commented explicitly
//
// We call this style 'space shuttle style'. Space shuttle style is meant to
// ensure that every branch and condition is considered and accounted for -
// the same way code is written at NASA for applications like the space
// shuttle.
- wouldbecouldbe 2y agohahaha well Kubernetes is the opposite of a special shuttle that keeps on flying. It crashes all the time, version updates etc. If you want stability go to apache or nginx.
- Sohcahtoa82 2y agoThis comment is a complete non-sequitor. Kubernetes solves an entirely different problem from Apache and nginx.
- deleted 2y ago[deleted]
- wouldbecouldbe 2y agoyeah maybe it does, but when you have a hammer everything looks like a nail. Kubernetes is used all the time nowadays on simple projects just because it's the most intellectual pleasing solution. This is creating high maintainance costs by locking in companies with extremely complicated software where it's just not needed.
- andix 2y agoI've never seen Kubernetes crash. I don't have that much experience with operating k8s clusters, but on those I've seen it just kept on working.
- whalesalad 2y agoSame. Pods will crash, run out of memory, fail to get scheduled, etc... but I have never seen kube itself crash.
- q3k 2y agoI've been experimenting with k8s and/or running it on prod basically since the initial release, and I've so far only had one workload-affecting bug. The bug caused the scheduler to get stuck meaning pods assigned to nodes kept running, but no new pods would be scheduled. https://github.com/kubernetes/kubernetes/issues/124930 https://github.com/kubernetes/kubernetes/issues/124930 That's a pretty good track record, and indicates a level of fail-safe design (everything continued working, even though a critical components kept crashinglooping).
- kesor 2y agoYou obviously have not operated kubernetes long enough. With large enough scale you'll find the cluster controllers crashing for various reasons, getting out of sync with each other, etcd crashing or getting locked, and a whole bag of bugs.
- OJFord 2y agoIf you can solve your problem with nginx then yes you should be using nginx not kubernetes...
- nimih 2y agoIf you think nginx is the right tool for solving problems like container deployment, service discovery, cluster scaling, and secret management, then I suppose it's not surprising that you think Kubernetes "crashes all the time" and that a 1 year rolling support window for software releases is an insurmountable obstacle. Kubernetes has a lot of genuine issues and rough edges, but you're kind of showing your ass when you make comments like this.
- wouldbecouldbe 2y agoThere are just very few applications that actually need all of this. maybe 1 tot 0.1%, for instance vercel might need it. But 95-99% can just run on several "simple" servers & keep deployment times within minutes and no complicated stuff needed. Yet Kubernetes get's pushed all the time.
- lyu07282 2y agoI don't know about that, I've found even simple applications need things like blue/green deployments and kubernetes makes that very easy and robust.
- wouldbecouldbe 2y agothere is nothing easy or robust about kubernetes. Hence all the tooling around it, having things break down if you don't update. Dependencies not being compatible all the time. Server management should cost as little time, and be stress free. There are many ways to solve the up/down issue and depends on which language you are running.
- lyu07282 2y agoI agree if you are running kubernetes yourself you are absolutely right. I was thinking more about managed clusters in the cloud. Every provider offers managed kubernetes, then you aren't even vendor locked.
- whalesalad 2y agoI tried to link directly to these lines, but hn's url sanitizer stripped off the anchor tags.
- arwhatever 2y agoWhen I looked into Go I found it a bit surprising that someone had created a non-expression-based language as late as ~2009. I have not familiarized myself with the arguments against expression-based design but as a naive individual contributor/end-user-of-languages, expressions seem like one of the few software engineering decisions that doesn't actually "depend," but rather, designing languages around expressions seems to be unequivocally superior.
- TurningCanadian 2y agoinstead of "expression" you meant "exception", right?
- whalesalad 2y agoexpression as-in s-expression (ex: lisp)
- Jtsummers 2y agoIn the statement/expression-oriented axis of languages, Go is a statement oriented language (like C, Pascal, Ada, lots of others). This is in contrast to expression oriented languages like the Lisp family, most, if not all, functional languages, Ruby, Smalltalk and some others. Expressions produce a value, statements do not. That's the key distinction. In C, if statements do not produce a value. In Lisp, if expressions do. This changes where the expression/statement is able to be used and, consequently, how you might construct programs.
- runevault 2y agoA simple example for anyone who might not appreciate why this can be so nice. In languages where if is a statement (aka returns no value), you'd write code like int value; if(condition) { value = 5; } else { value = 10; } Instead of just int value = if(condition) {5} else {10} Some languages leave ifs as statements but add trinary as a way to get the same effect which is an acceptable workaround, but at least for me there are times I appreciate an if statement because it stands out more making it obvious what I'm doing.
- supportengineer 2y agoI went right into the code and looked for 'if' statements without 'else' statements. There are plenty. I don't see how you can have any exceptions to this rule if you are truly committed to capturing all branches.
- throwanem 2y agoIf the 'if' condition matching always results in a thrown exception, a return, or likewise, then you don't really need an 'else' unless you're using a language which supports conditions and resumption (conformant Common Lisp implementations, and not really anything else I know of). The 'else', implicitly, is that the flow of control leaves the scope of the 'if' block at all. (I haven't read far enough into the code to know that this is what they're doing, but the head matter I did read suggests as much. It's a common enough pattern, especially around eg argument validation and other sanity checks a function might perform to ensure it can do meaningful work at all.) (I do wish HN supported an inline monospace markup, the <code> to a four-space indent's <pre>...)
- iainmerrick 2y agoSwift's "guard" statement would be pretty handy here.
- drewcoo 2y agoif (foo) { bail out } They're known as guard statements regardless of language. https://en.wikipedia.org/wiki/Guard_(computer_science) https://en.wikipedia.org/wiki/Guard_(computer_science) Swift has a guard keyword, but the construct feels a little awkward given most languages do the above. It makes me do a double take. guard !foo else { bail out }
- iainmerrick 2y agoNo, "guard" in Swift is special. Once you're in the "else" block, you MUST return or call a non-returning function (e.g. abort). It's specifically designed to prevent bugs where flow control accidentally resumes from an error handler. It's the same idea as the "every 'if' must have an 'else'" guideline in the code being discussed, except with "guard" the compiler will detect violations. It's a good thing.
- deleted 2y ago[deleted]