Live data from Hacker News

"No way to prevent this" say users of only language where this regularly happens

xeiaso.net

241–250 of 342 posts

Re: "No way to prevent this" say users of only language where this regularly happens

#241
post #226

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.

I can't remember Linux zealots raving irrationally about C though (although when googling I'm sure something will come up). Topics like Wayland or systemd on the other hand, oh my...

Re: "No way to prevent this" say users of only language where this regularly happens

#242

Earlier 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…

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...

Re: "No way to prevent this" say users of only language where this regularly happens

#243

Earlier 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...

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.

Re: "No way to prevent this" say users of only language where this regularly happens

#245

Earlier 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.

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.)

Re: "No way to prevent this" say users of only language where this regularly happens

#246
post #240
post #205

Earlier 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?

Every swiss that is issued the military gun (which is most) get a gun. They are trained by military professionals how to use the gun and hoe to store the weapon at home. It is for example forbidden and punishable by law, if something happens with your weapon, if you stored your weapons ready to shoot. You must remove the bolt and store it in a save, secured location. Using ammunition provided by the goverment must not be used, if it is used you will be punished. If you dont handle your weapon responsibly during trainig you may go to military prison.

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

#247

Earlier 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.)

By all means, name your exact point then.

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

#248
post #240
post #205

Earlier 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?

Switzerland has very high rates of fun ownership, but their laws are far from lax. They are much stricter than the US.

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

#249
post #71

Earlier 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…

C is more likely to define wrapping arithmetic. Wrapping is defined as undefined for compatibility with MIPS processors that support checked arithmetic.

Re: "No way to prevent this" say users of only language where this regularly happens

#250
post #133

Earlier 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.

> 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'.

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.
Post reply on HN