141–150 of 188 posts
Earlier quoted context omitted.
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).
There's also another item in that list, and that is performance. As soon as you slightly relax that one, Rust does become massively easier. A well placed .clone() or Arc makes the rest of the code performant enough and easier to understand, which makes the equation of choosing Rust over other alternatives in spaces that aren't necessarily systems programming less problematic.
The .clone() would have been [=] in C++, which would have safely quieted the warning.
Earlier quoted context omitted.
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.
So, safety, good, fast enough, good, but insufficiently expressive? No, thank you.
Earlier quoted context omitted.
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.
The point missed everywhere is that Rust lacks key language features needed to capture essential semantics in libraries, that C++ provides. To code libraries I want to code, I cannot use Rust. Rust cannot express them. So, safety, good , fast enough, good , but insufficiently expressive? No, thank you.
Want to elaborate on that? Quite curious.
Disingenuous. The bad C++ code is in the very first line of the "make_appender" definition: capturing the closure's environment by reference is nonsense: It is equivalent to returning a reference to an argument. It is not, then, a closure at all. Using a correctly-defined make_appender would not, then, produce undefined behavior when you use it, with or without "move". What the author has done here was to take a too-…
A function returning a value that depends on the lifetime of the function's parameter is not crazy at all. Every class getter method that returns a reference to a member of the class does this.
Getters that return references are code stink.
Earlier quoted context omitted.
This is a point that you constantly bring up in these threads, do you think most developers believe that data race safety should extend beyond the bounds of the process? One thing that Rust’s type system does allow you to do is define a consistent manner in which to access external systems, even add types that will mimic the same safety. Is it perfect? Will it protect you from a different process working against the…
Yes, when they care about data consistency in distributed systems. Maybe many Rust devs don't care.
Even if we account for everything, solar storms will eventually flip bits unexpectedly. Does that make Rust’s guarantees worthless?
Earlier quoted context omitted.
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.
The point missed everywhere is that Rust lacks key language features needed to capture essential semantics in libraries, that C++ provides. To code libraries I want to code, I cannot use Rust. Rust cannot express them. So, safety, good , fast enough, good , but insufficiently expressive? No, thank you.
Earlier quoted context omitted.
Pain is a strong warning that prevents [further] trauma. This analogy defeats its own purpose.
The doctor says, "then don't do that". So, the analogy is correct, and you have missed the point.
Earlier quoted context omitted.
> 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.
Your argument amounts to "Rust prevents X, so X is important. Rust cannot prevent Y, therefore Y is less important."
I rather like Lamport's last observation about what happens if you don't have sequential consistency and instead your programs just put up with whatever was cheap/ efficient to implement (as will happen by default on a modern multi-core CPU): "verifying their correctness becomes a monumental task"
It was later proved that it's not merely "monumental" this is actually an undecidable problem in general which explains why humans aren't good at it.
So, this is important in principle to get right, and (safe) Rust does so. You are of course welcome to decide you don't care, why aim to write correct programs anyway? And for now at least it seems in our industry many people agree.
I feel like a better comparison would be to use std::span (C++20) to mimic Rust's slice. Otherwise you might be tricked into thinking that adding // hey don't pass in a temporary auto make_appender(std::vector && suffix) = delete; (which turns the provided code into a compiler error under both g++ and clang++) is adequate to prevent the immediate class of issues (namely, C++ allows const Foo& and Foo&& to bind to tem…
That would just be another tendentious example. Nobody would write a make_appender that takes a span argument, because it makes no sense. The point we should take away is that is actually hard to invent plausible examples of the failure that we are being told Rust would prevent.
I don't agree with that. If you can guarantee that the data pointed to by the span will outlive your appender, then it's safe. And if you don't actually want to transfer ownership or incur the overhead of a copy, and you don't care if your input is a vector or an array, then it's the correct abstraction.
Replace std::span with std::weak_ptr (or a raw pointer), and replace the closure with a class (e.g. a tree where each node has a weak pointer to its parent), and tell me again that nobody would ever write that code. It's fundamentally the same concept: if your ownership model isn't ironclad, or if any of your assumptions are ever violated, then you can run into use-after-free.