Isn't this over engineered? Why not allow the assignment but do nothing if any of the intermediate objects is null (that's how Kotlin does it).

We see:

    pub fn implBy

    (impl_obj: anytype) 

    v_setLevel

    anyopaque

Which god should I believe in, though? There are so many.

And what if I pick the wrong god?

It basically allows you to pipe successive function calls returning different types by lifting these types into a monad.

Don't get me wrong, that promise is very powerful and in the rare few cases where it works, it unlocks beautiful composition, but the simple truth is that monads are really not that useful outside of Haskell (and I'd say, it's even questionable within).

How useful, really? Monads don't even universally compose, which is what most people sell the concept for.

Apps can expose endpoints that can be listed, and external processes can call these endpoints.

It basically powers all inter communication in Windows.

There is plenty of evidence that OOP provides some flexible, extensible, and intuitive ways to design GUI libraries.

I have personal experience that OOP can be the better approach in other fields too (such as overriding a specific method of a larger structure).

> Being in denial about this isn't an excuse for these problems.

I'm not in denial, I know exactly what Denuvo entails. Whenever I buy a game with Denuvo (which pretty much never happens any more), I know exactly what I'm giving away, and I'm doing so because I'm getting something in return.

Similar situation to someone dropping their business card in a jar at the exit of a restaurant with the hope they'll win a free meal. They give a bit of personal information because they think they'll receive more in return.

You don't get to take away the choice of customers to decide how to manage their information.

As long as everyone is free to make that choice, nobody is getting hurt and the market forces will ultimately land on an equilibrium, like we have today.

I never made that claim, please reread what I wrote, but here is my point again.

When you play a game from a publisher, they were able to create it because their previous games sold well. Therefore, anything that allows games to sell well is a positive for the entire gaming community, creators and players.

Denuvo is an important part of this picture, but it's obviously not the only one.

> And then there are people like me who simply refuse to play any game which uses Denuvo. There are thousands of excellent games out there, why should I waste time on those which treat me as a thief?

That's great, and I do that as well. And this is one of the reasons why Denuvo is not anti-user: everyone has the choice to not support it.

If I willingly let them in my home and I knew they were going to do that? I don't really have the option to complain, do I?

Your analogy doesn't make sense. People buy the game, Denuvo is clearly advertised on it. They have the option to not buy the game. Period. It's not overreach if I willingly accepted the reach.

> So to sum it up, DRM is always anti user in many senses.

How do you reconcile this claim with the fact that Denuvo games sell by the millions every month?

Describing it as "anti user" is theoretically correct but practically incorrect. It's true that it might prevent mods and possible future uses if the servers go down, but in practice, users don't care, as is demonstrated by the fact that games that contain Denuvo routinely sell in the millions and users have no idea it's even there, and they will never know.

Overreaching?

I don't know. Companies put out a product, you're free not to buy it if you don't like it. That's one of the reasons why I call this natural market forces.

> So conceptually it's not any better than what fourth amendment is aimed to prevent.

That's a gross exaggeration. The Fourth amendment is about unreasonable searches by the government, I completely fail to see how willingly buying a digital product from non governmental organizations is connected to Fourth amendment in any rational way.

Again, at the end of the day, nobody forces you to buy that product, hence "natural market forces".

The fact that millions of these games are being bought every month tells me users don't feel that whatever flaws, perceived or real, Denuvo has matters less to them than playing these games.

That's an extremely naive take that shows some stark ignorance of the tech and market forces at work.

From a tech standpoint, Denuvo negatively impacting performance has been debunked many times over (see my previous post about that).

On the economical side, you need to realize that whenever you are playing and enjoying a game, it's most likely due to the fact that the previous games sold by that developer have been successful in making money, which was most likely made possible by Denuvo.

In other words, making piracy harder allows the next generation of games to be created.

There is pretty much zero evidence that this is true and some credible evidence that it is untrue.

For example, plenty of games have had Denuvo removed after a few months by the publisher and showed zero improvement in performance.

This fake narrative is being pushed by software pirates bitter that Denuvo is being so effective at preventing them from stealing games.

And this is exactly where Go fails, because it allows you to completely ignore the error, which will lead to a crash.

I'm a bit baffled that you correctly identified that this is a requirement to produce robust software and yet, you like Go's error handling approach...

Kotlin is not a dynamic language, it's statically typed, just like Java.

Anyone else finding some irony in the fact that the provided code is unreadable not because of its structure but because of the highlight colors?