mpartel

The power that tech companies accumulate with tactics like this, and the justifications for that power, are strangely reminiscent of autocratic governments: we decide which programs you can develop and run, and we can levy an arbitrary 30% income tax (on top of regular VAT). But don't worry, it's all for your safety and security!

We are fast becoming corporate citizens, for better and for worse: https://www.youtube.com/watch?v=l3pkkSNRug4

While there is some truth to the security argument - security after all is sometimes at odds with freedom - good computer security can certainly be achieved without this degree of centralization of power. Maybe you can't protect a determined user from hurting themselves, but that seems like an acceptable price for freedom.

https://www.oatly.com/int/about-oatly lists other owners as well, but I couldn't find who owns what percentage.

I agree that it helps (though I'm probably more pessimistic about how much it helps). I wanted to counter the assertion that "There's no way it can be banned today, though" (which I should have quoted). Even a disconcertingly non-trivial number of western lawmakers make regular noises about requiring all encryption to be backdoored.

Oppressors can (and I think some already do) subvert HTTPS by mandating installation of government-issued certs so they can do their MITM.

https://puri.sm/products/librem-14/ ?

The experience might vary a lot depending on ping times to their servers, if most interactions require a server round-trip (and if they don't have nice animations to hide the lag).

> Plenty of developers sell through the Epic Store (having development funded by Epic), or GOG, or the Humble store, or on Itch.io, or even via microsoft store.

They do, and that's great, but rarely can they afford to not _also_ sell on Steam. Steam will still take their ~30% cut of the vast majority of revenue, still mostly thanks to its first mover advantage, and there's no self-interest-preserving move the developer has against that.

The only exception are exclusives like Epic's, and exclusives aren't exactly great for consumers either.

This is one of those nasty Prisoner's Dilemma type problems where everyone would probably benefit from a collective action in the long term, but it's hard to agree and coordinate when so many individuals derive (smaller and/or short-term) benefit from the status quo. Most societal problems seem to be of this form.

Even if it weren't the only option, the sad reality is that, for most, it'd be financial suicide to not be on the App Store.

Compare that to games on PC: even though competition has fortunately started to pick up recently, it'd still be madness not to publish on Steam.

All platforms seem to naturally tend towards monopoly, with an enormous first mover advantage. I wish I knew of a solution :/

My main complaints about UNET could be summarized as "the order in which things happen is very chaotic" (in unbelievably many ways!). I've not checked to what degree Mirror has improved on this.

Based on a superficial look, I'm worried it might have been more concerned with adding features than fixing and simplifying the fundamentals, but I don't really know.

Of course you'd still have restrictions on the code if you want it magically optimized, just as with DOTS.

But you're right to be skeptical, this is not something I've thought through that thoroughly :)

> Mind you, I'm a hobbyist in this field so maybe you could chalk it out to inexperience, but I shiver to think to what professional developers have to deal with if the small prototypes I cranked out were that painful.

Careful adherence to best practices (often discovered the hard way), banning certain code pitfalls with a linter, and many workarounds :(

It took me months to make something semi-usable out of (a subset of) UNET, and I can clearly see why nobody at Unity wanted to maintain it. Still, something half-decent and mostly backwards-compatible could have been made of it with enough work, but again they chose to chase the new shiny :/

As a Unity user emphatically sharing these frustrations, I'd be really curious to hear from long-time Unreal devs whether the grass really is greener on the other side.

How's Unreal's

- API stability?

- Editor stability? (I have some old experiences of it being quite crashy too, and you know, C++ ...)

- Backwards compatibility and upgradeability?

The reference source is pretty much useless for anything directly under namespace `UnityEngine`, because it consists mostly of forwards to C++, and the C++ was never released.

At least that was the case around 2018. It might be getting better as Unity is migrating away from C++.

I'm not so sure that would have been impossible. Nothing fundamental seems to prevent the compiler+runtime from:

- laying out instances of the same Component next to each other in memory

- Burst.Compiling their Update() functions

- adding backwards compatible APIs to do parallel loops etc over multiple components

Given the culture of constant rewrites Unity has displayed (and I'm sure they have lots of techdebt to make rewrites feel appealing), its seems far from certain that they explored avenues like this sufficiently.

Or maybe they felt their earlier modification of Mono, which kept them on an old version of .NET for so long, was too painful to even consider touching the runtime ever again.

> I have come to the conclusion that conciseness probably is only an experiential thing. It might not be able to control anything [..]

Doesn't it cause us to at least have these kinds of conversations?

> Doesn't every CPU these days have onboard graphics?

On laptops, pretty much. On Intel desktops, yes, aside from Xeons. On AMD desktops, only some lower end Ryzens have "G" models.

Wine / Steam's Proton does a decent job, and some older games even work better with Wine than with Windows 10.

If you have a spare GPU, a VM with PCI passthrough does an even better job, except for some anti-cheat software that artificially discriminates against this setup.

In theory it ought to be possible to switch a single GPU to/from a VM without a reboot. In practice I have no idea how huge a refactoring to the Linux graphics stack that'd require.

It's always a method in Ruby because you can only access @properties in method implementations.

What you're describing holds in e.g. Scala, where it's by design: they feel it should be an easy-to-change implementation detail whether a name is backed by a direct field access or a method. IMO that's a reasonable stance in a functional(ish) world.

Good point about the memory leaks. Not aiming to contradict it, but I'll mention that https://www.eclipse.org/mat/ is a great help in debugging Java memory leaks. .NET probably has something similar.

I mean, it's no longer horrible I guess :)

With mainstream languages, there's rarely any single clear and/or insurmountable problem, it's all the little annoyances you run into every day that add up, plus the cognitive load imposed by the language directly as well as indirectly through the code it lets you write.

I'm not 100% up to date on how much PHP has closed the gap in the last few years, but subjectively I never found it anything but tedious due missing features, various unnecessary pitfalls (sometimes with security implications), silly limitations (you can write a static type in this case but not in that, you can catch this error but not that, no inner classes, etc etc.), and numerous other small cases of poor "ergonomics".

The "batteries included" nature of the standard library is nice, and in contrast to the somewhat fragmented world of RubyGems or NPM it can feel downright pleasant, but finding a SQL library or such is a pretty small effort in the scope of a project, and (popular) 3rd party libraries tend in my experience to be better than the equivalent standard library stuff in most of the languages I know. Every time I wrote a non-trivial amount of code with PDO, I had to look up the correct initialization rituals to get sane settings and copy or recreate a bunch of more or less "obvious" helpers. I'm sure there's something better in Composer by now.

Fair, though I'd say 1-3 are more or less matched by Java/.NET and probably NodeJS.

Not sure if you meant this, but now that I think about it, the "one process per request" model is actually legit differentiator that obviates a lot of the concurrency trouble new developers can get themselves into with other languages. It makes good performance harder in some cases (though there are workarounds), but overall it's maybe the one thing in PHP that I'd like to see other languages make some note of.

In the past I sort-of agreed and even chose PHP in a few instances when the project was tiny enough that ease of deployment was a major factor.

Nowadays with something like Heroku or App Engine, language has almost no impact on ease of deployment, and even custom deployments are pretty easy once you've practiced the docker/systemd script + apache/nginx proxy dance once or twice.

Having followed and at times heavily used PHP since the 4.x times, its story seems to be that of slowly (and begrudginly?) accepting modern language features like classes, exceptions, lambdas, GC, static typing, etc., sometimes getting things wrong on the first try but still mostly converging towards modernness.

That begs the question, what's PHP's value proposition for new projects? If PHP mostly chases feature parity with Java/.NET/TypeScript and doesn't attempt to do anything better/different (like Elm/Haskell/Rust/Go/Erlang arguably do), then why choose it?

That is good advice that is unfortunately not widely followed in most of the apps I've seen. There's also the caveat that you should be prepared to retry transactions, but for small apps it's probably fine if you don't.

True, though even a single user triggering two actions quickly can cause issues if unlucky.

Sure, as long as the developer knows what they don't know. Race conditions usually don't fall into that category (and neither do potential UX improvements actually).

WebAssembly has some hope of changing how browsers are programmed, but you're probably right that JS will live on for many human generations as a legacy tech at least.

It can seem that way, but the consequence of not knowing them is lots of subtle race conditions. Granted, most webapps probably don't have enough users to trigger them too often, and the impact is often limited e.g. because the kinds of inconsistencies you can introduce don't actually matter that much in many cases.

For the majority of webapps, I'm not sure the default isolation level of MySQL and Postgres is an appropriate tradeoff, since I'd rather have correctness by default than performance by default.

Application-level checks are prone to race conditions, especially at the default transaction isolation levels of many popular SQL databases.

For example: transaction X deletes a parent row and its child rows while a concurrent transaction Y inserts a new child node. Without a FK, this can leave an orphaned child row.

For similar reasons, SELECT before INSERT is generally not a safe replacement for a UNIQUE constraint.

You don't even need that high a user volume to see these errors in practice.

It's a shame that ORMs don't tend to encourage the use of database-level constraints, but even if I just want to build something quickly in e.g. Rails, I still add the constraints as an extra check because I'd rather get the occasional 500 than an inconsistent database.