tobias12345

True, you have few external dependencies... but you have random code thrown into your repository in the form of vendored 3rd party libraries, header only libraries, and bits and pieces copied from somewhere. Of course you also get huge kitchen-sink libraries that do everything, so you only need to add one library and have semi-decent functionality for everything you might need. At least those usually have people working on maintaining their usually pretty huge dependency tree -- those they know of. They have the same problems knowing their true dependency trees as everybody else in the eco system.

I have not yet looked at any C++ code base > 1 milliom lines where I did not find at least 3 copies of zlib. Often just the compression or decompression function copy and pasted into a random file. Which version? No idea. Was it patched? Likely. Is there any documentation on how to update this? Absolutely not. Was it easy to find? No, some specialists even rename the functions so that users linking to the system zlib do not get into symbol conflicts. I have heared way to often that it is so much simpler to just copy a class over from abseil, or whatever other library than to depend on it.

Sure, you do not see dependencies, the functionality those provide are still there somewhere though -- either hidden away or in the form of reimplementations. You just do not know... and what you do not know about you can not maintain.

To handle supply chain attacks, you need to know where yiur code comes from. That is often not a given when working with languages where it is easier to copy and paste in code from random other projects.

I have seen so must stuff copy and pasted into projects in my life, its not funny. Often it is undocumented where exactly the code comes from, which version it was taken from, how it was changed, and how to update it when something goes wrong.

When code is not copy and pasted it is over rewritten (poorly).

Code sharing does have its benefit. So does making it obvious which exact code is shared and how to update it. Yes, you can overdo code sharing, but just making code sharing hard on the tooling level does mote to hide supply chain security issues than it does to prevent the problem.

I doubt that ideomatic code is easier to write in C once you switch to Fil-C. Your code will just get killed by the runtime whenever it does something it should not do (and the compiler does not catch). You need to think about that stuff when your runtime enforces it.

"Memory safe" means that there are no memory safety issues. One of the most critical areas targeted by exploits is just gone. And this in turn leads -- according to the numbers published by Google -- to a severe reduction of exploitable issues.

C++ means you can not know whether code is safe or not. That does not mean it is unsafe, but assuming it is is the only sane way to handle this. Incidentally this is exactly what browsers do: They typically require two out of these three to be true for any new piece of code: "written in a memory-safe languge", "sandboxed" and "no untrusted inputs". This blocks C++ from some areas in a browser completely.

Yeap, systemd is just another init system existing on a level playing field. They just dare to be successful by tackling problems that people have today over trying to deliver solutions designed in 1989.

How will porting a single concept like `defer` from zig, a language that is not memory safe, to C and C++ make those memory safe?

`defer` is a poor man's RAII. C++ has had RAII since the beginning, and C++ is still not considered memory safe. So how will adding `defer` help C++ to become memory safe?

This feels like another example of how poorly C and C++ devs understand the ideas behind memory safety. You do not really need to understand this concept, as long as you can debug all the memory issues that just pop up:-)

> we talk about supply chain attacks, a thing that Rust with Cargo falls deep into.

How so? By listing all dependencies in an easy to digest way?

Making it hard to have a dependency does not stop devs from reusing code, it just leads to that code bing copy/pasted into code bases. I found several copies of gzip in every large C++ code base I ever looked at. Sometimes the functions get renamed, as somebody reported that linking failed when pulling in gzip as a library elsewhere. Most of the time with some patches applied. Never with documentation on where the code came from or how to update it.

"Header only libraries" are taking this approach and turn it into a best practice: Just copy this file somewhere into your source tree and you are done.

Even if you use proper dependencies, you typically depend on huge kitchen sink libraries that depend on the world themselves... often with the world being "vendored" (== copied into the library repository).

Those hidden dependencies are the worst kind of supply chain security issue you can have as itnis costly to even know about them being there.

> Currently I see no existential risk at all.

