It’s not. Numbers are arranged (both binary and base 10) with the most significant digit on the left.
Whether you read the number from left to right or right to left is irrelevant and you can choose whichever one you want.
But it is completely consistent with base 10 (normal numbers).
As a rust developer I feel obligated by religion to make this comment:
Then you’d love rust! Rust only has “interfaces” (called traits) but doesn’t have inheritance. You just have traits that don’t inherit from anything and structs (that don’t inherit from other structs) that implement X amount of traits.
So you can have the good things about OOP without the bad ones.
And these traits allow you to make trait objects, which would be like regular objects in C# (with vtables for the methods). If 2 different structs implement the same trait, you can “downcast” them to a trait object and store them in the same array. Or pass it is an argument to a function that wants something that implements that trait but doesn’t care about the specific struct. You can of course cast it back later to the original struct.
The windows crate is full of Deref. Because the windows API is full of inheritance.
It may not be what the trait was thought of for, but I’m glad we have it to interface with APIs that have actual inheritance.
But if I have to make an Array I have to inherit from Indexable which inherits from Collection which inherits from Object! How else am I supposed to implement an Array?
I know this thread is old. But I disagree with you.
I agree that depending on how you use a debugger, some race conditions might not happen.
However, I don’t agree that debuggers are useless to fix race conditions.
I have a great example that happened to me to prove my point:
As I was using a debugger to fix a normal bug, another quite strange unknown bug happened. That other bug was indeed a race condition. I just never encountered it.
The issue was basically:
And so handling the session start and session end at the same time resulted in a bug. It was more complicated than this (we do use mutexes) but it was along those lines.
We develop in a lab-like condition with fast networking and computers, so this issue cannot happen on its own. But due to the breakpoint I put in the session initiation function, I was able to observe it. But in a real world scenario it is something that may happen.
Not only that, I could reproduce the “incredibly rare” race condition 100% of the time. I just needed to place a breakpoint in the correct place and wait for some amount of time.
Could this be done without a debugger? Most of the time yes, just put a sleep call in there. Would I have found this issue without a debugger? Not at all.
An even better example:
Deadlocks.
How do you fix a deadlock? You run the program under a debugger and make the deadlock happen. You then look at which threads are waiting at a lock call and there’s your answer. It’s as simple as that.
How do you print-debug a deadlock? Put a log before and after each lock in the program and look at unpaired logs? Sounds like a terrible experience. Some programs have thousands of lock calls. And some do them at tens of times per second. Additionally, the time needed to print those logs changes the behaviour of the program itself and may make the deadlock harder to reproduce.
Good rule of thumb. As long as it’s not followed blindly of course.
Structs with lifetimes are often quite convenient. Especially for performance.
From a non-technical user’s pov kinda true.
But not true at all when you enumerate the actual responsibilities of an OS.
Not really. Today at work that error appeared to me. As a software developer of course I have access to terminal, I use it every day.
I just closed the message and opened the terminal again, and it worked.
This is Microsoft’s fault, not any other’s.
In my case, I don’t usually encounter cases where I can’t just ?. But when I do, just make an error enum (kinda like thiserror) that encapsulates the possible errors + possibly adds more.
On the call site, just convert to string if I don’t care about specifics (anyhow-style).
I don’t find this much painful.
Concise: not much on the declaration side, since you have to create an entire enum for each function in worst-case scenario. But on code side, it’s just .map_err(MyError)?.
Type-safe: can’t beat errors as enum values wrapped in Result.
Composable: i don’t think you can beat rust enums in composability.
I don’t use anyhow/thiserror, so I’m not sure. But I believe thiserror fixes the conciseness issue for this.
“not having mandatory parenthesis in if statements is hazardous, so I prefer to write C instead of rust, because I really care about safety” < that’s how you sound.
Rust allows you to choose whatever method you want.
There are only 2 error handling methods that you cannot do:
And that is because both of them are bad because they allow you to do the second one, when .unwrap is just there and better.
If your concept of “not ugly” is “I just want to see the happy path” then you either write bad code that is “not ugly” or write good code that is “ugly”. Because there is no language that allows you to handle errors while not having error handling code near where the errors are produced.
Most of the times you can just let ... else (which is basically a custom ? if you need if let ... else it’s because you actually need 2 branching code paths. In any other language you also do if ... else when you have 2 different code branches. I don’t see why this is a rust-specific issue.
I’d say it’s much more influential the names of the identifiers of the standard library.
A language with function keyword that names it’s stdlib functions strstr and strtok will inspire way worse naming than on that has fn keyword with stdlib functions str::contains and str::split.
We could search for a random crate on crates.io and see what identifiers people actually use, or we could spread misinformation on Lemmy.
You used macro_rules, which is not common at all. Most rust files don’t contain any macro definition.
This code doesn’t even compile. There is a random function definition, and then there are loose statements not inside any code block.
The loop is also annotated, which is not common at all, and when loops are annotated it’s a blessing for readability. Additionally, the loop (+annotation) is indented for some reason.
And the loop doesn’t contain any codeblock. Just an opening bracket.
Also, the function definition contains a lifetime annotation. While they are not uncommon, I wouldn’t say the average rust function contains them. Of course their frequency changes a lot depending on context, but in my experience most functions I write/read don’t have lifetime annotations at all.
Yes, what you wrote somewhat resembles rust. But it is in no way average rust code.
Not to be confused with glibc. Where the g does actually stand for gnu.
But they can’t say “I’m going to rewrite this in that other language” because that’s the thing they hate about rust, so if they said that it would be too obvious that they’re full of shit.
Any body could just go to down detector. And of course effectively check the status of cloud flare based on if downdetector shows this page themselves.
This can also be a side product for code blocks being expressions instead of statements.
In rust for example they are, so it’s not rare to see functions like:
fn add_one(x: i32) -> i32 {
x+1
}
This lets you do amazing things like:
let x = if y < 0.0 {
0.0
} else {
y
}
which is the same as
x = y < 0.0 ? 0.0 : y
But is much better for more complex logic. So you can forget about chaining 3-4 ternary operations in a single line.
What a bad take. Notepad was never meant to have formatting, as the post states. Notepad’s purpose was to open war text files as raw text. For formatted text, there was WordPad. What made notepad great is that it was the fastest and easiest way to just know what is in the damn file.