pjmlp

Yes, it was also where C++26 static reflection was prototyped, as another example of its influence.

One of EDG developers prototyped his idea, and brought it to WG21 when it seemed reflection as originally thought for C++17 was never happening.

Some coders, those that equate being a developer with UNIX, mostly.

They pay tons of money for hardware, only to use it the same way I was using those DG/UX terminals at the university.

Naturally there are no coders in other operating systems as well.

There are dozens of us. :)

To be more pedantic that was taken from Motif layout managers, and old school VB did have layout managers available, however a large majority only dragged and dropped from the toolbox.

But that is the thing, you don't have access to all the NuGet libraries, or even CLR/MSIL abilities, it is a hit and miss depending on what platforms are being targeted.

Sure if you only want to target desktop/laptop computers, you're safe.

Cloud products based orchestrations with proper security mechanisms configured, don't have shell access and should only communicate over proper network mechanisms.

Rootless immutable containers without shell access, or SaaS products from multiple vendors with WebAPIs as the only touch point.

Besides the sibling comment, you can used closed hash tables algorithm (open addressing), which is fully based on a single array.

https://en.wikipedia.org/wiki/Open_addressing

Why? The only thing missing is the proper data structures and algorithms background.

Which during my degree, the lab deliverables were 100% C code.

Here, one possible book:

Data Structures, Algorithms, and Software Principles in C (1994 edition)

https://www.amazon.com/dp/0201591189

Back in the ActiveX days, ActiveState had IE scripting engines for Tcl, Perl and Python, allowing their use on IE instead of VBScript and JScript.

Well, it is nice, but not really solving any of the Firefox real problems.

Because it is much easier to have a custom language, than try to subsetting an existing mainstream language, while having to deal with all the mess of people trying to use random stuff on the engine, that naturally isn't supported.

Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.

Besides the sibling comment, VB.NET is still around, even if not with the attention it once had.

VB + C# with Windows Forms is not much different from old school VB.

And for the pixel positioning complaints, it is about time people learn about FlowLayoutPanel and TableLayoutPanel, they exist since .NET 2.0 (2005).

Not to sidetrack that much, COBOL is now in ISO 2023, even has OOP features, there are ways to do microservices in it, and nice modern IDEs as well.

Additionally maybe we should stop complaining about its verbosity, given the amount of English based programming going on nowadays.

XBox no longer uses UWP (ERA runtime), that is left around for compatibility mode, nowadays modern XBox development is classical Win32.

One of the reasons C++/CX was killed was because of this, even though UWP application developers were fine with it, apparently game devs were quite vocal against it, even though they love their compiler extensions in other platforms.

XBox is PC as well, at least in what relates Windows being owned by Microsoft, and the of studios that are still owned by them.

Steam Machine also has the issue that they don't have any significant number of native games, they are dependent on Windows gaming ecosystem as source.

The console you mean, Microsoft even with all the layoffs is one of the biggest publishers and studios owner around.

You forget that XBox is also the umbrella brand for Microsoft Game Studios, for Microsoft PC is also XBox, although the whole marketing around it is a mess.

One has to be naive not to understand that the whole cloud computing model is nothing else than being back at the timesharing days.

The big difference is the hardware evolution, now the rooms are full of server racks with sliding pizza boxes, and the terminals are prettier.

GeForce Now is doing much better.

Stadia had other issues beyond fast Internet, like asking a community focused on Windows/DirectX to add support for the Stadia/Vulkan stack.

At the last Stadia developers conference, a few months before it was killed, one of the talks was about doing something like Proton for Stadia.

EDIT: Here is the talk,

"How to write a Windows emulator from scratch"

https://www.youtube.com/watch?v=8-N7wDCRohg

I know the process, the question was how far .NET tooling support is there, because if they just rewrite everything into C++, there isn't much there to talk about.

When Rails came out, I was like what is the buzz all about, we have been doing this already for several years.

This is certainly where the expectation to pay premium doesn't match the actual product.

Ah, the memories.

The startup I joined in 1999 had its own application server loosely based on AOLServer architecture.

We had Apache + mod_tcl, IIS with our own ISAPI extension, then in box connections for all major RDMS across all key UNIXes and Windows NT/2000.

Some left to join companies doing Vignette projects, others eventually created OutSystems redoing the same ideas, but with the newly released .NET.

However it was also a lesson in performance issues, and the constant pressure to rewrite Tcl code into C extensions.

Devil May Cry on PlayStation 5 uses .NET, as do many other games from Capcom.

They have their own in-house fork of modern .NET, integrated into RE:Engine.

Also Unreal C++ has a GC, exactly to have easy interoperability between engine code and C++ components exposed to Blueprints.

Lots of people complain, yet nothing else has won over in GUI development tooling.

And even that doesn't add consoles support, is W4 that far?

Historical note that Arena Wars, released in the .NET 1.0 days, with thin bindings to OpenGL, was the very first .NET game, years before XNA.

https://en.wikipedia.org/wiki/Arena_Wars

C# being closer to C++, and .NET having direct support for C++ helped quite a bit regarding adoption among game studios.

Unity started on Mac, and they only adopted .NET when doing the cross platform rewrite.

I also don't remember if there wasn't some Mono advocacy at the time, as they became customers in the process.

Ironically Mono/Xamarin is almost gone from official .NET, all these years after the acquisition, with every modern .NET release, another bit falls off.

We are already on the phase that CoreCLR might take the remaining bits.

Which probably would have been a priority 1 ticket instead in the Steve Balmer Microsoft days.

There is more to it than just a CPU ISA.