arcadialeak

I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of the Web, really). Maybe this will bear fruit in that people will make more Native user interfaces again.

Euro-Office codebase will, obviously, not diverge significantly from the original product. If they planned fundamental changes, they would have started from scratch because taking over a huge project and rewriting its basis is an ever more daunting undertaking.

As such, any future patches to both codebases should be trivial to copy from one another, which essentially makes it collaboration.

Yes, but they can't do anything about it anyway. The FSF resolution on this matter, though, essentially means that they might just as well pull Euro-Office patches into OnlyOffice. So in the end, the product will be formed by combined effort.

I can't help but notice that this, in effect, establishes collaboration between EU and Russian devs over a common open-source office suite, because both projects can easily copy future changes from each other. The irony is staggering, given the war and the public rhetoric.

Nevertheless, it's also React team that came up with prefixes like __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED in their codebase because people couldn't stop messing with the internals. So any documentation about the new compiler would be anything but rejected by the community.

It's quite frightening to see how an enormous 120KLOC pull request gets merged at once with very little public discussion or coverage by the devs after just 3 months (which IMO is very little time in relation to the amount of code). There used to be extensive RFCs and series of conference talks long preceding changes this big, e.g. React Fiber.

I support wholeheartedly the move to AOT-compiled languages but it looks like paying off the cognitive debt is going to be brutal on whichever team gets to maintain it in the long run.

char* is an exception to strict aliasing rules of C++ precisely to facilitate the author's use case. You would still need a reinterpret_cast to make it work, but it's actually good because it makes the intent clearer, and the cast would have still happened either way to read the raw bytes.

> std::string_view or std::span should be used instead

That is for when the owner is a std::string or an owning range respectively. But a raw pointer does still make sense as a non-owning view over a single element, doesn't it? I'm new to C++ so I might be wrong.

Why does any mention of C++ nowadays turn into a Rust debate? These can coexist even in a single project via C ABI. Also, despite the vast syntax and semantic differences, an experienced dev will be able to apply most of their knowledge from one to the other.

Since you are already making use of LLMs, you could also ask questions about the code that it produces. I've been asking Google's AI overview and Deepseek while doing my first ever C++26 project, usually not to produce any code but to give advice or list possible approaches to implementing a feature. It's a very slow path, to the point that my project has currently more git commits than lines of code, but I'm convinced that it will pay off in the long run.