It sounds more like "path" borrowing than "group" borrowing to me, but the idea is great! Quite eye opening!
One minor thing is that I'm not sure why they had to have "in" keyword for sub-borrows. Wouldn't it be more consistent to see "entity &world.entities[?]" instead of "entity in world.entities[]"? We'd consistently get the borrow "&" symbol and open the door for some contracts on what index (range) is affected.
Or maybe open-source development is just poorly compatible with AI workflow? Today, projects may need a community, an issue tracker, but pull requests are becoming less important.
I suspect the ban of AI in established projects to be a very complex decision. Even if core developers would like to use AI, they don't want to review all of the AI-generated code from the larger community. So the only consistent way to preserve sanity is to declare that nobody would use it. Good luck enforcing it though!
- either evolve our UI systems for computers and let them operate efficiently, i.e. converting everything to API calls
. Frontier labs are pushing for this, starting with the Chrome plugin that Claude Cowork mandates.
- or make AI systems use the screen like humans do - what the article is arguing for
Both of these paths are possible. One of them is much more efficient than the other in the long term. Another one may be inevitable.
We had a process at one company where you had to create an issue before filing a PR. I found it most non-sensical and introducing friction for no good reason. Very surprised to see the author suggesting it in the article.
Review is indeed the main bottleneck now for open source, and we need to solve it. Introducing more friction is hardly helping.
Author of the benchmark here, as well as Meganeura - one of the tested frameworks. Results are constantly being refined, gaps are filled, but it's hard to get more hardware coverage by myself. Would appreciate someone running it on Intel Arc GPUs, both discreet and integrated. Happy to answer questions about methodology!
The main problem with Vulkan isn't the programming model or the lack of features. These are tackled by Khronos. The problem is with coverage and update distribution. It's all over the place! If you develop general purpose software (like Zed), you can't assume that even the basic things like dynamic rendering are supported uniformly. There are always weird systems with old drivers (looking at Ubuntu 22 LTS), hardware vendors abandoning and forcefully deprecating the working hardware, and of course driver bugs...
So, by the time I'm going to be able to rely on the new shiny descriptor heap/buffer features, I'll have more gray hair and other things on the horizon.
Shipping Vulkan in production on Linux is a challenge. Chrome was dealing with it for a while. Recently, with Zed ported to Vulkan, we saw the variety of half-broken platforms and user configurations.
I'd recommend Blended to not close the door on OpenGL and instead keeping it as a compatibility fallback.
Oh irony. The article talks about exaggerated attention to success of individuals, like Zuck, being an issue in Silicon Valley. And yet the article itself talks about this AI Ad direction as something invented by evil Zuck.
This isn't really about Zuck. Ultra-convincing ads will happen soon regardless of what Zuck does.
Firefox rendering is based on WebRender, which runs on OpenGL. The internals of WebRender are similar to gpui but with significantly more stuff to cover the landscape of CSS.
Super excited to see this reviving! We need more exploration into Linux structure: this world of hundreds distros barely different by their desktop environments - is too borong.
In pinhole cameras, straight lines look straight. That's what a regular projection matrix gives you with rasterization.
With non-pinhole cameras, straight lines look curved. You can't rasterize this directly. 3D Gaussian splats have an issue with this, addressed by methods like ray tracing.
It's very useful to train on non-pinhole cameras, because in real world they can capture a wider field of view.
Because it has to go through gpu anyway before it reaches the screen, gpu can be more efficient at doing this (better battery, etc), and we are wasting time transferring the pixels to gpu where the splines would be much more compact.
They developed a content generation tool based on splines, as well as a rendering algorithm based on finding the closest splines to each point. They are claiming real-time rendering (4k at 120hz) on CPU... why not run this on GPU?
I disagree with the first point. Say, the compiler figured out your missing semicolon. Doesn't mean it's easy for another human to clearly see it. The compiler can spend enormous compute to guess that, and that guess doesn't even have to be right! Ever been in a situation where following the compiler recommendation produces code that doesn't work or even build?
We are optimizing syntax for humans here, so pointing out some redundancies is totally fine.
That “.” substitution of an inferred type is going to fire back. I really appreciate when code has one simple property: you search a type by name and you get all of the places where it’s constructed. Makes it easy to refactor the code and reason about it with local context. It’s the case with Rust, but not C++ or Zig.
Quite often the meeting starts as “let me pick your brain on something“. This kind of expert advice from AI would save time and improve productivity of the team.
Having a standard CLI is definitely helpful. But does it have to be so hard to use? At what point would we acknowledge that we are being hostage by some random ideas put into ancient software, which just happened to survive?
I don't think calling for a stop of experimentation is the way. Nobody is going to take away your vi and bash any time soon.
Time will tell if this API is usable. In particular, the way resource synchronization works, and object renaming.
Time will tell if it will perform better than WebGPU or other abstractions.
Time will tell if it remains small in the presence of driver bugs that need working around…
I’m also sceptical about their new bytecode for a shading language. Parsing shaders at runtime was not a concern with WebGPU - it’s very fast. Even producing native shaders is fast [1]. It’s the pipeline creation that’s slow, and this bytecode wouldn’t help here.