今日已更新 113 条资讯 | 累计 37664 条内容
关于我们

标签:#us

找到 1794 篇相关文章

开发者

Zoox can now charge for rides in its steering-wheel-free robotaxis

Zoox just got permission to charge for robotaxi rides in its boxy, steering-wheel-less vehicles. On Thursday, the National Highway Traffic Safety Administration announced it has granted the Amazon-owned Zoox a temporary exemption, allowing it to deploy up to 2,500 vehicles annually over the next two years, as reported earlier by Reuters. The NHTSA's decision exempts […]

2026-07-30 原文 →
AI 资讯

Emergent Design & Gall's Law: When Complex Coding Problems Dissolve Instead of Being Solved

I recently read an article by the main maintainer of InversifyJS describing the journey of rebuilding its dependency resolution algorithm . What caught my attention wasn't the performance improvements or the technical details. It was something much more familiar. As I was reading, I realized they were experiencing the exact same phenomenon I had experienced years ago while creating InversifyJS. It reminded me of something that, until now, I had never really put into words. The temptation to solve the hardest problem first Every engineer has experienced it. You're implementing a feature when you encounter a design problem that feels wrong. You know the current approach won't scale, and you know there must be a beautiful abstraction somewhere, so you stop writing code and start designing. Sometimes that's the right thing to do. Many times it isn't. While building InversifyJS, I eventually adopted a different habit. Whenever I found myself thinking, "This feels too complicated, and I can't find a simple, elegant solution right now," I decided to wait. Not because I ignored the problem, but because I didn't think I understood it well enough yet. Instead, I focused on features where I had a reasonable level of confidence. I kept improving the parts of the system that felt obvious, leaving the difficult problems untouched. At first, this almost felt irresponsible. Over time, it became one of the most valuable engineering lessons I have learned. The magic wasn't finding the solution The interesting part is that I rarely came back later with a better idea. Something stranger happened. Implementing those simpler features changed the system itself. New abstractions naturally appeared. Responsibilities became clearer. Concepts that previously seemed unrelated suddenly fit together. Eventually, I would return to the "hard" problem only to discover it wasn't hard anymore. Not because I had become smarter or because inspiration had struck overnight. The problem itself had changed

2026-07-30 原文 →
AI 资讯

From Open Source to Paid Product: Is AI Accelerating the Shift?

I think many of us have already noticed that a growing number of open-source projects and libraries are moving towards commercial or dual-licensing models. In the .NET ecosystem, several widely used libraries have taken this path over the past year or so. AutoMapper and MediatR introduced commercial editions under a dual-licensing model, Fluent Assertions began requiring a paid licence for commercial use with version 8, and MassTransit 9 became a commercial product. These libraries were widely used in .NET applications and I mean widely used. Many projects treated them almost as a standard part of the ecosystem. Now, the same change is reaching the frontend world. PrimeTek recently announced that future major versions of PrimeNG, PrimeReact and PrimeVue will no longer be released as open source. All these projects were widely adopted, and many commercial applications depended heavily on them. Their licensing changes were primarily driven by the cost of long-term maintenance, but this raises a broader question: Is AI also changing the world of open source? You have probably already read many articles about code inflation. With AI, we can generate a huge amount of code in a very short time, even if the quality is sometimes questionable. The same thing is happening in open source. Maintainers can now receive more AI-generated issues, pull requests and feature requests than they can realistically review. Producing code has become cheaper, but understanding, testing and maintaining that code still requires significant human effort. Maintainers can become overwhelmed very quickly. AI may also discourage some developers from publishing their work publicly. Even small experiments, educational repositories and proof-of-concept projects can become training material for large language models. Some authors may therefore decide to keep their repositories private because they do not want AI companies learning from their work without permission, attribution or compensation. Licens

2026-07-30 原文 →
AI 资讯

[Advanced Rust] 1.14. Memory Types Pt.2 - Dynamically Sized Types and Wide Pointers, Packed Layouts, Larger Alignment for Speci…

Full title: [Advanced Rust] 1.14. Memory Types Pt.2 - Dynamically Sized Types and Wide Pointers, Packed Layouts, Larger Alignment for Specific Fields or Types, Memory Representation of Complex Types, and Repr Rust 1.14.1. repr(Rust) Remember the example in the previous article? That example used repr(C) , and the limitation of the C representation is that all fields must be placed in the same order as they are defined in the original struct. repr(Rust) is the default representation. It intentionally provides fewer layout guarantees than repr(C) : the compiler may reorder fields, and two types with the same fields in the same order are still not guaranteed to share a layout. Because the compiler may reorder fields (for example, placing larger fields first), padding can often be reduced. In the Foo example from the previous article, one possible optimized layout needs no padding. With fewer guarantees about layout, the compiler has room to rearrange things and produce efficient code. If repr(Rust) is used, then one possible memory layout of the Foo struct from above is: Code Field Type Size Default Representation Padding Final Alignment #[repr(Rust)] struct Foo { long: u64, 8 bytes 8-byte aligned 8 bytes normal: u32, 4 bytes 4-byte aligned short: u16, 2 bytes 2-byte aligned small: u8, 1 byte 1-byte aligned tiny: bool, 1 byte 1-byte aligned } Total 16 bytes The compiler first orders the fields by size, putting the largest first so that it can determine what alignment the struct should use. In this example, u64 is the largest and takes 8 bytes, so the struct is aligned to 8 bytes The compiler then looks at the remaining fields and sees that their total size is exactly 8 bytes, so it can place them together and avoid padding In the end, this struct only needs 16 bytes, which saves half the memory compared with repr(C) This is more efficient, but compilation time may be a little longer 1.14.2. Packed Layouts You can tell the compiler that no padding is needed between fiel

2026-07-30 原文 →