kvark

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!

We have 2 paths here:

- 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!

Thank you for support!

Part of the problem with timing variety is frameworks not always picking the right gpu/backend.

If you want to inspect or tweak the setup, be my guest at https://github.com/kvark/inferena

Sadly the form doesn't even show up in Firefox. If they want to appeal to computer nerds, gotta anticipate not everyone will be on Blink engine.

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.

I've spent years playing with BWT and suffix sorting at school (some work can be found be names of archon and dark). It's a beautiful domain to learn!

Now I'm wondering: in the era of software 2.0, everything is figured out by AI. What are the chances AI would discover this algorithm at all?

I'm not employed by Zed, so I can't answer these questions. But the product itself is great!

Sure. Maybe that's the forcing function for them to nail down all the kinks. Example: https://github.com/kvark/blade/issues/205

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.

Those rotifers might have inspired the 3-body problem's concept of dehydration/rehydration as a skill to survive cataclysms.

David Baron was a distinguished engineer at Mozilla - not someone you fire at a whim. What makes you think he didn't leave voluntarily?

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.

The gamedev ecosystem appears to be split between nalgebra (for Rapier users) and glam. Where does lin-alg fit?

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.

Locking DLSS-4 to 50xx only is unfortunate. I don't expect it to rely on any new superpowers. Otherwise - looks like a big step with the AI.

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.

That’s a great business idea: sell a laptop survival kit for tough times.