questioner8216

5 ms·

1.
by questioner8216 10mo ago
I am not breaking any rules, instead my comments are on point and show better debate culture than other comments, including better than yours and the previous comment. Please do better. You are at fault 100%, and you are well aware of it. E
2.
by questioner8216 10mo ago
[flagged]
3.
by questioner8216 10mo ago
It seems completely clear. He first gives unidiomatic C++ code, then next gives idiomatic Rust code, and differentiates the two based on the code snippets. It is a mistake on his part, and I do not see how it could reasonably be viewed othe
4.
by questioner8216 10mo ago
I have not given it much thought, but it would primarily be for the subset of Rust programs that do not need zero-cost abstractions as much, right? Since, even in the case of no panics, one would be paying at runtime for registering panic h
5.
by questioner8216 10mo ago
When comparing languages, posting unidiomatic code, and then making claims based on that unidiomatic code, is generally not fair nor correct.
6.
by questioner8216 10mo ago
I am not sure that I understand what scoped panic hooks would or might look like. Are they maybe similar to something like try-catch-finally in Java? Would the language force the programmer to include them in certain cases somehow? If a req
7.
by questioner8216 10mo ago
Right, I forgot that 'const' in Rust is 'constexpr'/'consteval' in C++, while absence of 'mut' is probably closer to C++ 'const', my apologies. C++ 'constexpr' and Rust '
8.
by questioner8216 10mo ago
But Rust's async is one of the primary ways to handle concurrency in Rust, right? Like, async is a core part of how Tokio handles concurrency.
9.
by questioner8216 10mo ago
Good points. I have also heard others say the same in the past regarding Go. I know very little about Go or its language development, however. I wonder if Go could easily add some features regarding that. There are different ways to go abou
10.
by questioner8216 10mo ago
That is a different topic from what I wrote about. The article wrote: > Automatic unlock: When you lock, you receive a guard. When the guard goes out of scope, it automatically unlocks. No manual cleanup needed. And presented Rust as bei
11.
by questioner8216 10mo ago
For that last example, if 'item' is immutable, there is no issue, correct?
12.
by questioner8216 10mo ago
Rust concurrency also has issues, there are many complaints about async [0], and some Rust developers point to Go as having green threads. The original author of Rust originally wanted green threads as I understand it, but Rust evolved in a
13.
by questioner8216 10mo ago
I dislike some of this article, my impression is similar to some of the complaints of others here. However, are Go programs not supposed to typically avoid sharing mutable data across goroutines in the first place? If only immutable message
14.
by questioner8216 10mo ago
That sounds really interesting, whether it is done in Rust, some Rust 2.0, or a successor or experimental language. I do not know whether it is possible, though. If one does not unwind, what should actually happen instead? How would for ins
15.
by questioner8216 10mo ago
I am not very familiar with C++'s API, but I believe that you are right that the C++ example in the article is incorrect, though for a different reason, namely that RAII is supported also in C++. In C++, a class like std::lock_guard al
16.
by questioner8216 10mo ago
Questions for anyone who is an expert on poisoning in Rust: Is it safe to ignore poisoned mutexes if and only if the relevant pieces of code are unwind-safe, similar to exception safety in C++? As in, if a panic happens, the relevant pieces