I see rust as a continuation of a trend that was started with Java... C++ has lost entire markets to memory safe languages in the last 25 years, be it the enterprise applications (Java), windows software (C#) or scientific computing (python). With these markets, C++ also has lost mind share and that shows in the new features being proposed.

When I visit a rust conference I am the old guy. When I go to a C++ conference I am of average age. The old guards are retiring with few new people filling up the ranks.

Sean Baxter stated that he is not working on Safe C++ anymore, so that proposal is dead.

But is somebody still working on safety profiles? I have not noticed and profiles related paper seeing updates since Hagenberg. Herb just wrote in his trip report "Profiles papers received a lot of discussion time in EWG (language evolution working group) and feedback to improve consensus,", which leaves any interpretation open.

Does it matter whether it is a common class of bugs or a not so common one? The point is, this is a class of bugs you do not have when picking a different language.

C++ claimed for decades to be about eliminating a class of resource management bugs you can have in C code, that was its biggest selling point. So why is eliminating another class of bugs a nice to have now?

C++ is loosing projects to memory safe languages for decades now, just think of all the business software in Java, scientific SW in python, ... . The industry is moving towards memory safe software for decades now. Rust is just the newest option -- and a very compelling one as it has no runtime environment or garbage collector, just like C++.

This has been going on for over a year now. Any progress in C++ land towards more memory safety?

Nope, editions cover that use case nicely: Rust breaks things every three years -- without breaking existing code.

Basically you have to opt in your project to the new normal. All your projects dependencies can opt in, too, whenever they want to make the jump. Nobody has to opt in though.

Maybe C++ can do something similar eventually once modules are used everywhere. Those have a much cleaner separation of code between individual project parts than you can have with headers.

RAII is great, but unfortunately it breaks down when the resource it manages leaks out of the RAII type.

E.g. Whenever handing out the raw pointer stored in a unique_ptr, the code receiving that raw pointer can delete it, which will very likely lead to a use after free and certainly to a double free issue.

I am not arguing that there is a lot of C++ code and that this code will be around for a long time. But I would prefer to see C++ as a language with a future and not as the language some well-paid dinosaurs use to keep the legacy code-base running while all the cool stuff happens elsewhere. "C++ will make a great legacy language" is underselling it.

But we might be wrong: Some government or consumer org or something _could_ step in and start to require the use of memory safe languages or just discourage the use of C/C++ in anything they buy. That would hasten the replacement of C++. I am afraid this is getting more likely based on how the C++ community handles growing concerns about memory safety outside of the development communities.

I have seen presentation on safety by people I respect for their contributions to the C++ language that all said a combination of these things:

* you said "C/C++", so you must be clueless * you do not know what safety means, let us explain that to you * everybody else does it wrong and is not really secure either * we can not solve the problem, because everybody uses C++ for the tricky bits that other language can not do because they are oh so safe * other languages are not as safe as they claim as they can all call into C++ * it will act swiftly, it will probably only take us a decade or so * you can use some extra tools somehow, that somebody will probably write * asking devs to follow our recommendations has never worked before, so we need something to enforce things. Let's ask all devs to please use this new thing. * Devs unfortunately do not follow best practices and there is nothing we can do about that

That does not seem to be a very convincing communication strategy to me, even less so when other communities show that real improvements are possible.

So your argument is: C++ will be a great legacy language and we will enjoy its memory bugs for decades to come?

I really hope it can do better than that.

Note that Window ships a kernel driver written in Rust already, Linux (== ChromeOS and Android) are working to add rust support and iOS is moving towards Swift everywhere. Other languages are closing in on all the use cases you mentioned.

There is more out there than C++ and Rust, but yes, if you are stuck with C++, then you have no option but to wait for a couple of years and start to rewrite wehn C++ is ready.

I seriously hope all your competition is in a similar situation or it might become harder and harder for you to meet requirements going forward. The push towards memory-safe languages is out there.

> There is no "rewrite it in another language" option.

How about "Wrap your C++ code in FFI wrappers and use it from a safer language"?

It is conceptually not much different to "rewrite all your C++ code to be profile compliant" -- which will involve wrapping existing "unsafe" C++ code you can not just port over to mark it up in such a way that tooling can reason about it better.

Which option? To write wrappers now instead of later?

I just see no way to be able to use current C++ code in a profiles world without wrappers or even a rewrite. For some code with decent semantics, a modern enough code base and clean APIs that wrapper might be just slapping a "compatible with profile FooBar" somewhere. On the other hand those are the APIs that are the easiest to wrap for other languages, too.

> As an example, while Microsoft slowly adopts Rust, it keeps putting out best practices and improved tooling, they aren't going to rewrite the whole Windows, XBox and Azure C++ code into Rust for the next couple of decades, or how long they would still matter on the market place.

So they are making the jump away from C++ now, wrapping their existing code to reuse it from safer languages. Smart :-)

