The Vala Language (2017)
bassi.io
bassi.io
Which brings on an interesting historical tangent - back in the day, Windows applications were written against the COM object model, either in pure C, or C++ with MFC. The parallels are obvious - Microsoft needed a language that was easier to use and better suited for the needs for applications programmers.
The obvious thing would've been to build something like Vala - a COM based reference counted compiled language - but they decided to build .NET/C# a garbage-collected JITted language with an entirely alien library and execution model. And while it became somewhat a success in the world of generic software dev, it never fulfilled this niche, with none of the core MS products ever integrating it, and most of the internal teams treating it with animosity.
I wonder why Microsoft decided to go down this route.
I have yet to meet a C# dev who actually touched J++ or J# to be honest.
The reason for this is the up-to-date Mono (that keeps up on runtime features and library support) lives here: https://github.com/dotnet/runtime/tree/main/src/mono After .NET became what it is today, many Mono components simply became part of the codebase there. Most notably Mono linker which became ILLink, a critical component of assembly trimming and AOT compilation to native binaries.
However, Mono is significantly slower than CoreCLR, frequently does not have the optimizations that performance-oriented code paths expect, only supports 128b SIMD and now serves the purpose of supporting exotic targets like WASM, monoaot for iOS (it will be eventually superseded), ARMv6 or just new platforms in the process of bring-up.
In any case, if you still plan to use Mono, it is best to use the one from dotnet/runtime.
Alternatively, you can build dynamically linked libraries with NativeAOT (it literally gives you plain .so files) and use that for extensibility instead. Note that they do not support unloading and live throughout the duration of the process.
https://www.betaarchive.com/wiki/index.php?title=Microsoft_K...
I think the installer itself was licensed from a third party.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
It was called Ext-VOS, and the main systems language was going to be J++.
The next COM Runtime.
See history of F# at HOPL, for some references on it.
However, the lawsuit happened, and the research language cool became C# and took J++ place, with J# being done for code migration from J++.
J++ already had P/Invoke (named J/Direct), Windows Forms (named Windows Foundation Classes), COM interop, events. The extensions that caused the lawsuit.
The background of Ext-VOS was visible in many environment configuration flags for .NET, that had COM_ prefix, nowadays replaced since .NET went open source.
Ironically after all this, Microsoft is back on the Java game, has its own OpenJDK distribution, and key contributions to the JIT.
Regarding the integration, you are missing the Microsoft politics, where WinDev is pretty much against anything that isn't C or C++. It has been a surprise that Rust has been accepted by them.
They are responsible for all safer attempts that could undermine Windows spotlight being killed (Singularity, Midori, Longhorn).
From what I gather, J++ would've been still a bytecode based, and GCd language, which would've had the same shortcomings as .NET when interacting with native code.
Also why there is the best practice to stay as much as possible inside. NET, or inside C++, instead of doing UWP API calls.
So don't fall into the usual trap thinking a tracing GC is worse.
As for Ext-VOS,
https://web.archive.org/web/20190111203733/https://blogs.msd...
How is this process different in UWP, and why is it heavier?
I'd guess, that since Win32 apps allocate one handle/kernel object per ui control, an UWP/WPF does not, your typical UWP app would use less handles than your typical WinForms one.
This is so error prone, that naturally there are smart pointers that keep track of this.
Like Apple did with Objective-C, and Cocoa's retain/release, VB 5 and 6, Visual C++, Delphi also have language extensions that keep track of this instead.
In Microsoft's C++ world, these language extensions are seldom used, because of the internal riot that killed C++/CX, replacing it with C++/WinRT.
So you still have the choices of using the smart pointers from MFC, ATL, WRL, C++/WinRT, WIL, or rolling up your own.
All of them with the caveat, that the Objective-C/Swift optimizations of removing needless pairs of calls does not take place.
So anyone that already knows the COM usage relatively well, tends to take shortcuts in the ways we are supposed to call AddRef()/Release (), as means to decrease the call count.
In .NET land, the runtime takes care of being more clever, via CCW/RCW infrastructure, caching instances and such.
Additionally there is the issue that a COM component can run in-proc, out-proc, or in-proc but hosted by specific Windows services, thus add OS IPC on top of each method call.
EDIT: Some of the guidelines, https://learn.microsoft.com/en-us/windows/win32/learnwin32/c...
Better way is to get one of those COM programming bibles, "Inside COM", "COM+ Unleashed", " .NET and COM: The Complete Interoperability Guide", "Windows Runtime via C#"
Part of it might come from Longhorn and it’s attempt to use garbage-collection (“managed language”) at its core.
Shouldn't there be room for a system that just does the thing(s) is does well? Why do we need to be continually tweaking? Adding increasingly obscure "features" and new bugs?
Unlike a human language, a computer language isn't "dead" when it stops changing. It is dead when nobody is using it. These are very different criteria.
New features often interact poorly with some of the existing features, as those features weren't designed with the new feature in mind.
A human language is considered dead if it no longer has any first-language speakers, but does have second-language speakers or is used fluently in written form, such as Latin. [0]
I broadly agree with your point though. Many languages would do well to slow their rate of change. There are very few slow-changing languages, like C, Forth, and Scheme. This 4 year old comment of mine on this topic is still applicable. [1]
But most of the new ones look and behave just like the old ones - but with slightly more awkward syntax to allow for some special "feature" dear to the authors ;)
I routinely check out the various new languages mentioned on HN and Lobsters. While plenty of languages are new to me, I'm yet to see any feature that is new to me :(
I appreciate the work that goes into any language, but the stream of "new" languages feels like a stream of tweaks and rearrangement. It's disappointing. Most new languages come across as "like language X but with feature Y".
Reminds me of all those "Airbnb for X" proposals from a few years ago:)
As a language, I hoped Vala would pave the way for a beautiful high performance application tool. Instead, we got Electron.
Which tells a story.
What's also interesting is that in Gnome 3, which came just a few years after, they chose JS because so many people already knew it and could easily develop for it.
I'd say the latter was the better idea, as there are far more shell extensions than Vala applications.
Likewise, I used to write Windows software in Pascal with parts in C and C++ because I oddly both found Win32 and COM and found interfacing with third-party libraries easier to deal with that way.
I'd point to PyQT as an example. It's function and documentation are flawless. I was able to build an entire web browser using it in a day(no, not a chrome competitor, just a simple one using QT and webkit components). The 'official' libraries are so clumsy in comparison.
To me, what was surprising about Vala is that it has automated memory management, C#-like syntax, but does not really offer memory safety, even if you don't interface with obviously unsafe C code.
The Genie language was created to expose a Python-like syntax to the Vala compiler.