Deterministic compilation, aka reproducible builds, has been a basic software engineering concept and goal for 40+ years. Perhaps you could provide some examples of compilers that produce non-deterministic output along with your bad news.
He is a software engineer with a comp.sci masters degree with about 15 years industry experience with primarily C++. Currently employed at a company that you most likely know the name of.
> I'm coming to the view that Rust mostly requires less cognitive load than other languages.
This view is only remotely within the bounds of plausibility if you intended for "other languages" to refer exclusively to languages requiring manual memory management
- `&mut T` which encodes that you have exclusive access to a value via a reference. I don't think there is any language with the same concept.
- `&T` which encodes the opposite of `&mut T` i.e. you know no one can change the value from underneath you.
- `self`/`value: T` for method receivers and argument which tells you ownership is relinquished (for non-Copy types). I think C++ can also model this with move semantics.
- `Send`/`Sync` bounds informing you how a value can and cannot be used across thread boundaries. I don't know of any language with an equivalent
- `Option<T>` and `Result<T, E>` encoding absence of values. Several other languages have equivalents, but, for example, Java's versions is less useful because they can still be `null`.
- Sum types in general. `Option<T>` and `Result<T, E>` are examples, but sum types are amazing for encoding 1-of-N possibilities. Not unique to Rust of course.
- Explicit integer promotion/demotion. Because Rust never does this implicitly you are forced to encode how it happens and think about how that can fail.
All of these are other ways Rust reduce cognitive load by encoding facts in the program text instead of relying on the programmer's working memory.
In languages like Java their version of the Billion Dollar mistake doesn't have arbitrary Undefined Behaviour but it is going to blow up your program, so you're also going to need to track that or pay everywhere to keep checking your work - and since Rust doesn't have the mistake you don't need to do that.
Likewise C# apparently doesn't have arbitrary Undefined Behaviour for data races. But it does lose Sequential Consistency, so, humans can't successfully reason about non-trivial software when that happens, whereas safe Rust doesn't have data races so no problem.
Neither of these languages can model the no-defaults case, which is trivial in Rust and, ironically, plausible though not trivial in C++. So if you have no-defaults anywhere in your problem, Rust is fine with that, languages like Go and Java can't help you, "just imagine a default into existence and code around the problem" sounds like cognitive load to me.
The problem Cloudflare had, and from what it seems, still have is that they don't actually test software at small volumes before global deployment. I would guess that two outages in quick succession means the voices saying "You need to test everything properly" might win, but perhaps not.
The Billion Dollar mistake is about not even having the distinction shown in the commit you linked. In languages with this mistake a Goose and "Maybe a Goose or maybe nothing" are the same type.
> DevOps was a reaction to the fact that even outsourcing ops to AWS doesn’t entirely solve all of your ops problems
DevOps, conceptually, goes back to the 90s. I was using the term in 2001. If memory serves, AWS didn't really start to take off until the mid/late aughts, or at least not until they launched S3.
DevOps was a reaction to the software lifecycle problem and didn't have anything to do with AWS. If anything it's the other way around: AWS and cloud hosting gained popularity in part due to DevOps culture.
That was one of the most frustrating seasons of any television show I’ve ever watched, right up until the finale—which completely redeemed it for me! What an ending.
It's phonetically identical or very near it in most dialects. If anything it's a transcription error, but in this case just a way to imply the spoken cadence of a certain accent. Not any more incorrect than spelling "going to" as "gonna" in dialog.
It's not even that, they're pronounced the same in most dialects. It's either a transcription error or an atypical spelling depending on the intent of the author. It doesn't represent a different meaning or pronunciation in speech.
You've misunderstood the theorem. It doesn't say you can't achieve any combination of mostly C/A/P; it says you can't have perfect C, A, and P at the same time.
Essay writing as a form of cultural and intellectual interchange predates college administrators by at least a couple of centuries.
Everyday here you'll find quality essays written by competent essay writers, those essays not being written for the benefit of a college administrator.
My thoughts would probably be different towards this if we weren’t sending kids to school with predatory lending practices. (hence the administrator comment)
Ignoring the programs using x86 intrinsics to do vectorized math, the top-performing Rust, Go, Java, and C# programs are all written in a simple, straightforward style; each is practically a direct translation from the other. The Rust program is fastest, but the others come in at 1.6x, 1.7x, and 1.7x the Rust program, respectively. These are not significant differences for the vast majority of applications.
Of course this is one artificial benchmark, and on that website you will find others where the Java, C#, or Go program will do especially well or especially poorly. But it's clear that those three are all roughly in the same performance class..
The entire selling point of pair programming is that your copilot would point out errors like this, not introduce them.
Pairing works when you either pair two strong programmers or pair a strong programmer with a weak one. In the latter case, the main advantage is that it's also a mentoring opportunity.
Copilot has invented a pair programming situation in which your partner constantly introduces dubious code you must painstakingly verify, but is itself incapable of being mentored.
