506 karma · joined May 19, 2020
The reason you can't "align" AI is because we, as humans on the planet, aren't universally aligned on what "aligned" means.
At best you can align to a particular group of people (a company, a town, a state, a country). But "global alignment" in almost any context just devolves into war or authoritarianism (virtual or actual).
Most folks who are part of the startup, don't care to stick around for the scale. Different phases of the company tend to attract different types of people.
> A small, central R&D team may work with management to set the bar, but they can't be responsible for mitigating the risk on the ground - and they shouldn't be led to believe that that is their job. It never works, and creates bad team dynamics. Either the central team goes too far, or they feel ignored. (See: security, compliance.)
Yeah, the problem (in this outsider's opinion) is that that charter is so ill-defined that it's practically useless, which in turn means that any sufficiently loud voice can apply it to anything. It's practically begging to be used as a whip.
> I think you definitely want people who have that responsibility to "wield their authority like a whip without regard for business value".
No, because without thinking of value, there is no enterprise, and then your mission is impossible. Essentially, it creates an incentive where the best outcome is to destroy the company. And, hey hey, that's kinda what almost happened.
> Whether it's "We don't really think our technology is that dangerous (and therefore valuable)" or "We don't really care if we accidentally kill everyone", it's not a good message.
I don't think it has to be so black-and-white as this. Meta, Microsoft, and Google did the same thing. Instead, those functions have been integrated more closely into the value teams. And I can't imagine Amazon or Oracle ever having those teams in the first place. They likely all realized the same thing: those teams add huge drag without adding measurable business value.
And yes, there are ways to measure the business value of risk management, and weigh against upside value to decide the correct course of actions - it's just that most of those teams in big tech don't actually take a formal "risk management" approach. Instead they pontificate or copy and enforce.
Rocket caskets. Can't kill someone who is already dead!
As someone who has scaled orgs from tens to thousands of engineers, I can tell you: you need value teams to own their own risk.
A small, central R&D team may work with management to set the bar, but they can't be responsible for mitigating the risk on the ground - and they shouldn't be led to believe that that is their job. It never works, and creates bad team dynamics. Either the central team goes too far, or they feel ignored. (See: security, compliance.)
But when you give them a larger remit, and structure teams with some owning "value" and and others essentially owning "risk", the risk teams tend to attract navel-gazers and/or coasters. They wield their authority like a whip without regard for business value.
The problem is the incentives tend to be totally misaligned. Instead the team that ships the "value" also needs to own their own risk management - metrics and counter metrics - with management holding them accountable for striking the balance.
[1]:https://www.tomsguide.com/news/amazon-is-killing-one-of-its-...
Dude gets off the phone after learning the information, and immediately calls the brokerage to write puts that expire 11 days later (strike 1).
He nails the strike price (keeping below 70; strike 2), and when the brokerage calls later he openly admits on the call that he traded on a nonpublic rumor (strike 3).
Absolutely zero subterfuge. He either has a blatant disregard for the law, or is an extremely high-functioning idiot, or both.
Pretty fathomable.
For example: I wonder if it wouldn't be more "erlangy"/"elixiry" to model the mutable ops behind a genserver that you send messages to. In the Elixir world it's perfectly normal to make GenServer.call/3 and expect the target PID to change its internal state in a non-deterministic way. It's one of the only APIs that explicitly blesses this. The ETS API is another.
Alternatively, you could have the ref store both a DB sequence and a ref ID (set to the last DB sequence), and compare them on operations. If you call FeGraph.set/2 with the same db ref two times, you compare the ref ID to the sequence and panic if they aren't equal. They always need to operate with the latest ref. Then at last the local semantics are maintained.
Maybe this is less relevant for the FeGraph example, since Elixir libs dealing with data are more willing to treat the DB as a mutable thing (ETS, Digraph). But the it's not universal. Postgrex, for example, follows the DB-as-PID convention. Defaulting to an Elixiry pattern by default for Rustler implementation is probably a good practice.
Playing = executing
MS has had a storied past when it comes to frontend tech, but rather than diverging and dying, what we seem to see now is convergence of a coherent technical vision (and some pruning as a result). They look the same on the surface, but the result is totally different.
The latest version achieves exactly what every strung-together implementation of a moderately complex SPA architecture has aimed for in the past decade: fast initial render, low latency interactivity, low server load.
They did it in a way that still plays moderately well with the existing JS ecosystem.
They did in in a way where everything you do can be airlifted to the desktop or mobile via MAUI Blazor Hybrid.
And some of the underlying pieces that are coming along to make this possible are incredible. (Go check out some of the stuff they're doing in the wasm/WASI space.)
1/ deposition competitors with inferior repairability v performance scores, ultimately leading to increased market share among the most discerning customers, who are also influencers for other non-expert buyers
2/ eventually create a thriving secondary market that reaches consumers who otherwise wouldn't consider buying Apple products, ultimately leading to increased market share among non-expert buyers and children (who grow up to be customers)
There's so much progress happening in existing Python-powered ML community that, unless there are very good interop tools and protocols (e.g. ONNX and the like), then even if you gain productivity gains w/your local team by moving to Elixir, you risk losing your ability to draft off that larger community's progress.
Very hard trade-off unless you're sufficiently funded to invest in the gaps.
Same for Elixir in general. Different philosophies, but same energy, some craftsmanship, some welcoming attitudes, same hubris about what can/can't be done by revisiting from first principles.
LiveView is quite elegant, and is something that could only exist with such elegance in a language/runtime/community that values and supports long-lived processes with functional semantics.
Broadway builds on the shoulders of giants to provide robust data ingestion and processing... as a library, rather than the cobbled-together set of independent systems that is usually needed to do this.
The architectural concepts underlying Livebook put it on a path to surpass Jupyter, if only we can get critical mass adoption.
The stuff emerging in the Elixir + ML space thanks to Nx and Axon gives me some hope that Elixir will find a place as an all-in-one home for all things ML. Livebook makes it easy do to incremental experimentation. Bumblebee makes it stupidly simple to use pretrained models.
It's all so magical.
What we need, though, is better marketing!
I also like the philosophy of magical experiences, without magical code. Everything is very traceable. And most of the time you don't even need to use the generators - just make your module, register in the right places, and you're done.