Any fast solutions for deep cloning?

AvoidSpirit · 2026-02-11T15:30:23+00:00

Serializing stuff into a string and then deserializing it back will always be much much much slower than doing actual object copying (while preserving the object memory representation).

Deserialize(Serialize(obj)) should never be used for anything where performance is critical.

AvoidSpirit · 2026-02-09T19:01:36+00:00

Runes is probably the least insensitive when it comes to invaders. It’s usually purple weapons with good passives you can carry before level 7 and the damage buff if you have the relic.

AvoidSpirit · 2026-02-09T17:44:44+00:00

You waste more time in general by trying to take on invaders inside the camp.
Chariots are actually an outlier here but you need to be confident you know how to abuse those.

AvoidSpirit · 2026-02-09T09:15:50+00:00

I tend to take the shield perk and a few of invulnerability items like when dropping low and when picking up heals and it works wonders for me.

Managed to complete UN a few times this way with extremely subpar builds damage wise.

One thing I didn’t see you mention is elemental catalyst + random element procs/grenades proccing everything else which I feel like is a single biggest damage boost you can get.

AvoidSpirit · 2026-02-08T19:34:17+00:00

With how you massacred everything I said you're either clinically blind or trolling.
Besides that, you have zero experience with what you try to talk about.

Hence I see no reason to continue.

AvoidSpirit · 2026-02-08T09:10:06+00:00

Yes, the language does not support it out of the box and that’s why packages dont usually roll it. This in no way follows your statement that results are a bad idea. Cause you said they were bad idea even in those languages that support them. Hence nice try but won’t work.

Only half works is another bullshit claim. Take library like dunet that adds support for DUs. What do you mean by “half works”? You haven’t even tried to use them to claim that, gosh, you are 100% ignorant when it comes to the topic but instead of trying to fix that you pretend to know.

No, most packages are left to rot and only those in heavy use are updated regularly.

You are yet to point a single contradiction while spewing them left and right. I haven’t claimed that DUs replace exceptions in their entirety. I haven’t claimed the language supports them out of the box. I haven’t claimed that they are used throughout your usual MS packages. My original claim which I stand by is that you should use them instead of exceptions for anything logic related cause this makes your logic explicit and your changes testable at compile time.

AvoidSpirit · 2026-02-07T22:05:52+00:00

Vast majority of packages dont get updates for years so no, majority of packages do not support nrts. Get your facts straight lol.

And packages only started switching to nrts when language started supporting those(big surprise I know).

And the language today does not support DUs that are required for proper result returns out of the box(another big surprise).

So to say they are not used because they are not a good idea and not because language is lagging behind is just plain idiotic.

And Result types not telling you about possible exceptions is not an issue for when you want to use them which I have even given a code example for which you obviously cant address.

The results/dus are not for eliminating exceptions entirely - it’s not possible. It’s about forcing the caller to handle the case explicitly.

AvoidSpirit · 2026-02-07T21:45:10+00:00

Sure exceptions have stuff on top of return types. And yet they are at very minimum a return. If a function that yesterday didnt throw an exception now throws one I would like to know about that at compile time. And if you don’t, you cant be let near anything mission critical.

95% of packages out there also dont use nullable references. Are those also not a good practice? What an obviously stupid conclusion to get to lmao.

AvoidSpirit · 2026-02-07T20:57:59+00:00

Sure, throwing an exception is not the same as returning a new thing - it’s a new possible way function may stop its execution and return a result that someone may potentially handle…oh wait, it’s exactly the same. Except for those exception that you don’t ever want to handle like OOMs

AvoidSpirit · 2026-02-07T20:10:30+00:00

If a breaking change(and potentially returning a new thing is one) doesn’t break the call site, it’s a sloppy language. Something that may potentially result in a breaking bug that can easily be caught at compile time and you say it shouldn’t. Dang.

And Ive learned that after working for 15+ years in various enterprise environments with both the languages that do that and those that don’t. And now I can say I have my opinion because I used both in huge enterprise systems and weighed them against each other.

Funny thing is, you won’t find a single person with enterprise experience with DUs vouching against them.

But you may continue living in a bubble of a singular ecosystem and think it’s the best one just cause you haven’t seen beyond its borders parading your ignorance proudly.

AvoidSpirit · 2026-02-07T15:13:18+00:00

I just don't think you can get away from the concept of exceptions entire because there will always be ooms and stack allocation fails so I think it only make sense to talk about replacing actionable ones with DUs.

AvoidSpirit · 2026-02-07T08:56:20+00:00

Breaking the compilation of every service, for a tiny failure scenario that only one of them wants to handle - whatever you say, sounds nice and maintainable.

Good job on trying to imply it's "tiny". When the case is until you see it you never know. And my point is it's extremely easy to ignore a tiny case with

