331–340 of 341 posts
Earlier quoted context omitted.
> I would love to hear what he thinks a good programming language is not OP, but outside of extreme performance critical software I MUCH prefer Swift, C# or python.
C# is really good, but is Swift good enough as true general-purpose language for every platform and OS?
Earlier quoted context omitted.
> Yeah, that's why my first comment in this thread was "Just having unsafe in your codebase means changing code outside the unsafe block could cause UB". You can caveat that with "that's bad code", but that's the reality. I agreed with you that changing safe code could trigger the bug, but the safe code is not where the bug is . > Nobody is saying that, you're just moving goalposts now. Nobody is saying you should al…
See my comment to @Capricorn2481 here[0]. You seem to be saying that unsafe code can be made correct so as to ensure soundness. This can be done by verifying invariants in unsafe code, but it is generally discouraged, as it tempts large unsafe blocks that could be partially safe code. Both you and @Capricorn2481 don't seem to make the distinction between "arbitrary safe code" and "my safe code within the module with…
So the categories of code: the unsafe block, the friend code that shares responsibility for invariants, the outside world code
Capricorn2481's mistake is putting the entire program in the second category, when only code in the same module is supposed to be there.
If a memory violation happens, you know you have a bug in a module containing unsafe blocks, which helps a lot. Those modules should be relatively rare and as small as possible.
Earlier quoted context omitted.
> Come on, please tell me you don't do this in your code. I don't, but that's not to say that I think it should never be done. > Formally you are correct, but there are many things in C++ that should have better not existed. Sure, but I think it's important that one should do their best to be correct and/or precise. > Because it would lose most of the Rust properties by that time. Perhaps for specific bits of code, b…
>I'm curious how you came to that conclusion. It seems wrong both on a theoretical level (Drop/unwinding/catch_unwind should obviously suffice for at least some cases?) and on a practical level (tokio can recover from worker thread panics just fine?). Tokio provides crash-resistant synchronization primitives, but it cannot recover complex structures you've been handling — you either need to write panic-handlers that…
Maybe I'm a bit confused, or I haven't made my point clear enough. I'm not trying to say that Rust will clean up errors in the same way languages like Erlang do. I'm saying that you can write Rust that will clean up errors in the same way languages like Erlang do. In short, what I'm protesting is the absoluteness of the claims.
That being said, I also feel like you're comparing apples and oranges to some extent here. I don't think the more complex recovery you're describing in the Tokio example is the same thing as the cleanup you describe "languages designed for crashes" as implementing. I think the cleanup you describe "languages designed for crashes" as implementing is "weaker" (in a CS theoretical sense) than the more complex manual recovery you describe as being required when using Tokio, which means you still need to write said more complex manual recovery even in languages like Erlang.
For example, consider this email from Joe Armstrong [0]:
> In C etc. you have to write *something* if you detect an error - in Erlang it's easy - don't even bother to write code that checks for errors - "just let it crash".
> Then write a *independent* process that observes the crashes (a linked process) - the independent process should try to correct the error, if it can't correct the error it should crash (same principle) - each monitor should try a simpler error recovery strategy - until finally the error is fixed (this is the principle behind the error recovery tree behaviour).
At least from how I read this, there's no fully "automatic[] clean up"; you still need to write the moral equivalent of "panic-handlers that would revert your data to more-or-less manageable state or employ ready-made libs that do it for you". Erlang/BEAM/etc. is not going to automatically correct errors for you in all possible cases - if it were, there would be no need to write that yourself - so I don't think it's reasonable to expect that from Rust either.
In addition, nothing here jumps out to me as being impossible to implement in Rust. Use nested threads, use catch_unwind to stop unwinding from killing the entire process, write appropriate panic handlers, etc. and you should get a similar result.
Perhaps you had a different example in mind?
[0]: https://erlang.org/pipermail/erlang-questions/2003-March/007...
> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…
A pacemaker in an unknown state goes forever undiagnosed.
Rust has its issues and there are plenty of things to not like about Rust, but this article is giving me the impression that this person has not written much Rust. Unfortunately, many such cases with Rust criticism. > Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliabi…
>Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface. Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source…
Yes you can have other bugs. What is this argument about? How about having just other bugs instead of other bugs and memory unsafe bugs?
> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly. > If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak co…
It was trying to push an element into a full ArrayVec. The options are:
- Blindly write off the end of the array. Obviously no one wants this, despite the decades of tradition...
- Panic and unwind, as the program actually did in this case.
- Return an error.
Some folks assume that returning an error instead of unwinding would've been better. But my assumption is that the outcome would've been the same. I think the issue came up when loading configs, which isn't usually a recoverable situation. If you have an "invalid config error", you're probably just going to return that all the way up, which is effectively the same outcome as unwinding: your process exits with an error code. There are cases where the difference matters a lot, but I don't think this was one of them.
The real gap seems to be why it took hours for folks to notice that this service was crash looping. That should normally be really prominent in alerts and dashboards. (Probably part of the story is that alerts were firing all over the place. Tough day at the office.)
Earlier quoted context omitted.
>Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface. Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source…
>However, as already implied in my article, you can get most of the guarantees without losing your sanity. Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust? I'll use "safety" in a loose term to say "you really infrequently encounter odd memory safety issues". Go for example still has the occasional memory corruption issues with maps in particular although these don't sho…
[1]: vlang.io
[2]: github.com/vlang/v/blob/master/doc/docs.md
You cannot go along like “I’m writing a cold path high-level code, I don’t need performance, I don’t need to go deeper into lifetime handling, I just want to write a high level logic”. You will be forced into the low level nuances every time you write a single line of Rust. There is no garbage collector for Rust and will never be — you will have to semi-manually pack all your data into a tree of ownership. You have t…
the issues with Crystal, nim, zig, is that they have zero changes to be bigger.
Use D.