461–470 of 492 posts
Earlier quoted context omitted.
True, however I only saw this happens to achieve max perf. I have very limited experience so this is confirmation bias from my end.
An example of unsafe not for performance is when interacting with hardware directly.
opening stdout with file handle 0 is not guaranteed safe by the compiler. there's an "unsafe" somewhere in there.
Earlier quoted context omitted.
And I didn't say this was about Rust the language. I said many times it's not OK for you to generalize an entire community of hard-working people. It will never be OK. What is actually funny in our exchanges is that I don't even actively work with Rust anymore. I work with multiple languages, it included. I've met very smart, humble and fairly hardcore [Rust] devs from whom I learned a lot and got severely humbled as…
> generalize an entire community of hard-working people By claiming they are hard-working, you are generalizing. It is usually only a couple or few that are actually hard-working people, but then again, I am generalizing because I do not know, I do not wish to actually claim to know. Judging by your comments, e.g. "you should be ashamed" (for simply expressing his dislike of YOUR community), you sound exactly like a…
Fair, I appreciate the call-out and it's a valid one.
> Judging by your comments, e.g. "you should be ashamed" (for simply expressing his dislike of YOUR community), you sound exactly like a zealot.
It's not that. I said he should be ashamed because he doubled down on generalizing. Even said he usually does that a lot. To me if you work in tech you should be more analytical and more unforgiving towards your own assessments. We all thought the bug is in X but it turned it was in Y, right? That's what I called out.
As you yourself pointed out, we don't truly know much people in the community are generally nice and hard-working, which I agree is an accurate call for a balanced take.
My problem is the outright negative generalization. I was in the mood and didn't leave him alone about it. He eventually seems to have admitted that he only demonstrated his own anecdotal evidence. I disengaged at that point because that's a valid way to exit a discussion... though I still would worry what kind of people he communicated with if he had such an overwhelming negative experience, and only with its most lunatic members to boot.
You are free to think of me as a zealot but I'd think that's an emotional and unfair reaction and would ask you to revise it. My comments were not a stubborn push-back, but a call to being objective.
> Why do you feel the need to claim moral superiority and tell someone to be ashamed just for simply expressing their dislike of your community? And while we are at it, he probably dislikes the community because of people like you. We have gone full circle.
I claimed analytical superiority, not a moral one. I've met Rust zealots. I've met Golang and (oh boy are they MANY) C/C++ zealots. Even my favorite Elixir has some weird people that think everything should be written with it.
The difference between me and the poster you seem to defend a bit emotionally is that I don't claim my outlier negative experiences are the norm. He did that. I did not.
As for the full circle thing: I ain't giving the other cheek. I don't owe grace to people who are rudely generalizing. I am aware many people would assess me much better if I just gave the other cheek. I know. But I choose not to abide by those expectations. Sadly this leads to people like yourself branding me like a zealot. Regrettable. But it's ultimately your loss for missing out on interesting and informed and unbiased discussions with me.
Feel free to check my comment history. I am not always super level-headed but I always look for the truth.
> Sounds condescending as well, but this is a minor nitpick. :)
Couldn't resist, admittedly. See above. ;)
Earlier quoted context omitted.
I see the issue. Biased people like yourself don't belong in tech. For the record, I only picked Rust 5-ish years ago out of a 23 years of career. I know plenty of other languages. I was a skeptic at the start as well. Never generalized a pretty big group like you do though. You should be ashamed.
He should be ashamed because he does not like your community?
And it's not "my" community. I don't belong to a single one so I don't emotionally defend any of them.
Earlier quoted context omitted.
> never actually seen the people doing that thing I'm happy to share then. Here's my most recent encounter with a rustacean: https://x.com/_chjj/status/1829989494298460636 I asked if he/she/they had ever used the unsafe keyword. That was the response I got. It's usually some vile insult involving furry or transgender genitalia.
Honestly, that website is so far off the end of the sanity meter that I don't know what to say. Technically, you are right in that counterexamples exist. But on platforms like HN/techincal subreddits etc., never seen it myself, suggesting the problem is far less widespread than one might be initially moved to assume.
I mean, by that logic, people of my nationality would have to be fenced off and never allowed in other countries... because we do indeed have thousands of nasty scammers out there in the world.
99.99999% of us are chill, work, pay taxes, have fun etc.
So generalizations like the one that moved me to start pursuing the guy and not leave him alone until he ultimately said "it's just my anecdotal experience" (and stopped claiming it's universally true), because you know, we can pick ANY group, find several lunatics and claim the group is bad in this or that way.
As said to another guy a few minutes ago -- I can get such "opinions" in every bar. I come to HN for better discussions than this.
Earlier quoted context omitted.
"The encapsulation referred to here is that you can expose a safe API that is impossible to misuse in a way that leads to undefined behavior. That's the succinct way of putting it anyway." Well, no, actually. At least, not in an (IMHO) useful way. I can break your safe API by getting the constraints wrong on unsafe code inside that API. Also, unsafe usage elsewhere is not local. I can break your impossible to misuse…
Are you writing lots of FFI and/or embedded code? Those are the main places I see unsafe being used a lot. The tooling and the encapsulation go hand in hand. > The idea that you will convince people not to write broken unsafe code, in ways that breaks safe APIs, or that the ability to assign blame matters, is very strange to me, and is no better than C. As systems grow, the likelihood of totally safe transmutes growi…
There is still plenty in my non-embedded stuff, but a fair amount hardware-adjacent (IE i have to drive things like relay cards, just from a desktop machine). to be fair.
But i've found plenty of broken unafe in things like, uh, constraint solvers.
I would agree that useful and successful rust projects aggressively encapsulate (and attempt to avoid) unsafe usage.
I will still maintain my belief that this will not be enough over time and scale.
Earlier quoted context omitted.
"The encapsulation referred to here is that you can expose a safe API that is impossible to misuse in a way that leads to undefined behavior. That's the succinct way of putting it anyway." Well, no, actually. At least, not in an (IMHO) useful way. I can break your safe API by getting the constraints wrong on unsafe code inside that API. Also, unsafe usage elsewhere is not local. I can break your impossible to misuse…
> I can break your safe API by getting the constraints wrong on unsafe code inside that API. This doesn't make any sense at all as a broader point. Of course you can break the safe API by introducing a bug inside the implementation! I honestly just cannot figure out how you have a misunderstanding of this magnitude, and I'm forced to conclude that we are mis-communicating at some level. I did read the rest of your co…
My suggestion would be - if we are ever in the same place, let's just grab coffee or something.
In the end - i suspect we are just going to find we have different enough experiences that our views of safe encapsulation and its usefulness are very different.
Let's put that aside for a second - I'll also take one more pass at the original place we started, and then give up:
To go back all the way to where we started, the comment i was originally replying to said "No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness."
So we were in fact talking about scale and more particularly how to scale to global correctness, not really whether rust enables safe encapsulation, but whether encapsulation istelf enables local reasoning to scale to global correctness (In theory or in practice)
My view here, restated more succinctly, is "their claim that encapsulation is the only way to scale local reasoning to global correctness is emphatically wrong" (both in theory and practice).
My argument there remains simple: Tooling is what enables you to scale local reasoning to global correctness, not encapsulation.
Putting aside how useful or not it is otherwise for a second, encapsulation, by itself, does not enable you to reason your way from local results to global results soundly at all - for exactly the reason you mention in the first sentence here - bugs in local correctness reasoning can have global correctness effect. Garbage in, garbage out. Encapsulation does not wave a wand at this and make it go away[1]. There are lot of other reasons, this is just the one we went down a bit of a rabbit hole on :)
Instead, it is tooling that lets you scale. If you can have "catches 95+%" of local reasoning error (feel free to choose your own bar), you can almost certainly parlay that into high-percent global correctness, regardless of whether anything is encapsulated at all or not.
Now: If encapsulation enables an easier job of that tooling, and i believe it helps a lot, fwiw, then that's useful. But it's the tooling you want, not the encapsulation. Again, concretely: If I could not safely encapsulate anything, but had tooling that caught 100% of local reasoning issues, i would be much better off than having 100% safely encapsulated code, but no tooling to verify local or global reasoning. This is true (to me) even if you lower the "catches 100% of local reasoning issues" down significantly.
[1] FWIW, i also don't argue that this problem is particular to rust. It's not, of course. It exists everywhere. But i'm not the one claiming that rust will enable you to scale local reasoning to global correctness through encapsulation :P
Earlier quoted context omitted.
This is known as the Second System Effect: where Great Rewrites always succeed in making a more performant thing.
I am not sure if the semantics have drifted over the decades to what you say, but this seems not quite right according to wikipedia: https://en.wikipedia.org/wiki/Second-system_effect EDIT: but I do agree that starting greenfield from an old code base is often a path towards performance.
Earlier quoted context omitted.
I assume you are hinting at 'int' is signed here? And, that signed overflow is UB in C? Real question: Ignoring what the ISO C language spec says, are there any modern hardware platforms (say: ARM64 and X86-64) that do not use two's complement to implement signed integers? I don't know any. As I understand, two's complement correctly supports overflow for signed arithmetic. I might be old, but more than 10 years ago,…
AI rewrote to avoid undefined behavior: int average(int x, int y) { long sum = (long)x + y; if(sum > INT_MAX || sum
Earlier quoted context omitted.
AI rewrote to avoid undefined behavior: int average(int x, int y) { long sum = (long)x + y; if(sum > INT_MAX || sum
I don't know why this answer was downvoted. It adds valuable information to this discussion. Yes, I know that someone already pointed out that sizeof(int) is not guaranteed on all platforms to be smaller than sizeof(long). Meh. Just change the type to long long, and it works well.
Earlier quoted context omitted.
It seems like you've got it backwards. Even unsafe rust is still more strict than C. Here's what the book has to say ( https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html ) "You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to: Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static va…
I believe the post you are replying to was referring to the fact that you could take actions in that unsafe block that would compromise the guarantees of rust; eg you could do something silly, leave the unsafe block, then hit an “impossible” condition later in the program. A simple example might be modifying a const value deep down in some class, where it only becomes apparent later in the program’s execution. Hence…