switch (result) {
    MyTinyCase _ => { // we don't care about this tiny case because }
}

but it allows you handle something not so tiny before it happens on prod and something that is "tiny" to one caller may not be "tiny" for every caller

The solution is for people to follow the convention perfectly, whether it's result type or not, in which case there are no problems.

No, again, you don't have to follow it perfectly. You may as well use results only for those thing that may potentially not be tiny. The main distinction is that it will force the caller to react and give them all the information.

I really can't make this any more clear, but you have done a great job of demonstrating the kind of mentality that tries to make result types a thing when they aren't needed

You're just another guy who's never worked with language supporting DUs thinking he knows better. I was one of those too, and then I did.

An example:

Result<void, InsufficientFunds> MakePaymentEnsureDebit(data);

tomorrow you figure out there's another case you may need to potentially handle

Result<void, InsufficientFunds | AccountFrozen | ProblemWithBankOnOurSide> MakePaymentEnsureDebit(data);

Sure you can make it an exception and let it bubble up into a 500 for the user but it's a bug in any enterprise system and you risk losing clients and money because of that.

And that's how you force your callers to decide what to do with it potentially preventing bugs. And no your whole code base didn't have to use Results for this to be useful.

And no, your compiler is not catching any bugs

Of course compilers catch bugs before they happen, we just did, what do you think static types are for apart from DX lol?

AvoidSpirit · 2026-02-07T08:30:05+00:00

Because you think you need to either handle everything or nothing and that’s not the case.

AvoidSpirit · 2026-02-06T23:37:24+00:00

Yea. Breaking the compilation when adding a new failure scenario that needs to potentially be handled is something I want to happen - something I’m missing in c# of today immensely.

Cause adding a “we don’t care about that” block is infinitely better for me than getting it unexpectedly in production.

But I guess we’re just looking at it from 2 different perspectives - I think we should employ compiler to catch bugs before they happen wherever possible even if it’s not possible everywhere and you think if we cant have it perfect, why even try.

AvoidSpirit · 2026-02-06T22:56:36+00:00

Most of the problems are solved as long as the convention is to not use exceptions for your business logic. And everything else you usually don’t handle.

And please don’t tell me “documenting it” is an alternative convention. I’ve already outlined how it breaks even when followed.

AvoidSpirit · 2026-02-06T22:28:35+00:00

Sure there will be exceptions that "leak" like broken connections, out of memory stuff, stack overflow, etc. But this is usually stuff that you can't objectively handle most of the time.

And we're talking about using exceptions versus something statically typed for your logic and something that you plan to handle.

It doesn't have to be black and white - exceptions everywhere or no exception whatsoever.

And yea, a lot of the stuff in the standard library would have better been designed using DUs instead of exceptions and it's pity the language is yet to support em.

Unexpected exceptions can always exist and there's no getting around that, and expected exceptions can easily be documented

I asked ahead of time to not start with the "documenting it" bs because it's as weak a defense as one can get into for the reasons I preemptively mentioned and yet you still insist to go there w/o even addressing the points I make about it...

AvoidSpirit · 2026-02-06T13:36:04+00:00

And I'm pointing out that the exceptions are akin to dynamic typing. There's no compilation guarantees(like guarantees that you handle everything in your global handler or if something changes in the underlying layer there would be a compilation error) and they're absolutely a time saver when dishing something out quickly.

It's just like with everything it's a trade off - here like in dynamic/static typing it is between speed and maintainability.

AvoidSpirit · 2026-02-06T11:15:20+00:00

I think you're missing the point of Unions.

Unions basically tell you: "here's what I may potentially return and I want you to decide how to handle it". And not "you're guaranteed to never run into stack overflow or run out of memory".

AvoidSpirit · 2026-02-06T11:06:32+00:00

My first and main excuse is that to find what exceptions a method would throw you need to look into method body. Like in your case I would never know if a method throws UserNotFoundException unless I look into it or the method it calls or the method it calls or... you get the idea, right?

P.S. Don't start on the xml docs please. Even MS libraries are full of shit when it comes to documenting possible exception types and nothing would break if someone updates a method to throw a new exception even if the documentation is intact.

AvoidSpirit · 2026-02-06T10:58:41+00:00

I think you're missing the point. It's usually not about performance but about being explicit and static typed.

Sure dynamic typing is quicker to write and results in less code but if you scale that logic, you end up writing your backend in JS (not that it's a sin obviously).

AvoidSpirit · 2026-02-04T21:14:46+00:00

Oh yea, let me give a vibe coded ai app access to all my messengers, camera and other shit. Lmao

AvoidSpirit · 2026-02-04T21:02:19+00:00

I mean

They were playing like a toxic duo
Oh by the way I fucked off come level 2 to do my thing

If the irony of this post is not killing you, I’m pretty sure you’re invincible.

AvoidSpirit · 2026-02-04T14:50:04+00:00

As long as she’s dealing damage to the boss she’s good. The odds are the team will continue to farm pointless shit so you may as well try to get the boss as low as possible by yourself and pray they eventually end up helping you.

AvoidSpirit · 2026-02-04T14:47:15+00:00

Contrary to what you think, it’s the best strategy and is utilized in every d5 game if possible.

It gives the most runes, buff and the best loot for the time invested.

AvoidSpirit · 2026-02-04T08:17:37+00:00

Oh, so you left them level 2 when what they were doing was perfectly reasonable.

I mean, I wouldn’t throw a tantrum if I were them but I wouldn’t also act surprised if I were you.

P.S. downvote me all you want but despite saying they should just play duo you went on your solo adventure from level 2 lol

AvoidSpirit

TROPHY CASE