The biggest problem are the platform ABIs that are not expressive enough for either rust or C++. That means both sides do tricks to smuggle extra information through the C-compatible platform ABIs -- or to pass constructs entirely around that ABI. E.g. name mangling is used to smuggle function overloading through the C ABI by encoding type information into the symbol name which is just a string.

Things going around the ABI is all the stuff that C++ requires to always be in a header file. Those headers get directly included into the user of a library, going around the ABI layer completely.

The challenge for interoperability is to extract all the necessary information from one language and make that available in the other. Gathering that information without some defined ABI means extracting it from the source code of the language itself. That is damn hard, especially if one side is C++ that needs heuristics to even get parsed.

There is a proposal to have Rust semantics in C++. Nothing more. It will take decades to get that through the committee, with prominent members already having said that all other venues need to be explored before this proposal can be considered.

Sean having suggested to not have a new C++ standard library (but to use rusts instead) is not going to help find support inside the committee.

So the problem is that you got devs that are unwilling or unable to learn new things? That's indeed a problem...

They will suck out the will to live from any fresh blood that joines their team. Your product is stuck in the past forever, behind a strong waöl of "we never did that before".

Yeap, but humans just can not do that. We need tools to help us.

... and yet that is exactly what the "Safe C++" proposal is that has hit the committee recently.

We are pretty much the only industry that thinks like that. There is no contradiction between "improve eco system" and "train developers". All the other industries around us do both.

We are also pretty unique as an industry in that we watch our products fail and then go "there is nothing we can do about that, sucks that random people were too stupid to write proper code". We urgently need to improve, or we need regulators to step in to make us improve. Code is just getting too important to continue with our attitude.

Memory issues are used to attack your software. Them causing crashes is the lucky case...

True, but those languages make sure you do not need to worry about the entire class of bugs that are related to memory management.

That frees up resources to think harder about all the other issues your code might have.

Rust has proven that you can eliminate these issues without runtime overhead. So fixing these issues is now considered by governments to be low-hanging fruit.

There was an interesting paper recently that looked at first time contributors to open source projects. They found that their first few patches are way more likely to introduce vulnerabilities when the code base is in C++ compared to Rust. The difference gets smaller the longer the contributor is around but never vanishes.

Maybe the devs are not bad, maybe it's you setting them up for failure?

https://cypherpunks.ca/~iang/p...

Quote from the conclusion ofnthenpaper:

> Namely, while it may still be true that Rust may feel like a more difficult language to learn, in at least some ways, new contributors actually benefit from its adoption, with their first contributions being less than 2% as likely to introduce vulnerabilities as C++,

So you avoid RAII since I gives a false sense of security? It also removes a class of bugs you can have without it.

> If the compiler barks you should be really careful about that unsafe block over there because memory but hey this block over here which results in melted steel when not done in the correct sequence is not marked for safety by the language and therefore does not deserve attention according to the language, what is the implication from a psychology perspective?

It absolutely would bark at "this melts metal when done wrong". Any sane rust dev would make that a unsafe function, so you would need to call that in an unsafe block.

Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?

I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem slow.

I also think that maintainers would not have gone for systemd if they did not think it had benefits for their users. Contrary to what you think maintainers do care for having people use their distribution. The fact that systemd had convinced developers did also factor into the maintainers decisions. So did advantages for the packagers: Getting rid of init scripts was a big part of that. There were lots of factors considered at Debian, check the CTTE discussion you liked to earlier for more.

I do not think it matters whether software depends on an init system. Software depends on other software all the time and will adapt once some better option comes along.

Actually I find it reassuring that things start to depend on systemd: It means that it is reasonably simple to interact with the system and that it provides something worth the effort to talk to it. Never seen that before on Linux.

Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.

How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.

Yes, POSIX is important. But as with any standard it defines the least common denominator. Couple that with the fact that POSIX was not updated in years and you have to address the least common denominator from more that 5 years ago (I think even longer...). That is an eternity in IT. A standard is fine, but it should not stop you from playing to your strength.

Systemd argues that an init system is closely related to the Kernel and should make all the fancy kernel features available to user space. There is enough precedence for this in commercial unix variants by the way: Many come with init systems tailored to their specific strength of their kernels. I do not see that as a bad thing. So far I am not aware of anybody in the BSD camp even wanting to port systemd. At least the FreeBSD developers said they wanted a modern init system, too, but they are going for something that plays to the strength of their own kernel. So why should systemd bother about being portable to OSes that want to come up with their own solution?

That BSDs require some compatibility layer is nothing new, either. There is support for Linux style /proc and IIRC even /sys in some of the BSDs! DBus, polkit and whatnot were ported over to the BSDs, too. So how is systemd any different than those projects? You will need to implement a couple of DBus interfaces and make sure those will do the right thing. Nothing new, nothing special.

There are projects on the BSDs as well, that are non-portable: LibreSSL and openSSH from openBSD spring to mind here. Those use interfaces from the BSD kernel. There a separate porting projects that bring those code bases over to Linux. They actually introduced a new kernel API due to libreSSL into the Linux kernel.

I see nothing bad in targetting specific platforms whatsoever. Yes, I do think POSIX is important: If you can do something with POSIX, then use that. If not, then use something else. And when in doubt target one platform and let people that care for other platforms port the stuff if they care.

It was not possible with consolekit, great that there was progress with consolekit2.

There is no way to refute conspiration theorists. It is a self-contained believe system, that functions outside of the real world. I won't bother to argue with that.