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.

• Early return propagating the error
• Early return ignoring the error (maybe by returning a default value)
• Explicit handling by if-else (or match) to distinguish between error and not error cases.
• Early return and turn the error into another type that is easier to handle by the caller.
• Assume there is no error, and just panic if there is. (.unwrap)

There are only 2 error handling methods that you cannot do:

• Exceptions
• Ignore the error and continue execution

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.

I’ve got all that. I just needed to convert a string of characters into a list of glyph IDs.

For context, I’m doing a code editor.

I don’t use harfbuzz for shaping or whatever, since I planned on rendering single lines of mono spaced text. I can do everything except string->glyphs conversion.

Just trying to implement basic features such as ligatures is incredibly hard, since there’s almost no documentation. Therefore you can’t make assumptions that are necessary to take shortcuts and make optimizations. I don’t know if harfbuzz uses a source of documentation that I haven’t been able to find, or maybe they are just way smarter than me, or if fonts are made in a way that they work with harfbuzz instead of the other way around.

As someone trying to have as little dependencies as possible, it is a struggle. But at the same time, harfbuzz saved me soo much time.

EDIT: I don’t do my own glyph rasterization, but that’s because I haven’t gotten to it yet, so I do use a library. I don’t know if it’s going to be harder than string->glyphs, but I doubt so.

I cannot comprehend what the fuck harfbuzz does.

I tried to implement my own because “I don’t need all the features, I’m gonna render self-to-right western text with very few font features”. But holly fuck, the font format documentation is barely non-existent. And when I tried my naive solution it was like 10000x (or more) slower than harfbuzz.

This is the dram. Since the entire codebase is shit, you basically have to rewrite it basically in its entirety.

Which means you can do it with an actual good design.

And if you mess up on something, you have a working version you can consult.

The same argument for cartels. “We didn’t all increase our prices to the exact same amount, we just paid a consulting company to tell us which price we should use. Of course our competitors used the exact same company, but that’s just a coincidence”.

Tbf that leads to the problem of:

Company/Individual makes program that is in no way meant for making management decision.

Someone else comes and deploys that program to make management decisions.

The ones that made that program couldn’t stop the ones that deployed it from deploying it.

Even if the maker aimed to make a decision-making program, and marketed it as so. Whoever deployed it is ultimately the responsible for it. As long as the maker doesn’t fake tests or certifications of course, I’m sure that would violate many laws.

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.

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.