namark @namark@qoto.org
Joined Jan 2020
@isagalaev I apologize I rustled your jimmies by speaking ill of your favorite language, but, wile I enjoy doing that periodically otherwise, notice please that I did not do that in the OP or my previous reply to your previous reply. My argument is rather specific, that rust's memory/resource safety does not guarantee mechanical elimination of all bugs naively deemed memory errors in c++. If you have an argument against that, please present it directly, and stop imagining that I'm trying to definitively prove rust useless for all intents and purposes with those couple of sentences I wrote in the OP. I might do that some other time, but with many more sentences.
If your argument is simply that in the cases I'm describing here, the good rust programmers will do the right thing, cause of the general expressiveness of the language, the same can be said about c++ (for the purposes of not making those logic errors in the first place), so it is in no way an advantage of rust to be counted in the statistic of "problem rust will definitely fix".
If your argument is that it is better than nothing, I will again point out that a wrong fix for a logic error is just as bad as the logic error, and rust in no way guarantees that it will be fixed correctly, as there is a myriad of ways to fix memory errors without addressing the underlying logic errors (and I'm talking about those cases where these underlying logic errors exist). You are back to square one with that, again relying on discipline of the programmer and general expressiveness of the language, not the memory safety.
Finally if your argument is that you predict that these logic errors that result in memory errors in c++ are not common enough to significantly affect any statistic, I would have to point our that your prediction, however justified, is not a statistical argument, so you might as well present it without collecting any statistics.
These are the more or less direct arguments I've encountered in this expansive subthread with @kornel, if you are interested:
https://mastodon.social/@kornel/107487641143219120
Please also keep in mind that if you are not a member of the "statistical nerds out there counting memory errors in c++ to justify the existence of rust" then the OP is not directly calling you out, regardless of your marital status with rust.
@kornel for 2 my point isn't that rust is always wrong, or that all things considered it does a worse job here than c++, my point is that the memory safety alone can't provide a strong guarantee that these errors will be fixes once diagnosed. The error might be fixed, or might be obfuscated, dependent on other factors, such as overall expressiveness of the language or the discipline of the programmer. You can argue that rust is more expressive or coherent, but that would be a completely different, much more subjective and complicated discussion, compared to the basic sales pitch of "all bajillion of these memory* errors I counted will 100% entirely go away".
@kornel no c++ does not automatically prevent such logic errors, my point wasn't that it does, my point was that this class of errors skew the statistic of memory errors that rust can help fix reliably. Exactly how much can only be shown empirically, but I haven't seen anything like that mentioned or addressed anywhere. Most statistics seems to be based on technicalities and not root causes.
@kornel I didn't mention c++ here to claim it is better in this particular regard, I mention it to call you out on writing paragraph that reads like an ad for resource management generalization in rust, in a thread about comparing rust to c++, which supported that since forever. I didn't mean specifically that rust copied RAII and moves, I mean it copied "whatever you can do with memory you can do to any other resource" generalization.
@kornel yes, so being equal is not enough... how does that meant that I claim that c++ is better? The new thing needs to be better for it to have value, otherwise it's just a waste of time... I mean if rust is just a experiment you are having for fun with, no judgement there, but that's not how it is advertised. If you are not one of the "nerds trying to justify existence of rust by comparing it to c++", that's great, that would make you the happiest rust fan I've met so far.
@kornel nah, nothing in my argument about c++ being better... I do think c++ is better... but that's not in this argument.
@kornel I had this in mind when writing everything I wrote but I do not conciser closing an fd twice a logic error, it's a resource management error, which for the purposes of this discussion is same as memory error, equivalent to double free. I wrote "resource" in my example intentionally to somehow hint at that. It could be a heap allocated object, an fd, or a container-iterator pair, with the iterator being the part that gets invalidated, or whatever else that fits the pattern. It should really be called resource safety in general, but I was following the convention here.
Btw, in case you didn't know, this resource management generalization comes directly from C++, and has been a thing there since forever.
@kornel Your latest reply in this thread finally makes sense to me, you can put it right after the OP and it will fit perfectly. It's also fortunate that you have split it exactly here, as for the purposes of this argument I can't meaningfully engage with your opinions and prediction regarding the statistic. I'll read them, but can't promise I'll have much to say.
The only direct argument I see here is your implication that my own opinions and prediction regarding the statistic are somehow relevant to the argument I'm trying to make. They are not. I've presented a class of errors that potentially invalidate or heavily skew any naive memory error statistic, so the burden is now on the "statistical nerds out there counting memory errors in #cpp to justify the existence of #rust" to empirically prove that their statistics are not significantly affected by this. Any other argument will not be a statistical argument. You just can't deduce statistics. You might as well present your arguments without the statistic at that point.
Now I also think that it is practically impossible to actually diligently identify all such logic errors, so I expect them to instead resort to some high arcane probabilistic sampling mambo-jumbo, which being way beyond my comprehension will force me to concede and issue a public apology to the international community of "statistical nerds out there counting memory errors in #cpp to justify the existence of #rust" for helping to refine their statistics.
Also from a cursory glance at the split thread, I see you keep going back to the "it's better than noting" argument, with the "better know in advance" formulation, so I'll try to elaborate on that more: Better to know what in advance? That you have a memory error when you actually have a logic error? What it takes from you to identify the logic error from the memory error, is exactly the same as what it takes to not make the error - overall expressiveness of the code, familiarity with the codebase and time. You have these things - you will not make the logic error. You don't have them - you will patch the false positive memory error and leave the logic error as a time-bomb, or at the very least an unnecessary hurdle for the future readers, compromising the overall expressiveness of the code, anyone's familiarity with the code-base, and everyone's time. In my eyes both outcomes of "hidden logic error", or "indirectly mitigated logic error" are simply worse than "unknown logic error", but even if you think that one of them is worse while the other is better, overall it makes things equal, that is rust does not definitively address these any better than c++ does, so they are still false positives in the statistics of "errors that rust will fix because it's memory safe", or even "errors that rust will help with because it's memory safe".
@kornel *but irrelevant in this particular context
@kornel you are assuming I don't know the very basics of the languages I'm talking about and spewing out unrelated marketing slogans. But alright I'll try one more time and hope you'll put a bit more effort into it. I assure you, I'm not trying to destroy you favorite language, or definitively prove that it is entirely useless (I'll do that later maybe). I'm making a very specific point. So here we go again:
Memory errors are not impossible in rust, they are possible they just happen at compile time. My example was in pseudo code and conceptual, so whether the error happens at compile time or runtime doesn't matter. My point is that the error in question has nothing to do with memory management, and cannot be solved with memory management techniques, it's a completely unrelated logic error. If you solve the memory error in the most obvious way you will not solve the logic error. You can satisfy the rust compiler, but the problem will still remain. Therefore rust by the virtue of being rust does not eliminate this class of errors that statistically you would count as memory errors in C++, because that's how they are more often than not manifested technically. If you find yourself inclined to pursue the route of "it's better than nothing" again, I addressed that when I presented the example and in the OP, so please take that into consideration and continue with arguments from that point. If you think that regardless of all of that rust is still useful, that's fine, but irrelevant.
@kornel are you even reading what I'm writing or are you just a rust commercial? I don't think I can chew it up any further for you, just try again if you will, and present a better argument, I can't engage any further with you bringing up points unrelated to what I'm saying, I'll have to just repeat myself.
@kornel now you are literally arguing that most logic errors are memory errors, that's how religious you are about your beloved language.
Here is a pseudocode example to demonstrate to you a logic error, that results in a memory error, that is not itself a memory error, or has nothing to do with memory management. This is apparently utterly incomprehensible to you:
got some resource x
if(condition)
some operation that invalidates x
use x
memory error on last line... how do you solve this problem? You could replace the first operation with equivalent that does not invalidate. You could replace x with an equivalent shared resource that does not invalidate on that operation. You may take a copy of x, and keep the original for use after invalidation. You may rearrange the code so that the second use comes before the condition. All of these options will solve the memory error, but none of them would be correct. The correct solution in this contrived example is to return early in the condition body(or add an else after the if, or whatever other branching technique you use), and never use x in that case, because it was an error condition for that particular subroutine. You will never know this from the memory error alone, you need to understand the business logic of the piece of code, to figure that out. The memory error was not the cause, or even a hint of what the problem is. In fact it was a distraction.
And fixing memory errors without fixing the logic is not better than nothing, it's worse, because it complicates the code and lets the underlying logic error "fester behind a coat of paint". Otherwise it's a segfault. Both are equally bad for security but that is beside the point. Any discussion of silent bugs vs a loud bugs is about development and maintenance, not security. For security any kind of bug in a critical part of the program is a disaster.
@kornel you are either completely missing the point, or intentionally derailing now, go read the OP, I'm talking about statistic of memory errors in c++, and it's use as an indication of how important/common memory errors that rust eliminates are. It's useless because most logic errors result in memory errors in c++. You are counting these logic errors towards your total of memory management errors. And once again logic errors are not memory errors, that's what I'm trying to explain to you, while you keep imagining that I said that all memory errors are logic errors.
@isagalaev you can fix the memory issue that is reported to you, by introducing shared state or a copy where by program logic there should not be any shared state or a copy, making your memory management perfect, while your logical invariants are still utterly broken. Otherwise you need to understand the code regardless of the memory management to identify the logic error that led to a memory error or whatever else side effects. The point is when you count memory errors you get a metric ton of false positive logic errors in a language where memory is managed explicitly.
@kornel yes I would not count type errors such as "undefined is not a function" in dynamically typed language to statistically evaluate the usefulness of static typing, because I know there would be a lot of false positive that are caused by logic errors and not typing errors. Type conversion is a fix for a type error but it would not fix the underlying logic error. You have to fully understand the code, follow some guidelines or get lucky to identify the logic error from the type error, even if it is reported to you at compile time.
Correctness of memory management is not correctness of program.
to all of the statistical nerds out there counting memory errors in #cpp to justify the existence of #rust: a logic error in a system that uses explicit memory management often culminates in a memory error. That doesn't make it a memory management error, it's still a logic error, and patching it up with more memory management is over-complicated at best and silently incorrect at worst.
@johnabs not to worry, take care
@zpartacoos
@QOTO I set default in my settings to plain text but apparently that does not apply to replies, who is responsible for this?! :V
@johnabs freakin markdown by default again, screwing up my formatting... those last paragraphs formatted as quotes include replies -_-
@johnabs I'm nor arguing against your morality, there was no morality in your OP, you pretended that it's an economic argument and that it would be economically beneficial to all in the US. It will not be. That's my argument. Nothing against morality as it was not central to your argument prior to me replying, but now for some reason it is. And again it is tangential and secondary to the argument of IP vs right to repair, so I'll address those part only.
> I am going to get the chip one way or another, either by buying the laptop or by buying the chip itself. So if someone is really that dedicated to reverse engineer their parts, it can be done 100%. But considering it hasn’t really happened yet, I have a hunch it’s not economically feasible to sell apple knockoffs.
It is illegal in your country and any other country that respects IP from your country, hence even if a business was feasible it is impossible in your country, hence the argument of "it doesn't exist, therefore it probably can't exist" doesn't work.
> But now, with billions of 7-14nm transistors, I highly doubt it.
You do not need to produce an exact copy, you need to produce an equivalent design, that can serve the same function. That is illegal in your country, as you can never proof that you designed a replacement part, without reverse engineering the original device, to figure out the function of the part.
> We have to start somewhere, and I think the moral arguments for why it must be done easily trump the soft economic reasons of why it “cant”.
My argument is that you are wasting time trying to invent ineffective laws, if you ignore the elephant in the room that is causing all your problems.
> I actually do fully own and can repair my own laptop (and can flash whatever BIOS, install any OS, etc.) that I want
Are the designs open or proprietary. If the latter then you are at the mercy of the IP owner. If they decide you don't get the part you won't get the part. You can't go to a third party and ask them to make the part for you or make an independent business out of that. But yeah sure you are free, as long as your favorite brand wishes to cater to your specific needs and bank on your specific niche.
