Bash might be better than IE. But I think we can agree that it is no longer a good shell.
Its syntax is awful, and lacks many features that other shells have.
It is only so widely used because it is a de facto standard. If bash was created today, barely no one would us it.
For me it’s the opposite. Lossy ones (the ones that seem to maintain quality while lowering size by a lot) are magic to me but lossless is understandable.
What do you mean “treat this image as a wave and do an inverse Fourier transform on it in order to discard the high frequency low amplitude noise”. wtf? Straight up magic.
They may be worse than a very good programmer. But will be much faster answer. The real captcha is not to check if the answer is correct. It is to check the time it takes to answer.
Except humans that are not very good programmers will just give up and answer quite fast. Or just click away lol.
I haven’t read 90% of your comment since it is out of the topic of the discussion. The “trap” is trying to argue with mee about something I haven’t even mentioned.
I don’t know whatever that language is doing is called, but it’s not reference counting. It’s doing some kind of static code analysis, and then it falls back to reference counting.
If you call that reference counting, what stops you from calling garbage collectors reference counting too? They certainly count references! Is the stack a reference count too? It keeps track of all the data in a stack frame, some of it might be references!
I don’t know what you read on my reply. But your reply makes no sense.
Let me rephrase it if you prefer:
Claiming that Rusty’s borrow checker is reference counting is hugely misleading. Since the borrow checker was made specifically to prevent the runtime cost of garbage collection and reference counting while still being safe.
To anyone unaware, it may read as “rust uses reference counting to avoid reference counting, but they just call it borrow checking”. Which is objectively false, since rust’s solution doesn’t require counting references at runtime.
I don’t know what mutable string or any of the other rant has to do with reference counting. Looks like you’re just looking to catch a “rust evangelist” in some kind of trap. Without even reading what I said.
There is no reference counting if the count is always one.
The defining feature of reference counting is that its a runtime check. Which in turn results in a runtime performance.
If there is no in memory counter at runtime, nobody calls that reference counting.
“good code is better than mediocre code” definitely one of the statements of all time.
It’s more than 10 years old. It has stable syntax, big standard library, big library ecosystem, plenty of rust programs already in production.
If by “evolving” you mean “changing”, I don’t think that is an issue at all. At most, they add features. They don’t change or remove. And with the editions system, it should be no issue.
If by “evolving” you mean “improving”, then I don’t see how that could ever be an issue.
No.
A stack overflow is a symptom, not the illness. A fork bomb is an illness.
Software coming from the mathematical point of view, assummes it has infinite resources. However, a real computer has many resources that are finite.
CPU time is finite. Memory amount is finite. There is a finite number of network ports. And so on.
A stack overflow just means: “you have run out of this resource called ‘the stack’”. The stack is a region of the memory. Each thread of each process has 1 stack, and it is not infinite in size. This program will cause a stack overflow because it is infinitely recursive, and each function call will consume a bit of the stack.
A forkbomb is not the end of a finite resource. A fork bomb is a program that uses “forking” to rapidly consume system resources. A fork bomb might cause a stack overflow. Or an out of memory issue. Slow the computer a lot. Or if the OS has a hard limit for process amount, it might reach that limit.
I do enjoy cleaning code a lot.
When I work on shitty code I’m always thinking about how shitty it is and thinking on how a different design would make it much easier.
When you clean the code, you’re implementing that perfect design you were thinking of all that time. And you know from that point on you’ll be thinking less about how shitty the code is.
If your only task is to clean code and you’re not gonna work on that codebase afterwards, it’s not as rewarding though.
If it has three letter variables, chances are it was also written by someone that doesn’t want to code either
Ah, just kill half the humans. That will make water consumption go way down. Follow me for more resource-saving tips
Rust doesn’t have “safe” and “unsafe” modes in the sense your comment alludes to.
You can just do the little unsafe thing in a function that guarantees its safety, and then the rest of the code is safe.
For example, using C functions from rust is unsafe, but most of the time a simple wrapper can be made safe.
Example C function:
int arraysum(const int *array, int length) {
int sum = 0;
while (length > 0) {
sum += *array;
array++;
length--;
}
}
In rust, you can call that function safely by just wrapping it with a function that makes sure that length is always the size of array. Such as:
fn rust_arraysum(array: Vec<i32>) -> i32 {
unsafe{ arraysum(array.as_ptr(), array.len() as i32)}
}
Even though unsafe is used, it is perfectly safe to do so. And now we can call rust_arraysum without entering “unsafe mode”
You could do similar wrappers if you want to write your embedded code. Where only a fraction of the code is potentially unsafe.
And even in unsafe blocks, you don’t disable all of the rust checks.
With your definition this conversation doesn’t make sense though. Since rust’s direct array access doesn’t perform bounds checks when building in release mode. And it doesn’t require using unsafe.
As I said, I don’t consider going out of bounds of a buffer a memory safety issue. Forcing the programmer to handle an out-of-bounds case every time there is an array access can be incredibly tedious. So much that not even rust forces you to do so. And if that language has iterators, it’s even less of an issue.
I consider out-of-bounds array access to same as casting a pointer to another type. Just because a language lets you do it, it doesn’t mean that it is not memory safe. It is a performance feature, since checking the bounds every time is always possible (and incredibly easy to implement), but also with too big of an impact when you could just check the length once per loop instead of per loop iteration.
How can you not have memory-safety while also having a garbage collector?
Garbage collection means that all objects live as long as you have a reference to it. Which means that you can only dereference a pointer to invalid memory if you willingly create an invalid pointer, or reinterpret the type of one pointer into another. Going out of bounds of an array counts as the first case.
If a language has garbage collection but no compiler/interpreter supports it, then the language doesn’t have garbage collection.
Null safety and memory safety are different features.
Null safety means that you cannot access a struct’s fields without first checking if the pointer to that struct isn’t null. And this must be a compile-time check.
Memory safety means that you cannot read or write to/from memory that has been free-ed. Without leaks ofc, otherwise it would be very easy.
I kinda disagree. The reason rust caught on is because it is much safer than C++ while having the same or even better performance. And in some contexts, being garbage collected means bad performance.
Before rust you could either have a fast language (C/C++) or a memory safe language (any other language. That is, languages with garbage collector). But if you required memory safety and peak performance, there wasn’t any option.
Yes, the reason that rust is both memory safe and fast is because it has a borrow checker. But the borrow checker is the means, not the end.
If you don’t understand the “problem” part in the “what problem does this tool fix?” Then you probably don’t need that tool. You should probably try the program they mentioned that didn’t fix their specific problem. Since that program probably has way more users and a more entry-level documentation.