Can we throw Python in too? Python has more safety than any of these languages, yet it's always left out of these discussions.
You're joking, right? A dynamically-typed language has more safety?...
Safety: A comparaison between Rust, C++ and Go
121–130 of 188 posts
Re: Safety: A comparaison between Rust, C++ and Go
#122Earlier quoted context omitted.
This has been a recurring theme from you, but in the cases you're describing the risk is only a race condition (no general solution is possible) and not a data race (which safe Rust is able to deny by design). These are categorically different problems.
Because it is a recurring theme to ignore the other kind of race scenarios when promoting Rust's type system.
People have to consider race conditions anyway, they're part of our world. For example if you use git's ordinary --force to overwrite certain changes that's subject to a TOCTOU race, which is why force-with-lease exists. Even in the real world, I once opened a bedroom window to throw a spider out onto the garden below and a different spider came in through the window in the brief interval while it was open - exploiting the "open window to throw out spider" race opportunity.
Data race isn't just "Oh it's just a race condition" or Rust wouldn't care, data races destroy Sequential Consistency. And humans need sequential consistency to reason about the behaviour of non-trivial programs. So, without this writing concurrent software is a nightmare. Hence, "fearless concurrency".
You won't destroy sequential consistency by having non-transactional SQL queries. Try it.
Re: Safety: A comparaison between Rust, C++ and Go
#123Earlier quoted context omitted.
>> In the end either safety is either important, or it isn't. Choose accordingly. Not to disagree with your post but this comes across as very black-and-white.
To expand: There's a prioritized list of requirements in engineering. Use the right tool for the job. Rust has: (see https://hackmd.io/@rust-ctcft/r1plN4You#/5 ) 1. Safety If you don't need that at the first slot, then the biggest strength of Rust doesn't apply to your problem (and you would waste time having to track lifetime parameters more than necessary to solve your problem).
Big problem in these discussions is what should be prioritized.
To me, with the 20 years of experience I have in 8 programming languages, I'll always include safety. Especially having in mind that it's nearly zero-cost in terms of runtime performance.
So to me not choosing safety is a strong sign that I don't want to work with the people who practice that.
Re: Safety: A comparaison between Rust, C++ and Go
#124Earlier quoted context omitted.
> Most of the C++ I maintain these days is in whole or in part generated by Haskell Can you expand on that? I'm currently researching something similar but lower level & lisp instead of Haskell. It would help to see some existing examples to figure out if it's worth it or not.
Ideally we'll just be able to open source it soon! Basically we have a nice Haskell DSL for generating arbitrary C++, and we deal with lots of code you wouldn't want to write by hand (big nested switch statements and other kinds of state-machine logic, choices about loop unrolling, lots of template overloads, SIMD intrinsics that require immediate values, etc. etc.) so we write Haskell that generates C++ and feeds it…
Sounds great, that's what I was imagining too. Is there a way I can find it when/if you open the source?
Re: Safety: A comparaison between Rust, C++ and Go
#125Earlier quoted context omitted.
I find it so weird that the Rust community is borderline evangelical about memory safety when a) it's not actually memory safe once you start doing heavy shit b) modern C++ is quite memory safe and c) there are so many other great reasons to like Rust. Memory safety in serious systems software is something that you approach asymptotically and/or probabilistically. Rust makes it easier to be memory safe in a lot of sc…
>a crashed program is a crashed program whether I dereferenced a null pointer or was poking around in a slice with multi-byte Unicode characters in it Most of the biggest advances in software engineering are because of increased modularity. One of the best traditional ways to increase modularity is the ability to define and call functions. But any isolation between these "function" modules is only possible if you can…
rustc rejects the resulting program if you mechanically factor out a function accessing &mut self, into a function holding mutable borrows to half the fields calling another function which access the other half of fields (or vice versa, the caller holding &field calling a method mutating other fields). This requires the more complex transformation of passing individual fields into the subfunction (more work, but sometimes easier to read), or waiting for Rust to add partial borrows. Note I've never actually hit this case myself, though I've heard it's an issue people run into.
Re: Safety: A comparaison between Rust, C++ and Go
#126Earlier quoted context omitted.
Because it is a recurring theme to ignore the other kind of race scenarios when promoting Rust's type system.
People have to consider race conditions anyway , they're part of our world. For example if you use git's ordinary --force to overwrite certain changes that's subject to a TOCTOU race, which is why force-with-lease exists. Even in the real world, I once opened a bedroom window to throw a spider out onto the garden below and a different spider came in through the window in the brief interval while it was open - exploit…
I have tried plenty of times, and seen not so happy train travelers with the same ticket for the same place on the same train, hence why bring it up all the time.
It is obvious it is a subject that is irrelevant in the Rust community.
Who needs consistency in distributed systems when multiple threads from the same process are accessing the same external data without coordination.
Re: Safety: A comparaison between Rust, C++ and Go
#127Earlier quoted context omitted.
People have to consider race conditions anyway , they're part of our world. For example if you use git's ordinary --force to overwrite certain changes that's subject to a TOCTOU race, which is why force-with-lease exists. Even in the real world, I once opened a bedroom window to throw a spider out onto the garden below and a different spider came in through the window in the brief interval while it was open - exploit…
I have tried plenty of times, and seen not so happy train travelers with the same ticket for the same place on the same train, hence why bring it up all the time. It is obvious it is a subject that is irrelevant in the Rust community. Who needs consistency in distributed systems when multiple threads from the same process are accessing the same external data without coordination.
> Who needs consistency
Programmers do. Programmers are human and so can't reason about the behaviour of non-trivial programs without sequential consistency.
If I was trying to debug software which sometimes mistakenly issues people duplicate tickets, I think I'd want to be able to reason about how the software works, and that's not going to be possible if it doesn't even exhibit sequential consistency.
Re: Safety: A comparaison between Rust, C++ and Go
#128Earlier quoted context omitted.
I have. `cxx` and `autocxx` and `bindgen` and `cbindgen` are, better than nothing I guess? But they're all flakey and have weird corner cases (and crash sometimes! I'm looking at you `cbindgen`!) and don't handle containers well if at all and just, ugh. I always end up saying fuck it and `extern "C"`-ing everything. It would be completely possible to make these tools work well, but the Rust ethos is "rewrite everythi…
> But they're all flakey and have weird corner cases and crash sometimes! Did you report those crashes? There's also crubit these days, mostly combining the autocxx and (c)bindgen approaches. (It's a very new effort, which is why it's being kept separate from these more established ones.)
was not aware of crubit, so thanks for posting. i'm trying to follow closely what's happening in this space
Re: Safety: A comparaison between Rust, C++ and Go
#129Earlier quoted context omitted.
Because it is a recurring theme to ignore the other kind of race scenarios when promoting Rust's type system.
People have to consider race conditions anyway , they're part of our world. For example if you use git's ordinary --force to overwrite certain changes that's subject to a TOCTOU race, which is why force-with-lease exists. Even in the real world, I once opened a bedroom window to throw a spider out onto the garden below and a different spider came in through the window in the brief interval while it was open - exploit…
Is Rust really "fearless concurrency" ?
Considering the number of deadlock issues encountered by folks using async Rust, I think "fearless concurrency" is misinformation by Rust evangelists.
Deadlocks in production Rust microservice:
https://blog.polybdenum.com/2022/07/24/fixing-the-next-thous...
Re: Safety: A comparaison between Rust, C++ and Go
#130This would be a better article if the UB in the C++ example wasn't blindingly obvious-- no C++ programmer worth a damn would ever write this.
Yeah, agreed that a competent C++ dev would not write the code in the example. The charitable interpretation though is that errors of the same type can crop in real codebases, the example is just simplified for the purposes of discussion.
In such examples you’re always primed to look for a mistake. It’s a different situation when you have 100K+ lines of code, a dozen developers, and a deadline.
It’s a difference between “look this is Wally” (duh, of course) and a game of “Where’s Wally?”.
Whenever a CVE is discussed people say that the error is obvious, and no good programmer would write like that. It’s easy in hindsight.