There are use cases. Like containers where the pointer to the object itself is the key (for example a set). But they are niche and should be implemented by the standard library anyway. One of the things I hate most about Java is .equals() on strings. 99.999% of times you compare strings, you want to compare the contents, yet there is a reserved operator to do the wrong comparison.

Yes that is correct. A BigInt represents the entire integer set.

Rational numbers are defined by just 2 integers. Therefore, 2 BigInts represent the entire rational set.

I haven’t tried using a GUI library for this. But it is possible (and relatively easy) to build for Android using rust.

I found this tool called “x build” that works basically out of the box. It was a bit tricky to set up the release build, but got it working too.

I made a small App using winit+wgpu and it seems to work. Win it also has touchscreen-specific events.

Iced does use winit+wgpu, so if they are listening to the touchscreen events, it should work for Android. Haven’t tested it though.

Yes. Have a structure with 2 BigInts. Treat one as the numerator. The other as denominators.

It might not be efficient or fast. But it is possible.

In C, goto is basically a necessity though. There is really no good way of error handling.

Options:

1. Using goto

void func(void *var) {
    void * var2 = malloc();
    if var == Null {
        goto err;
    }

    do_something();

err:
    free(var2);
}

2. Early returns:

void func(void *var) {
    void * var2 = malloc();
    if var == Null {
        free(var2);
        return;
    }

    do_something();

    free(var2);
}

3. Skipping with conditionals:

void func(void *var) {
    bool error = false;
    void * var2 = malloc();
    if var == Null {
        error = true;
    }

    if !error {
        do_domething()
    }

    free(var2);
}

4. Early return + cleanup function.

void cleanup(void *var2) {
    free(var2);
}

void func(void *var) {
    void * var2 = malloc();
    if var == Null {
        cleanup(var2);
        return;
    }

    cleanup(var2);
}

Option 1 is really the only reasonable option for large enough codebases.

Option 2 is bad because duplicate code means you might change the cleanup in one code path but not some other. Also duplicate code takes up too much valuable screen space.

Option 3 has a runtime cost. It has double the amount of conditionals per error point. It also adds one level of indentation per error point.

Option 4 is same as option 2 but you edit all error paths in one single place. However, this comes at the cost of having to write 2 functions instead of 1 for every function that can error. And you can still mess up and return while forgetting to call the cleanup function.

You must also consider that erroring functions are contagious, just like async ones. I’d say most of the time a function is propagated upwards, with very few being handled just as it ocurrs. This means that whichever downside your option has, you’ll have to deal with it in the whole call stack.

Show one use case of Blockchain outside cryptocurrency. It must also be a better solution than a traditional database.

If there’s literally a bike lane along the road, there’s no reason to use the road on a bike unless you’re an asshole.

I do pay the water company, which doesn’t give me the right to throw wet wipes down the toilet.

I do pay a waste management tax. That doesn’t give me the right to throw dogshit in the paper container.

We all pay to build bike lanes. Since people using bike lanes helps both cyclists and drivers. Just use the damn bike lane if there is one.

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.

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.

When I want to draw raw polygons, I use wgpu. When I want a GUI I used iced. And when I want both, I use wgpu+imgui.

Learning wgpu is quite steep, and it has tons of boilerplate. So unless you’re certain that you will use it a lot. I would just use iced.

When I say wgpu I mean wgpu+winit. Though winit is quite simple and light. So the main part is wgpu.

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.

Well, the closure has a type. Just you cannot declare it. That’s why you do “impl Fn” instead. Because you know that whatever type the close is, it implements the “Fn” trait.