Earlier quoted context omitted.
The C sphere is actually refreshingly free of zealotry (mainly I guess because there isn't such a thing as a "C community" and even despite C being the main attack target of language zealots - funny enough nobody complains about those pesky assembly coders and their hippie attitude towards memory safety lol). The "religious zeal" was also an important reason why I switched back to C from C++ and why I don't have much…
Are you sure? The C sphere overlaps with the UNIX one, for obvious reasons.
"No way to prevent this" say users of only language where this regularly happens
241–250 of 342 posts
Re: "No way to prevent this" say users of only language where this regularly happens
#242Earlier quoted context omitted.
The right questions according to who? Are your coreutils replacements 100% drop-in?
I don't need a 100% drop-in. Barely anyone does. I've observed at least 80% of all of the coreutils features are not used by 90% - 99% of programmers and sysadmins. Ask people if they used all flags of `sort` and report back results as a test of my hypothesis. > The right questions according to who? This is tiring. I told you twice that I'd prefer you engaging in technical merits. You keep drawing attention to what i…
> This is tiring.
Hey, you're the one keeping the argument going...
Re: "No way to prevent this" say users of only language where this regularly happens
#243Earlier quoted context omitted.
I don't need a 100% drop-in. Barely anyone does. I've observed at least 80% of all of the coreutils features are not used by 90% - 99% of programmers and sysadmins. Ask people if they used all flags of `sort` and report back results as a test of my hypothesis. > The right questions according to who? This is tiring. I told you twice that I'd prefer you engaging in technical merits. You keep drawing attention to what i…
I don't see many CVEs in coreutils. Maybe one or two, in several decades? I do on occasion use obscure flags (or at least ones that are obscure to me). > This is tiring. Hey, you're the one keeping the argument going...
I am getting tired of being misinterpreted, not of the argument itself because the argument ended several comments ago and the person focused on being a little rebel ("who gets the determine the right questions" is his favorite pet peeve apparently).
There is no argument currently, just people trying really hard to miss the point that was stated very clearly.
Re: "No way to prevent this" say users of only language where this regularly happens
#244Re: "No way to prevent this" say users of only language where this regularly happens
#245Earlier quoted context omitted.
I don't see many CVEs in coreutils. Maybe one or two, in several decades? I do on occasion use obscure flags (or at least ones that are obscure to me). > This is tiring. Hey, you're the one keeping the argument going...
One more person misinterpreting? Cool. I am getting tired of being misinterpreted, not of the argument itself because the argument ended several comments ago and the person focused on being a little rebel ("who gets the determine the right questions" is his favorite pet peeve apparently). There is no argument currently, just people trying really hard to miss the point that was stated very clearly.
(Or, I suppose, whether we're just talking past each other.)
Re: "No way to prevent this" say users of only language where this regularly happens
#246Earlier quoted context omitted.
TIL almost every european country is in a state of tyrnanny. Also Yemen which is one of the only countries with somewhat similar gun ownership compared to usa (bit less than half as many guns per capita) must be the epitome of freedom and safety.
What about Switzerland? They have extremely liberal gun laws, on par with the USA. Perhaps it’s not the guns that are the problem? Perhaps it’s the overall dysfunction of the US as a country?
So probably it probably not really compareable to how most people learn to handle a weapon in the usa.
Re: "No way to prevent this" say users of only language where this regularly happens
#247Earlier quoted context omitted.
One more person misinterpreting? Cool. I am getting tired of being misinterpreted, not of the argument itself because the argument ended several comments ago and the person focused on being a little rebel ("who gets the determine the right questions" is his favorite pet peeve apparently). There is no argument currently, just people trying really hard to miss the point that was stated very clearly.
Yeah... I'll just leave the other readers (if anyone else is still reading) to judge whether we missed your point, or you missed ours... (Or, I suppose, whether we're just talking past each other.)
Mine was that some people needlessly -- and very immaturely -- rebel against using Rust because of something they saw on HN 5 years ago. There's no Rust zealotry here for a long time.
I chased after a few people asking them if they really tried it or they simply resist something because it's gaining popularity.
How dare I? :D
Re: "No way to prevent this" say users of only language where this regularly happens
#248Earlier quoted context omitted.
TIL almost every european country is in a state of tyrnanny. Also Yemen which is one of the only countries with somewhat similar gun ownership compared to usa (bit less than half as many guns per capita) must be the epitome of freedom and safety.
What about Switzerland? They have extremely liberal gun laws, on par with the USA. Perhaps it’s not the guns that are the problem? Perhaps it’s the overall dysfunction of the US as a country?
You need a permit to buy anything other than a hunting rifle. You can't buy a gun if you have been convicted of a crime, have an alcohol or drug addiction or express a dangerous attitude.
You generally can't carry a gun except when going to and from hunting or a shooting range and you can't have the gun loaded in transit.
It's also compulsory for most male citizens to learn to handle a gun safely, something which the US doesn't require even if you buy a gun.
Re: "No way to prevent this" say users of only language where this regularly happens
#249Earlier quoted context omitted.
I would rather have unpleasantries that make the language safer vs unpleasantries that make it more vulnerable. Especially when the unpleasantries in question don’t even make the language easier to use.
C standard: "Undefined behavior means such a situation can't happen." Me: "If it can't happen then it would be fine to just crash on those situations, right? Because such a crash would never be reached. Can we get that?" C compilers: "No. Would you want to crash on signed integer overflow, for example?" Me: "Yes? Would be safer than the current situation at least." C compilers: "What, no, that would make your program…
Re: "No way to prevent this" say users of only language where this regularly happens
#250Earlier quoted context omitted.
In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?
Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'. Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility. Lack of global scope. Lack of function overloading.
You're mistaking "idomatic because it's the only way" with "idomatic because we say say so". There is currently no way in Rust to specify the granularity of a borrow, so we're stuck with splitting your structs to get around it.
Part of the problem is that it's a hard problem to design around. It can not be done automatically by the compiler, because it would result in changes in the implementation being changes in the type signature. For example, say we have this function:
pub fn foo(&self) -> i32 {
self.a + 5
}
The granularity is borrowing `a`. If we then change it to this: pub fn foo(&self) -> i32 {
self.a + self.b
}
The granularity of the borrow has changed in a backwards incompatible way (it now includes `b`), but that change is not reflected in the signature. It's the same reason why the compiler refuses to infer signature lifetimes from function bodies now.You could, of course, say that we can allow the programmer to specify it manually:
pub fn foo(&'borrow self) -> i32
where 'borrow: 'self.a + 'self.b
{
self.a + self.b
}
But this is now leaking implementation details if `a` or `b` are private fields.