Live data from Hacker News

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

xeiaso.net

271–280 of 342 posts

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

#271
post #267
post #182

Earlier quoted context omitted.

[flagged]

It's not even really benefits of guns are outweighed by people doing murders. All countries pretty much have some gun availability. In the UK where I am you can get a shotgun without huge problems for example. Also all countries have restrictions - even in the US I don't think you are allowed to stock up on M777 howitzers and ammo (British gun by the way). It's about having sane regulation.

The last comprehensive study on gun usage in the United States estimated that there are up to 2.5 million defensive uses of guns in the US yearly, most of which never involve firing a shot. They also found a correlation between gun ownership and lack of injury from violent crimes. Also you can own howitzers in the US, they just require special paperwork and a $200 tax stamp.

https://nap.nationalacademies.org/catalog/18319/priorities-f...

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

#272
post #267

Earlier quoted context omitted.

It's not even really benefits of guns are outweighed by people doing murders. All countries pretty much have some gun availability. In the UK where I am you can get a shotgun without huge problems for example. Also all countries have restrictions - even in the US I don't think you are allowed to stock up on M777 howitzers and ammo (British gun by the way). It's about having sane regulation.

The last comprehensive study on gun usage in the United States estimated that there are up to 2.5 million defensive uses of guns in the US yearly, most of which never involve firing a shot. They also found a correlation between gun ownership and lack of injury from violent crimes. Also you can own howitzers in the US, they just require special paperwork and a $200 tax stamp. https://nap.nationalacademies.org/catalog/…

I don't really understand US politics very well but looking at Wikipedia there's stuff like

>poll in ...October 2015 found that 92% of Americans supported "universal background checks for all gun sales"

But you can't do it because the NRA owns your politicians? That's the kind of thing that could be fixed I would have thought.

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

#273
post #272

Earlier quoted context omitted.

The last comprehensive study on gun usage in the United States estimated that there are up to 2.5 million defensive uses of guns in the US yearly, most of which never involve firing a shot. They also found a correlation between gun ownership and lack of injury from violent crimes. Also you can own howitzers in the US, they just require special paperwork and a $200 tax stamp. https://nap.nationalacademies.org/catalog/…

I don't really understand US politics very well but looking at Wikipedia there's stuff like >poll in ...October 2015 found that 92% of Americans supported "universal background checks for all gun sales" But you can't do it because the NRA owns your politicians? That's the kind of thing that could be fixed I would have thought.

We have universal (depending on what that means) background checks for everything except private sales currently, you cannot go to a store and buy a gun without submitting one. Private sales are person to person and represent a rounding error in gun sales. Guns are a hot button topic and most people are uninformed so stats like "want universal background checks" doesn't actually amount to anything actionable legislatively because according to most gun owners, we have that, but many that don't own think its the wild west.

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

#274
post #228

Some of the HN discussion about whether "new projects in C should be allowed" is moot: Fluent Bit was imported into git in 2015 [0] (a few months before Rust's first public release), and may be considerably older than that for all I know. I suppose incidents like this actually do give a reason to "rewrite it in Rust", when "it" is "widely deployed infrastructure written in C". OTOH, I'm sure there were plenty of non-…

People slipping backdoors into stuff are no doubt super enthusiastic about Rust both for the opportunity for new anonymous nobodies to rewrite long stable and proven tools as well as the dependency ecosystem that tends to blindly pull in multiple different entire HTTPS/TLS stacks into anything but the most trivial software.

I don't buy it. Rust has a really good track record on attracting more people to read and modify the code, which isn't what you want if you're hiding backdoors in the code.

In decades of writing C (sometimes as a hobby, often for a lot of money) I'd guess I thought "These errors when I wrote bugs in my program are crap, somebody should fix it" maybe once per month on average. But a C compiler is very intimidating code, subtle and hard to even build from scratch let alone contribute to, so I never attempted to make such changes.

In only a few years of writing Rust (none of that paid) exactly twice I've thought "Man this compiler error diagnostic isn't very good, somebody should fix it". The first time I asked on Reddit, and I was informed that I wasn't the first to notice, the fixed diagnostic was in nightly Rust already. The second time I found the diagnostic and I just fixed it, compiled first time, wrote a new unit test, checked that passed, wrote a pull request. Landed it. Then I wrote a HN comment, a reader found a bug in my diagnostic, so I fixed the original code, and wrote a new PR which also landed. If Rust has told you that instead of 'X' when you needed a byte, you should write b'X' because just 'X' is a char not a byte - that's me, that's my small fix. [Before the fix 'X' wasn't legal here, of course, but the diagnostic wouldn't suggest what to write instead]

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

#275
post #11

Earlier quoted context omitted.

https://xeiaso.net/shitposts/no-way-to-prevent-this/ Generated by exactly 69 lines of Go every time: https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-t...

Kudos for faithfully reproducing the joke then.

Thanks, I've had thoughts about making it a bit more elaborate (possibly involving large language models somehow to help synthesize what's going on into the right format, and so that it's not literally the same thing every time), but there's a charm in making it literally the same thing every time with the details swapped out. It points out the repetition to the level that all you need to do is swap out the details next time. This is all so preventable, but sometimes these things just happen and there's not anything anyone can do about them.

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

#276

Earlier quoted context omitted.

No, more people should be using memory managed languages like Java and Golang. Then educate and expose people to sum types and pattern matching. It is actually insane how people is still unconvinced about sum types. Imagine how insane it is to program without product types? That's exactly what it felt like.

Just call them "tagged union" or "variant" and suddenly "sum types" are not so rare anymore ;) ...same with "struct", "record" or "tuple" vs "product type". Nobody calls them that except functional programmers and mathematicians, both quite rare specimen in the wider programming world, but nevertheless they are ancient and widely known concepts even among us "peasant coders" ;)

