Welcome to the Lounge

Quote:

Consider WindowNative, InitializeWithWindow
See https://aka.ms/cswinrt/interop#windows-sdk'

var filePicker = new FileOpenPicker();
filePicker.FileTypeFilter.Add("*");
InitializeWithWindow.Initialize(filePicker, WindowNative.GetWindowHandle(this));
await filePicker.PickSingleFileAsync();

Quote:

A man of ordinary strength exerts a force of 30 lbs. for 10 hours a day, with a velocity of 2.5 feet in a second == 4,500 lbs raised 1 foot in a minute == 1/5 the work of a horse.

• Concepts like the "borrow checker" from Rust and "nullability checker" from C# will be expanded to cover other constraints that are frequently broken by accident. "Such as what" - well who knows. Maybe we'll see refinement types being embraced, maybe linear types, maybe it will come in the form of compile-time verified asserts, or maybe we'll just continue down the path of inventing a Special Case to address each individual thing.. Whether you like these things of not, they are the trend. Don't start with "but Rice's theorem", it is well known that static analysis cannot be perfect, it doesn't have to be, it only needs to be useful.
• With more and more of the performance of modern processors being locked away behind SIMD and multi-threading, we will see the adoption of paradigms that natively handle one or both of them, for example basically writing compute shaders for the CPU. Intel ISPC is something in that direction and there will be more, because the hardware demands it. Not only x86 hardware, by the way. Even if the future holds a lot of ARM and RISCV, there will be a need to target ARM SVE and whatever RISCV calls their vector instruction set, and the (probably) dozens of small cores. Auto-vectorization doesn't really address the problem, it can only do so much when the source is written in the wrong paradigm to begin with, it can't change your inherently-serial algorithms.
• The "easy learning curve" because "everyone is going to be a programmer in the future" (from the article) is, IMO, the wrong way to look at it. I expect that lots of non-programmers will be writing some code, but they won't be interested in becoming programmers, and they won't be using general purpose programming languages. They will probably be using some expensive-but-buzzword-infested-and-horrible "business automation" packages (inflicted upon them by their boss) and their made-up proprietary languages. I feel a bit sorry for them already. It will be an extra thing that we're going to see more of, but it won't affect future languages in general, only the ones that are in that niche.