54 replies
20h27m
// ==================================================================
// 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.
When 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.
instead of "expression" you meant "exception", right?
In 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.
A 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.
How would this work if I need to update multiple variables?
Would I have to repeat the if expression twice?Depends on the language a bit, but a common feature in these languages is the tuple. Using a tuple you would end up with something like:
let (value1, value2) = if (condition) { (8, 16) } else { (16, 256) }
Or else you’d just use some other sort of compound value like a struct or something. Tuple is just convenient for doing it on the fly.
hah we gave basically the same example on the same minute.
I love destructuring so much, I don't know if I'd want to use a language without it anymore.
It’s actually so painful to go back to languages without destructuring and pattern matching.
As someone who writes a fair bit of c# making switch and if's into expressions and adding Discriminated Unions (which they are actually working on) are my biggest "please give me this."
Plus side I dabble in f# which is so much more expressive.
Same for me in the Scala vs. Java world, it's hard once you get used to how awesome expressions over statements and algebraic data types/case enums/"discriminated unions" are. But I haven't done much C# (yet) myself, could you clarify for me: does C# have discriminated unions? I didn't think the language supported that (only F# has them)?
The c# team is working on a version of them they are calling Typed Unions, not guaranteed yet but there is an official proposal that I believe is 2 weeks old.
https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
Cool, thanks for answering
Depends on the language. if you have destructuring you can do it all at once.
So like I believe you can do this in Rust (haven't written it in a while, I know it has destructuring of tuples)
let (a, b) = if (condition) { (1, "hello") } else { (3,"goodbye") }
.. save yourself an else :
int value1 = 128;
int value2 = 256;
if (condition) {
It’s only an acceptable workaround in the case of two conditions, but you’re still out of luck if you have >2 branches and no match expression.
You can technically do some craziness with nested ternary operators but they look awful and if you write them you will regret it later.
True, but I would have to categorize that as an unacceptable workaround haha
expression as-in s-expression (ex: lisp)
I'm assuming you mean "non-exception". Apologies if I assume incorrectly.
In case I'm correct, this is from Andrew Gerrand, one of the creators of Go:
The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about.
In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.
In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?
https://news.ycombinator.com/item?id=4159672
You appear to have misread "expression" as "exception"; this is completely unrelated. An expression-based language is one that lets you do `let blah = if foo then bar else baz`, for example.
i honestly struggle with this because its a "i know when i see it" thing, ex. here, const boo = foo ? bar : baz suffices which brings in ~every language I know.
My poor attempt at a definition, covers it in practice in languages I'm familiar, but not in theory, I assume: a language where switch statements return a value
Go doesn’t have a ternary operator, you are supposed to write something like
One of the many cases where Go’s designers decided they would ban something they disliked about C (in this case, complicated ternary operator chains), but thought Google programmers were too stupid to understand any idea from a more modern language than C, so didn’t add any replacement.(I’m not exaggerating or being flippant: Google programmers being too stupid to understand modern programming languages has literally been cited as one of the main design goals of Go).
The second you add a tenary operator people are gonna nest them, but the same is true for if/switch/match expressions unfortunately. I don't think they meant stupid literally, it's more like KISS philosophy applied to language design for maintainablity/readability/code quality reasons. Google employs some of the smartest programmers in the world.
Nesting them is not so bad if the syntax makes it obvious what the precedence is, which isn't true of C, but is of Rust for example.
Anyway, complicated code should be avoided whenever possible, true, but banning the ternary operator (and similar constructs like match/switch statements as expressions) does nothing to make code simpler. It just forces you to transform
intoA language where everything is a value. Yes, a switch statement could be considered a value. More specifically - these are expressions that can be (but don't necessarily have to be) evaluated into a value. The most practical and introductory example of this is probably Ruby (called case: http://ruby-doc.com/docs/ProgrammingRuby/html/tut_expression...).
Python, JS, Ruby all have facilities to do this to varying extents. For a "true" expression-based language you will want to look at something like Clojure.
https://en.wikipedia.org/wiki/Expression_(computer_science)
Yeah you nailed the limitation. Switch type expression that returns a value is a pretty universal feature in expression based languages, often in the form of a pattern matching based expression.
Check out the ‘case’ statement in elixir for an example.
In languages that support it, it usually becomes an incredibly commonly used expression because it’s just so applicable and practical.
A language in which matching on a structure is not a statement but instead returns a value; the special case of matching on a boolean (this is often spelled `if`); one which doesn't have a `throw` statement (but instead models it as a generic function `Exception -> 'a`, for example); etc.
The `if` statement is just less ergonomic than the ternary operator, because statements don't compose as well as expressions do. A language which has a lazy ternary operator, and which lets you use an expression of type `unit` as a statement, does not require an `if` statement at all, because `if a then (b : unit) else (c : unit)` is identically `a ? b : c`. The converse is not true: you can't use `if` statements to mimic the ternary operator without explicitly setting up some state to mutate.
I don't think he misread, because I also was puzzled. I had never heard of the term "expression" used in this way, and I imagine I'm not alone. I do greatly appreciate the clarification from you and jtsummers though. I knew of the distinction, but I didn't know of a term for it until today.
I used to be skeptical about introducing complex expressions to C-syntax languages for a long time until I saw how well Kotlin handled `when`.
Now every time I use typescript or go I have trouble trying to express what I want to say because `when` and similar expressions are just such a convenient way to think about a problem.
In go that means I usually end up extracting that code into a separate function with a single large `switch` statement with every case containing a `return` statement.
Yeah expression based languages are a pleasure to work with. A lot of what was good about CoffeeScript was absorbed into ES6, but the expression oriented nature of it was never fully replicated in JS/TS.
More to the point, the comment in the code mentions the “combinatorial” explosion of conditions that have to be carefully maintained by fallible meat brains.
In most modern languages something like this could be implemented using composition with interfaces or traits. Especially in Rust it’s possible to write very robust code that has identical performance to the if-else spaghetti, but is proven correct by the compiler.
I’m on mobile, so it’s hard to read through the code, but I noticed one section that tries to find an existing volume to use, and if it can’t, then it will provision one instead.
This could be three classes that implement the same interface:
The last class takes a list of IVolumeAllocator abstract types as its input during construction and will try them in sequence. It could find and then allocate, or find in many different places before giving up and allocating, or allocating from different pools trying them in order.Far more flexible and robust than carefully commented if-else statements!
Similarly, there's a number of "feature gate" if-else statements adding to the complexity. Let's say the CreateVolume class has two variants, the original 'v1' and an experimental 'v2' version. Then you could construct a SeqVolumeAllocator thus:
And then you never have to worry about the feature flag breaking control flow or error handling somewhere in a bizarre way.See the legendary Andrei Alexandrescu demonstrating about a similar design in his CppCon talk “std::allocator is to allocation what std::vector is to vexation”: https://youtu.be/LIb3L4vKZ7U
hahaha 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.
If 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.
There 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.
I 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.
there 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.
I 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.
I'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.
Same. Pods will crash, run out of memory, fail to get scheduled, etc... but I have never seen kube itself crash.
I'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
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).
You 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.
This comment is a complete non-sequitor. Kubernetes solves an entirely different problem from Apache and nginx.
yeah 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.
If you can solve your problem with nginx then yes you should be using nginx not kubernetes...
I 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.
If 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>...)
Swift's "guard" statement would be pretty handy here.
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.
No, "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.
"Else" is for when the if condition is false.
A resumable exception initiated in the "then" part of an if will not go to "else" when control resumes; it will go to the next statement after the if.
I did not say exceptions could be resumed (correctly 'restarted'); I said conditions could. Most languages with which I'm familiar do not have the latter.
One typically available restart is to ignore the condition and resume execution immediately after, as you describe. Another is to re-evaluate the form in which the condition was signaled. In that case, the conditional may well be itself re-evaluated with a different result, executing a different branch.
Someone has obviously simplified the code. Oops.
Yeah, I immediately scrolled down to see how silly I thought it looked, and.. it's not, there are plenty of ifs without elses. If you're going to have exceptions to that rule where it's 'simple' and not necessary, then congratulations you're using if (and else or not) just like everyone else?
I tried to link directly to these lines, but hn's url sanitizer stripped off the anchor tags.