> Just call them "tagged union" or "variant" and suddenly "sum types" are not so rare anymore ;)

Nah, this is a false dichotomy. If a language doesn't have product types but instead resort to declaring variables separately, you don't call that "structs". Similarly, calling tagged unions a sum type is kind of misleading. They are both programming languages, I am sure I can do whatever I can do in A using B.

Why is a "struct" such a powerful concept? Because it is correct by construction. When I declare struct A, I have everything that A should contain. It is impossible to say, oops, I forgot about A::b. Similarly, a sum type as a concept is only useful when the abstraction is very, very solid.

Tagged unions or variants (in C and C++ respectively) is nothing like that. I have a variant A, I checked that that it is B, but oops, I casted it as C. Its your typical TOCTOU (or LOCLOU for line of check, line of use, I guess). std::optional is also like, same with pointers. Proper sum types, like Rust, it is literally impossible for me to get C by mistake.

Obviously, all of this minus some underlying implementation details, unsafe code yadda yadda.

Sorry if I sound aggressive, but I am just tired of "we have A at home, A at home (the most cursed shit)".

Does go have enums? Yea... just declare some global constants like so bro.

SomeEnum_A = 0

SomeEnum_B = 1

SomeEnum_C = 2

Yea..."enums"..

Edit: Oh how can I forget, we had this kind of issue just TODAY in production. No wonder I am so pissed off.

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

#277
Free Pascal and Lazarus which is a GUI built on it support strings that don't require manual allocation and are counted and reference counted. A huge amount of grief would go away if that library could be supported in the Linux kernel somehow, and all of the string parameters in system calls ported.

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

#278
post #60

Earlier quoted context omitted.

It is totally possible for pointers with bounds checking to exist in C. Turbo C did that 30 years ago. However, why bother trying when whole culture is biased against it and you can use any of the other languages?

>Turbo C did that 30 years ago. I used Turbo C++ (not C) back in the day, and recall near pointers, far pointers, based pointers, but I don't recall bounds-checked pointers. Do you remember any details? >However, why bother trying Because it would immediately make the large amounts of C code still in the wild safer for the users , who do care?

I remember it as an compiler otion.

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

#279
post #228

Earlier quoted context omitted.

People slipping backdoors into stuff are no doubt super enthusiastic about Rust both for the opportunity for new anonymous nobodies to rewrite long stable and proven tools as well as the dependency ecosystem that tends to blindly pull in multiple different entire HTTPS/TLS stacks into anything but the most trivial software.

I don't buy it. Rust has a really good track record on attracting more people to read and modify the code, which isn't what you want if you're hiding backdoors in the code. In decades of writing C (sometimes as a hobby, often for a lot of money) I'd guess I thought "These errors when I wrote bugs in my program are crap, somebody should fix it" maybe once per month on average. But a C compiler is very intimidating cod…

I'm not sure how modifying the compiler is relevant to the point. I think it's the general trend that early in languages lives its much easier to contribute to the tools, after decades of amassing improvements (such as yours!) they tend to become less accessible.

But regardless, the "rewrite in rust" advocacy has created a significant opportunity for projects created by single people, without outside review and often without significant domain expertise (at least where they are slavish re-implementations of existing code), to be proposed as replacements for longstanding stable tools. Whatever the merits of that chance it's also dream for someone looking to introduce new vulnerabilities. Even where the replacement itself is reviewed it will usually come with a massively expanded dependency footprint which isn't.

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

#280

Earlier quoted context omitted.

Well computing has gotten a lot more complex since c’s inception. It’s model has held up well but the cracks are there

Programs are a lot more complex. The computers aren't. They were far less homogenous in the early years. Today you have a octet addressed little endian integer machine, with ieee float hardware and a small vector unit. Maybe you have two different instances of that on the same address space, but probably just one. I think reasonable argument could be made that the complexity in modern computing is primarily self infl…

Computers have gotten much more complex. Maybe your OS provides that nice little bubble for you, but it’s an illusion
Post reply on HN