You can pay for Zed today if you'd like - https://zed.dev/pricing - and also the editor itself is open-source under the GPLv3 license. So if at any point in the future Zed changes direction in a way you don't like, you are perpetually free to build the version you liked from source (or make a community fork and take it in a different direction).
So here's my ask: let me pay for it without paying for AI! None of my use cases will stress your servers; I have `"disable_ai": true` in my settings.json. Give me a $5/mo "support the devs tier" or a $10/mo tier with some random app quality-of-life features and I'm there. I specifically want to pay for good software without paying for AI to signify the value proposition that still exists there cause I don't think a VC would believe me otherwise.
careful. I too am pessimistic on the generative AI hype, but you seem even more so, to the point where it’s making you biased and possibly uninformed.
Today’s news from BBC, 6 hours ago. “AI designs antibiotics for gonorrhoea and MRSA superbugs”
https://www.bbc.com/news/articles/cgr94xxye2lo
> Now, the MIT team have gone one step further by using *generative AI* to design antibiotics in the first place for the sexually transmitted infection gonorrhoea and for potentially-deadly MRSA (methicillin-resistant Staphylococcus aureus).
…
> "We're excited because we show that generative AI can be used to design completely new antibiotics," Prof James Collins, from MIT, tells the BBC.
I didn’t realize at the time, but Oxide’s application process was the best form of interview prep I’ve done. The process forced me to thoroughly document my values and career accomplishments. In later non-Oxide interviews, I effectively recited what I had written my materials. In that way, it has felt less one-sided than every other company application process I’ve gone through. I was able to take away an artifact from the experience, versus being filtered out via a coding challenge. It’s also been rewarding to reflect on my submission from years ago to see how my mindset and skills have evolved.
If you have any interest in working in the pediatric telemedicine space, I encourage you to email me your application. We accept Oxide materials. I’m happy to provide feedback as a hiring manager. My email and our company website are in my bio.
There was a great panel discussion this year from a number of the co-authors of the the paper linked, discussing what is Local-first software in the context of dev tools and what they have learnt since the original paper. It's very much worth watching: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
The community are very much settling on "Sync" being a component of local first, but applicable so much wider. Along with local first software being a characteristic of end user software, with dev tools - such as sync engines - being an enabling tool but not "local first" in as much themselves.
The full set of talks from the last couple of years are online here: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
It's an exciting time for the local-first / sync engine community, we've been working on tools that enable realtime collaborative and async collaborative experiences, and now with the onset of AI the market for this is exploring. Every AI app is inherently multi user collaborative with the agents as actors within the system. This requires the tech that the sync engine community has been working on.
It would seem that these tuners have a lawful purpose if there are in fact exceptions for non-road vehicles, such as true race cars.
Edit: answered my own question. Seems it's just selective enforcement. State level inspection exemption is still a "visual only" inspection, meaning there can't be any obvious deletes (not really enforced it seems). https://www.thedrive.com/accelerator/2137/epa-clarifies-its-...
So to answer your actual question, while technically actual off road use is still legal a lot of bad actors in the industry used every bit of leeway that the regulators gave them and now this crackdown is the result.
Back when I worked properly on big games the UI libs would often be trees of widgets with injectable functions for modifying the rendering, which is actually one of the points in this blog the writer would like. (The UI lib of classic Sims was exactly like that). These days the stuff I've done, although entirely in JS, at https://luduxia.com/ follows that pattern for the 3D components at least. The world is defined in an almost classic scene graph and then behaviour is added by attaching functions to pieces, which can be composed functionally.
Much of the anti-OOP noise is the result of people that have suffered from others creating hierarchies of the world too literally. Quite why it proves so difficult for developers to slow down and think about the right course of action is beyond me. They're also staggeringly resistant to changing afterwards.
I think one of the problems is that a heirarchy is inherently opinionated. You have to choose the criteria around how to group the objects/nodes in your graph and that criteria is context-dependent. The example I've used with animal taxonomy is grouping your objects via things you can eat vs things you can pat. Thsoe are two very different graph structures of the same group of objects and if you started with one then realized you need to change, how you use your objects you're gonna have a bad time. Multiple inheritance is the bandaid solution that usually comes with more hassle than it's worth.
Building a UI is a good example of a heirarchical structure where you know exactly how you want to use your objects and how they'll relate to each other, Not having access to that programming structure would be frustrating and just feel like a loss. But I've also done multiple large refactors of Python projects because I relied on OO inheritance models that turned out to not be quite the right implementation. In those situations, Rust traits are a breath of fresh air for offering the right kind of polymorphism.
But ultimately I sense the subtext here is much the same as with other Rust problems: the object oriented baby has been thrown out with the bathwater, often in the name of premature optimisation, but also with a sense of misplaced religious purity regarding the evils of state and the merits of functional programming. There never was any OOP law that your inheritance hierarchy had to be insane, or that you had to create classes for absolutely every last thing. Now we have people hitting the opposite extreme where everything has to go through the same function switched on a pattern matched enum. One of the core problems with Rust is it lacks the mechanisms to allow moving adequately out of this tarpit.
I still think Rust might have a place at the lowest level core where it is all about shuffling arrays of things through compute units, but for the higher level pieces it is clearly the wrong thing to be using.
I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is. But when you're creating models of the world it's usually really convenient and even accurate to use nested inheritance models. Maybe the original system for this is the flora/fauna taxonomy but it applies to a lot of things; like GUI elements or game models.
If this is correct, it might explain why the discourse is so polarized. Whether OOP is a blessing or a curse probably depends on whether you're using a programming language as a modelling language or as a logic/execution language.