So is this a reflection on Boeing engineering culture? Seems it would be, I remember comments from previous articles saying it is.

Bigger than that, legacy US defense contractors ARE the US Military / Space Force / etc.

So IMO the golem whose values are being reflected in this failure / recovery from it is a US Government <> Commercial organism. And indirectly the United State's civilian population since the Government is formed (over centuries) to be a care-taker reflection of the civilian pop.

Yes mostly the idea that risk should be averted at all times by using the same few companies has fully captured US gov culture. And it’s only gotten much worse since they seem to think China should be the model to copy because they dump money into pet megacorps there, even though it’s still a very new concept that is far from proven sustainable in China itself. Not to mention they mostly coast off copying US innovation and preventing competition.

But mostly the issue is employing it as a long term strategy, because it worked a few times in the last as a short term boost to newly ascendant orgs (ala NASA+space industry in the 1960s) before the Iron Rule of bureaucracy kicks in at all organizations involved, be they private or public.

I have to favorite mantras related to this:

There is nothing more permanent than temporary.

... and ...

We don't have time to do it right, but we do have time to do it twice.

Here is something from Clojure that stuck with me as particularly elegant:

The -> macro.

  (-> {}
      (add-person 'servbot)
      add-age
      add-info
      add-to-db
      notify-status-by-email
      log-user-addition
  )

So the threading operator is exactly what you ask. It inserts the results of the previous expression as the first argument as the first argument as the next expression. Note this still supports situations where an expression can take more than one argument.

Additionally, there is the ->> operator which inserts the previous result as the last argument in the next expression and some a library that includes the "magic wand" operator "-<>" ala

  (-<> {}
      (add-person 'servbot)
      (add-age 21 <>)
      (add-info 'servbot <> 21)
      (add-to-db 'my-db-handle 5432 <>)
      notify-status-by-email
      (log-user-addition 'dev 'email <> 'paint-by-numbers)
  )

This particular set of macros seems entirely trivial until you use it, and then it changes your entire perspective of what functions do since your ability to express the computation pipeline changes completely.

Edit: Update for formatting.

The Clojure standard library has had the the 'as->' macro for a while which serves the same purpose as the "magic wand". It doesn't need to use '<>' as the identifier, but I usually choose to do so because I learned about the magic wand library before I learned about the 'as->' macro.

  (as-> {} <> 
      ...
      (add-age 21 <>)
      ...)

Thank you for the insights on Go and how Go has added value to your organizations and enabled a better environment for development at your organization! I love hearing viewpoints on tradeoffs and general evaluations on value of new(ish) development technologies.

I'd also like to point out that I write this a Python-phile that has come to the understanding that Python is great until it isn't. When Python becomes to burdensome, the understanding of the problem delivered by my Python sketch helps to narrow the focus of what I need to solve the problem efficiently. By that time, Go has never been the correct tool for me. I'm comfortable writing solutions in C, Rust and Java, perhaps this is my problem.

Whenever I read or write Go I don't understand how it managed to capture the mindshare that is has. Especially in the face of other technologies available, Go seems like a timid step forward in descriptions of computation, when there are bolder choices that deliver valuable additions to my development ecosystem.

I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. But I feel that when I make the leap from Python to Go, I admittedly don't understand the allure. Static compiltion is really nice! Statically linked binaries for distribution is very nice! The tooling is out of this world! Hands down, Go has one of the best out of the box toolchains I've ever encountered. But when helping me think about computation, Go doesn't.

Go's concurrency primitives don't feel like a great deal of a step forward compared to C. I know, I know, this is crazy talk. I feel like I am missing some great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly helped a lot of people minimize concurrency problems. But whenever I use channels I am reminded Go does not allow me to shut my brain off, and whenever the deadlock bug strikes, I feel that I might as well be writing C.

I don't mean to disrespect Go and the great things it does, the opposite of that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until then I've become too familiar with other tools to justify using Go for more than incredibly niche use cases. I really hope that will change (both my mindset and Go)!

> I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak.

Rust's static guarantees come at a price: You have to learn Rust to take advantage of them, which is apparently no mean feat.

> I am hoping Go delivers a bulletproof abstraction for concurrency.

Don't hold your breath. Go has always been and will always be about “good enough”, not “bulletproof”.

From:

http://legacy.python.org/dev/peps/pep-0465/#id24

Implementing __matmul__, __rmatmul__ and __imatmul__ will allow you to apply this operator to any given class. In that light, you could subclass the numpy matrix class yourself and simply apply these.

As for whether these will be applied to Python lists, my speculation is: I doubt it. Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.

The matrix multiplication on lists could be used for the cartesian product (see itertools.product). However this operation is rather uncommon so there's no good reason to use an operator for it.

It wouldn't incur any overhead, don't know why you'd think it would. Each method of any object only needs to be stored once, not again for every instance. The overhead comes from pointers and data fields such as the length.

> Its possibly the most commonly used data structure, and I doubt they would add the overhead of another set of methods on each instance.

Unless I'm grossly mistaken, Python methods add basically no per-instance overhead (they add per-class overhead.)