Comment Re:Why not link to the near Dupe? (Score 5, Funny) 193
The new employee who's supposed to link to dupes didn't show up for work today.
The new employee who's supposed to link to dupes didn't show up for work today.
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.
Meanwhile Rust-inspired safety principles and constructs are being added to C++ right now in the form of Circle C++ and an enhanced libstdc++, and in the near future in the C++ standard. The future for C++ is quite bright and will allow more cost-effective ways of retrofitting safety onto existing C++ code.
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".
You should write correct code everywhere.
Yeap, but humans just can not do that. We need tools to help us.
C++ isn't Rust. Are you now suggesting that C++ adopt implementation details of Rust to solve a problem?
... and yet that is exactly what the "Safe C++" proposal is that has hit the committee recently.
"The responsibility is on our ecosystem, not the developer"
This is false. You need to train your developers (unless they're already skilled).
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.
What do you mean with secure? Secure as not attackable, or secure as not crashing, aka having memory bugs?
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.
These days, security problems stemming from unsafe memory are not even the majority of issues.
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.
If you want to kill competition in an industry, tax it enough that only the large corporations can survive the loss, and add some complicated regulations in for extra effect.
The notion that this is about helping SpaceX kill off their competition is absurd.
This is Musk Derangement Syndrome. The Brandon administration is simply trying think of every way to go after Musk. He pissed them off. He dismantled the branch office of Pravda that the old Twitter was building for The Blob. He fired all of the CIA and FBI spooks on Twitter's payroll, who were busy censoring and shadowbanning anyone who was engaing in wrongspeech. But the worst of it: he has all but explicitly endorsed Trump. Just read his tweets. He's been fully red-pilled. Not a day goes by that he doesn't rag on all of the left's sacred cows: environmentalism, transgenderisms, the illegal alien invasion from all the South American shitholes, et. al.
This is why they're doing this. This is why they have a bunch of lawsuits going against Tesla, for a bunch of bullshit reasons. This is why every time the Brandon administration tries to puff up the US's fledging EV industry they always fluff only Detroit's automakers, and conspicuously ignoring the elephant in the room.
And this is why they're doing this, that's all.
What about OpenSSL, is it available from homebrew? Sounds like it's time to build OpenSSL from source, and link curl to it.
There seems to be an obvious solution to anyone who finds themselves in this boat and needing to use MacOS for some reason: build their own stock version of curl and use that. Did someone mention homebrew?
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://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fcypherpunks.ca%2F~iang%2Fp...
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.
Giggidy!
Come on. Admit it. You were thinking the same thing as me.
I'm always looking for a new idea that will be more productive than its cost. -- David Rockefeller