1. Microsoft was heavily involved in orchestrating the 95% of employees to side with Sam -- through promising them money/jobs and through PR/narrative
2. The profit incentives apply to employees too
Bigger picture, I don't think the "money/VC/MSFT/commercialization faction destroyed the safety/non-profit faction" is mutually exclusive with "the board fucked up." IMO, both are true
> was it just Helen Toner’s personal vendetta against Sam
I'm not defending the board's actions, but if anything, it sounds like it may have been the reverse? [1]
> In the email, Mr. Altman said that he had reprimanded Ms. Toner for the paper and that it was dangerous to the company... “I did not feel we’re on the same page on the damage of all this,” he wrote in the email. “Any amount of criticism from a board member carries a lot of weight." Senior OpenAI leaders, including Mr. Sutskever... later discussed whether Ms. Toner should be removed
I feel like the "safety" crowd lost the PR battle, in part, because of framing it as "safety" and over-emphasizing on existential risk. Like you say, not that many people truly take that seriously right now.
But even if those types of problems don't surface anytime soon, this wave of AI is almost certainly going to be a powerful, society-altering technology; potentially more powerful than any in decades. We've all seen what can happen when powerful tech is put in the hands of companies and a culture whose only incentives are growth, revenue, and valuation -- the results can be not great. And I'm pretty sure a lot of the general public (and open AI staff) care about THAT.
For me, the safety/existential stuff is just one facet of the general problem of trying to align tech companies + their technology with humanity-at-large better than we have been recently. And that's especially important for landscape-altering tech like AI, even if it's not literally existential (although it may be).
I think the surprising thing is seeing such cohesion around a “goal to ship” when that is very explicitly NOT the stated priorities of the company in its charter or messaging or status as a non-profit.
Probably some combination of:
1. Pressure from Microsoft and their e-team
2. Not actually caring about those stakes
3. A culture of putting growth/money above all
That’s a fair point. I guess there are contexts where pseudonymity can be useful and enable types of interactions that otherwise might not be possible. Especially in online contexts where you’re interacting with people you don’t know anyway, so using your real name doesn’t add much value in terms of trust.
I’m still skeptical that work is a context where I’d want/need this. But it’s a thought-provoking idea!
Oh for sure! I’m not saying using real names automatically creates real relationships and trust, just that it helps. I just generally want to see the internet moving toward deeper, more meaningful interactions, which, like you say, is a big challenge, and almost certainly means some form of making things “smaller.” But making things more anonymous strikes me as the wrong direction.
It’s interesting to see all these ideas built around the idea that “more anonymity is better.”
I think the opposite is usually (not always) true, and that many of the issues we see in today’s internet stem from the fact that we have completely lost a human connection to the people on the other end of our interactions. (You can even go further and connect this to the larger loss-of-community trends across modern society.) Developing a real relationship with someone increases empathy and trust; it leads to healthier, clearer, and more productive communication; and it generally is good for everyone’s mental health and happiness.
Personally, I want a less anonymous and more communal internet (and society).
This comparison feels like it's less about Node vs Rails and more just about "batteries-included framework" vs not. (Although, perhaps there isn't really a Django/Rails equivalent in Node yet? I'm not definitively sure.)
>I’ve always found it hard to climb out of the plumbing, forget about it.
This is the crux it of it, and it's true for any web project not relying on "magic" frameworks. And of course, it comes with tradeoffs. Namely, frameworks can be inflexible, and they can be difficult to understand/debug under the hood.
There is no escaping these tradeoffs, with any framework or language. More magic means less plumbing and more initial speed, but less flexibility and potential issues as complexity/scale increases. It's all about trying to choose the best tool for the job.
Even completely leaving aside the language/software diversity, the point is that the vast majority of web "frontends" are really just one thing (rendering the UI and responding to inputs) whereas web "backends" are frequently not really one thing (1 or more types of storage, 1 or more types of computation, responding to requests, perhaps event processing and scheduling, etc.)
I did not mean to imply that all, or even most backends are more complex than frontends -- only that the problem space of backends is larger and more varied (for typical web use these days, at least.)
Check out Amplify! I've heard good things and my limited experience is good so far. (Although running locally isn't the best, unfortunately... but that's always going to be an issue the more you lean on a cloud services.) Deployments are easy. In terms of scalability, it's all massively scalable AWS services under the hood, and it seems relatively easy to "eject" if you ever need to.
1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.)
2. At the end of the day, web backends are just a lot more varied and complex than web frontends. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client. And functionally, there's a relatively large set of common things they pretty much all do (routing, serve images, etc.) Therefore, it's relatively simple to build an opinionated framework that can still cover a good number of situations.
By contrast, a "backend" is really a lot of different things (like the four you mention, plus various types of storage and caching), which can use many different languages/technologies, all working together in different ways. It's hard to conceive of a universal "backend" framework that could cover all of that complexity.
3. There are some efforts to do this kind of thing (to some extent). Google's Firebase and AWS Amplify are the two that I think are closest -- they try to give low-configuration generic backend building blocks. (I'm currently using Amplify for a project -- still too early to tell. It also works with Next.js!) There's also platform-as-a-service options like Heroku.
> That does not mean there isn't a general underlying "cognitive ability" factor.
Careful. "g" is a statistical regularity, not proof of a generalized "underlying cognitive ability."
From the same Wikipedia article:
>It is a variable that summarizes positive correlations among different cognitive tasks
>Yet, there is no consensus as to what causes the positive correlations between tests
This whole subject is a scientific, statistical, and ethical can of worms (as pg alludes to in the essay), and this isn't the place to get into it... I just want to flag that it's a bit more complicated/controversial than it might sound at first.
Maybe this is outside the scope, but one thing I’m really curious about —- what about the radiation!?
I’m guessing the payload could be sufficiently shielded and/or would just outrun it. But would there be any eventual issues with blasting out tons of radiation all over space wherever it went? In particular, this seems like a big problem during take-off from Earth…
Ah yes. We did end up using extraReducers, but didn’t love that the thunks and their corresponding reducers had to live in separate parts of the file. (For me at least, mentally simpler to have an action and it’s reducer close together.)
This looks cool, thanks for passing along! I’m actually starting a new project now, and deciding what my state management / caching layer should be, so great to know this is an option.
Can someone elaborate on the privacy concerns (e.g. with Amazon "becoming a pseudo-ISP")? It seems like most (if not all) of the network use would be Amazon devices anyway, which is data they already have. Additionally, as far as I know, Amazon isn't really in the business of selling ads or customer data, so they seem like they'd be relatively trustworthy (compared with, say Google, who's entire business is based off of selling ads, and also literally sell routers.) Is the concern just the threat that they could abuse this data? Is it just general "big company getting even bigger / having more data is bad" sentiment? Genuinely curious.
(The security concerns make sense to me -- most people and businesses assume their home network is closed, and this theoretically opens an attack vector. Asking specifically about privacy.)
High-level, we wanted to minimize the need to "jump around" to multiple files or multiple places in a file to make a single change to an action (and also just minimizing the amount of boilerplate generally).
If I'm remembering, createSlice() got us most of the way, but async actions still needed an extra declaration (and maybe types? we were using TypeScript), which couldn't be placed next to the createSlice reducers, since they're in-lined. I can't remember if we ended up popping the reducers out into their own functions so they could be next to the createAsyncThunk call, or if that created too much of a typing headache and we just dealt with having async action creators declared at the top. (We also tried just using createReducer directly, but iirc the typing was just extra work compared with createSlice.)
**
Only partially-related to RTK, but the other thing we had to tinker with a bunch was performance. RTKs default use of immer helped a lot, and I believe we also ended up using createSelector (or perhaps the Reselect API directly) in a few places. We also had to learn to make extensive use React.memo and React.PureComponent. Redux dev tools were incredibly helpful for figuring all of this out.
*
Anyway, hope that's useful/interesting! RTK made a big impact in my day-to-day React/Redux development, from "ugh so much boilerplate I feel stuck" to "I can make changes reasonably quickly." Hope to see it continue to improve!
There are for sure lots of bad ways to use React, and lots of bad React developers. I actually had a very poor experience with React my first project using it.
But that's true for any framework (or lack thereof.) It's definitely possible to find good React patterns too. My 2nd project with React was a great experience, and was infinitely more maintainable and reusable than the framework-free frontends I had worked on.
Sounds like you've worked in really bad React projects (and/or really good non-React projects). All I can say is that my experience has been different! Redux + Redux Toolkit (https://redux-toolkit.js.org/) helped me and my team establish React patterns that were organized, concise enough, and performant -- although we did still have to tinker and try some things out until we found the patterns that worked for us. Hope it helps!