I am disappointed:

I have to wait a few years for the C++ committee to define profiles. Then a few more years for tooling to become available. Then a few more months for the tooling to become interoperable enough to actually be used in existing build tooling. Then a few more years for all my major dependencies to actually use profiles. Then I can rewrite my code in profiles-C++ -- or by writing safety wrappers around my existing code and all dependencies that do not support the right profiles.

Or I can switch to a memory safe language today. I still have to write safety wrappers around all my code to interface with that, but I'll have a couple of years of a head-start to anybody sticking to C++.

C++ did a lot to improve safety over the decades, but it seems to have ended up in a local maximum. I doubt you can break out of that local maximum by doing all the things you did before. Something needs to change, backward compatibility would be the one thing with the biggest overall benefit -- but also with the biggest cost.

There is accessibility using the Qt backend and I started working on accesskit integration, which should cover the rest of the backends. Yes, more work needs to be done there, but the architecture has proven that it works. Any help with accessibility is welcome, especially as I lack the experience of having to rely on accessibility features. I might miss some things that will be show-stoppers for people reliant on accessibility. Of course any help is appreciated, too ;-)

All the text handling code is done in Rust (or C++, depending on the backend you pick). Just the basic navigation between elements and such is done in our DSL. But yes, we need more widgets and more features for some of the existing ones. We are working on that...

The problem is that the different crates typically address certain sub-eco-systems and produce better results for that one dialekt spoken there. It is hard to generalize all that.

I missed more: There are a lot of tools out there addressing special cases. Those typically address certain C++ sub-eco-systems that follow certain rules that make the mapping in some special cases better.

Most of these are either built on top of cxx or are similar in spirit. So I did not list all of them. The original presentation was only 30 min and there is only so much you can ask a person to read in a blog post:-)

I did try to make it clear that my list is in no way exhaustive.

There is still work to do to make Slint's accessibility support great, but this is an important first step: It validates the ideas we had to make Slint UIs accessible and puts a lot of infrastructure into place.

So Widgets can now have `accessible-*` properties that the compiler knows how to handle. Those properties are available at runtime and one of our backends does work with them and forwards them to the OS-specific accessibility backend for actual interaction with screen readers, braille-terminals or whatever is needed. We decided to use the Qt backend in this phase: That covers the major desktop platforms with one implementation. We can add different/more backends going forward, the infrastructure for that is in place now.

Yes, there should be pre-build binaries of the viewer available.

Right now there is not, but work is being done to cover the common platforms.

Both are wonderful options for some use cases. I would also take one of thise approaches for the simple demo in the blog post.

But the system UI that is also linked in there is something that goes beyond what you can do with e.g. zenity.

This kind of puts (almost) all the power of a modern UI description language in reach of shell scripts.

By splitting / and /usr you create problems for packagers: Where do all the files need to go?

Does cryptsetup need to go into /sbin or /use/sbin? Does network code belong into / or /use?

Must users will not care, but some might need either of them to set up their file systems.

If you pace something into /, then you also need to put all libraries and binaries that needs into /. That will rapidly blue up the size of /. It is also not automatically testable, so distributions will get things wrong (as they repeatedly did before).

You could have a script to only put the stuff your system needs into /... Most distributions use such a script for their initrd, which contains everything necessary to check and mount your root file system. So you could just extract that into / and be fine with it:-)

Or just use your initrd as that rescue medium.

That would suck hard for me:-)

I have a tmpfs on / and mount a ro-snapshot onto /usr. Fresh system in every reboot:-)