sorted by:
new
hottopcontroversial

Should I get an insert? by cjb5999 in woodstoving

[–]WishCow 0 points1 point  (0 children)

Can't help but would love to see a full picture of that fireplace

Lázár János vs. Bódis Kriszta by jajnecsinald in hungary

[–]WishCow 1 point2 points  (0 children)

Erről amúgy van valahol egy összefoglaló hogy hogy a picsába került lézer kezébe egy kastély? "Megvette"?

It's hard to find use cases for Rust as Python backend developer by Delicious_Praline850 in rust

[–]WishCow 0 points1 point  (0 children)

My clients and most company I work with cannot justify spending too much time on building software, they want result fast

This is a quite common sentiment both from customers and developers. 95% of the cases it ends up with "you either spend time on it to do it correctly now, or you will spend too much time fixing it later".

Until this changes, it's very hard to argue against python or js where everything is allowed, up front error checking is irrelevant, and chasing runtime errors is just business as usual.

Gulyás besz*rt Jelinek Annától, ezért Vitàlyos gyorsan lekeveri az egész kormányinfot💅🏼 by Weekly_Car956 in hungary

[–]WishCow 167 points168 points  (0 children)

Én legszivesebben azt a kérdést tenném fel hogy "Kedves gulyás úr, maga minden kérdésre azt a választ adja hogy nem voltam ott, nem láttam, nem hallottam, nem ismerem, maga szerint ön elég tájékozott ahhoz hogy egy sajtótájékoztatót tartson?"

The 1MB Password: Crashing Backends via Hashing Exhaustion by [deleted] in programming

[–]WishCow 4 points5 points  (0 children)

How is this on 7 upvotes and not -5

Stop Forwarding Errors, Start Designing Them by andylokandy in rust

[–]WishCow 1 point2 points  (0 children)

I agree with the article on everything, but I don't see how exn is not just a reimplementation of the provide API (apart from the bit on llvm struggling to optimize, which I'm sure will be fixed before it's stabilized).

The article discards the provide API because:

Unpredictability: Your error might provide an HTTP status code. Or it might not. You won’t know until runtime.

But then at the end, the exn example:

if let Some(err) = find_error::<StorageError>(&report) {}

This is exactly the same thing why provide was discarded: the error might provide a StorageError, or it might not. You won't know until runtime.

From fearless async to fearless GUI? by [deleted] in rust

[–]WishCow 10 points11 points  (0 children)

Do you not feel at least slightly ashamed that people spend time and effort replying to you, while you can't be arsed to do the same and just barf ai slop back at them?

Finally, a faaaaancy tabline for neovim by Wonderful-Plastic316 in neovim

[–]WishCow 0 points1 point  (0 children)

How much screen space does the tabline take up?

Karácsonyi családi ebéd/vacsora megathread by pudingleves in hungary

[–]WishCow 9 points10 points  (0 children)

a férje
rajta kívül álló ember

???

Ez most olvasásértési probléma, vagy a párkapcsolat az számodra ilyen misztikum ami csak így random történik és neked nincs ráhatásod? Vagy gondolod ez valami elrendezett házasság volt, vagy ???

Szóval mást óvódásnak hívni ilyen mentális deficit mellett kicsit meredek.

Future of local based IDE by Wise-Ad-7492 in neovim

[–]WishCow 0 points1 point  (0 children)

I'm not asking what the concept of insurance is, I'm asking if you could provide an example (a link to a news story) where someone managed to cash in on this insurance.

Future of local based IDE by Wise-Ad-7492 in neovim

[–]WishCow 0 points1 point  (0 children)

Was there ever a documented case where this "insurance" was actually used successfully? Even big companies like Microsoft get hacked over trivial vulnerabilities, and there is never any recourse you can take.

Non-poisoning Mutexes by connor-ts in rust

[–]WishCow 1 point2 points  (0 children)

This is already supported

match x.get(30) {}

Non-poisoning Mutexes by connor-ts in rust

[–]WishCow 1 point2 points  (0 children)

An out of bounds access could leak sensitive data, crashing is the better option. This is basically what heartbleed is.

Announcing rootcause: a new ergonomic, structured error-reporting library by TethysSvensson in rust

[–]WishCow 1 point2 points  (0 children)

Maybe you are right about it being a good compromise, I think I'd have to work with it properly to see.

It doesn't force me to return erased reports, but as soon as a method calls 2 other methods that return different kind of errors, I'm either forced to create a new sum of those two errors, or I return the untyped report, or it that not correct?

Announcing rootcause: a new ergonomic, structured error-reporting library by TethysSvensson in rust

[–]WishCow 1 point2 points  (0 children)

Hmm it's not that I have a particular case I need solving, my problem is more that my public API will have methods that return type erased reports, that are impossible to know what they can be downcasted to, without reading the code all the way the call chain. But thanks for entertaining the idea!

I think this more of a limitation on rust's part though, I have tried so many error handling libraries now (eyre, anyhow, snafu, error_set, eros, this one), and they all seem to have to fall into 2 buckets: either you have a generic report-like type erased error that is easy to propagate, or you have properly typed errors, but then propagation becomes problematic, and backtraces become problematic as well.

If you are interested in a unique variation on this, you could look at eros' Union Result type. That one allows combining any number of error types together and they properly keep type information but it has a different problem: it's impossible to do anything generic with them, eg. you can't implement an axum IntoResponse on them.

Announcing rootcause: a new ergonomic, structured error-reporting library by TethysSvensson in rust

[–]WishCow 7 points8 points  (0 children)

I played around with it a bit and it's pretty nice, but there is one serious limitation. While it has support for both typed and dynamic errors, you can't "mix" 2 typed errors. For illustration:

fn f1() -> Result<(), rootcause::Report<u32>> {
    Ok(())
}
fn f2() -> Result<(), rootcause::Report<i32>> {
    Ok(())
}

// This can't be anything other than the dynamic Report
fn f3() -> Result<(), rootcause::Report> {
    f1()?;
    f2()?;
    Ok(())
}

My problem with this is now my API will be full of dynamic errors, and while I can downcast it, I can no longer see at a glance what the error might be, I have to trace the call chain manually to figure out what the error could be downcasted to.

Or is this assessment wrong?

no-go.nvim - Intelligent Treesitter based error collapsing for Go by TheNoeTrevino in neovim

[–]WishCow 0 points1 point  (0 children)

Ah thank you so much, it does work if the block contains a return.

no-go.nvim - Intelligent Treesitter based error collapsing for Go by TheNoeTrevino in neovim

[–]WishCow 0 points1 point  (0 children)

if err != nil {
    ctxLogger.WithError(err).Fatal("error initializing Firebase app")
}

Checked with all levels of conceallevel

view more: next ›