6 ms·

Vala is an interesting language - it looks like C#, but is a compiled, reference counted, GObject based language (which is Gnome's/GTK's object model library),

Vala is an interesting language - it looks like C#, but is a compiled, reference counted, GObject based language (which is Gnome's/GTK's object model library), that simplifies/streamlines writing app code, compared to writing it in C. 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.

lukeh 2y ago
Perhaps it was an era when everyone was trying to compete with (or embrace) Java?
- rzzzt 2y ago
  .NET and C# appeared to counter the proliferation of Java after J++ has been sidelined in court: https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigation_against_Microsoft https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigatio...
  - giancarlostoro 2y ago
    Yep, there was also J# an intermediary language so you could run old J++ code on .NET iirc which obviously became defunct sooner rather than later since C# became defacto. I have yet to meet a C# dev who actually touched J++ or J# to be honest.
- jahewson 2y ago
  Yep, some interesting tidbits here https://stackoverflow.com/questions/1083368/whats-the-early-history-of-the-net-framework https://stackoverflow.com/questions/1083368/whats-the-early-...
- chubs 2y ago
  My recollection of the reason back then was that running on a VM would make the transition to 64 bits smooth, which at the time was worrying everyone a lot.
neonsunset 2y ago
Speaking of, today you can use https://gircore.github.io https://gircore.github.io for rich GObject (and GTK4) interop. It is relatively new hence not widely known but is already used by e.g. https://www.pinta-project.com https://www.pinta-project.com. It's a proper and actively maintained successor to GtkSharp.
- giancarlostoro 2y ago
  That gives me a messed up idea of using Vala to implement a main GUI and then embedding mono to let users expand your app using this.
  - neonsunset 2y ago
    Embedding Mono today might be a mistake. You really do want to embed CoreCLR instead if you can, even though it's a bit more complex. 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 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.
    - giancarlostoro 2y ago
      Not specifically married to Mono, just what came to mind as I typed it. Regular .NET works just unfamiliar with how commonly it gets embedded.
adw 2y ago
And a massive success in games development, particularly on mobile. (Unity!)
lmz 2y ago
Did you forget Visual Basic? That was a COM-consuming, easier to use language.
- giancarlostoro 2y ago
  I low-key wish they would open source the compiler so the open source community could make an attempt at rebuilding the IDE. I have heard they cannot open source all of it, wish they would open what they can.
  - chungy 2y ago
    Your wish is granted. https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn
    - lmz 2y ago
      My guess is they want VB6, not VB.NET.
      - giancarlostoro 2y ago
        Correct. There was something really nice about VB6 not needing any special runtime, just bundle any DLLs or OCX files you need and you're golden.
        chungy 2y ago
        Memories of missing vbrun60.dll come to mind. (or whatever the name of its runtime was)
        giancarlostoro 2y ago
        It was an installer, installed all the DLLs, which if you bundled with your application, meant you were golden to run it as-is. Though you are technically correct that you need them, I think my statement still stands: You just need to bundle the required DLLs and OCX files and you're golden. https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/192461 https://www.betaarchive.com/wiki/index.php?title=Microsoft_K...
pjmlp 2y ago
WinRT is how .NET was going to be initially. https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ 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).
- torginus 2y ago
  Thanks for the article, I'll be sure to read it when I have the time - unfortunately there seems to be nothing in there about J++ and Ext-VOS which would be the most interesting to this discussion. 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.
  - pjmlp 2y ago
    COM reference counting happens to be a big deal, that is why UWP applications are much slower than Win32 ones, it isn't only about the sandbox. 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.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-research-project-history-the-msr-white-paper-from-mid-1999/ https://web.archive.org/web/20190111203733/https://blogs.msd...
rbanffy 2y ago
> integrating it, and most of the internal teams treating it with animosity. Part of it might come from Longhorn and it’s attempt to use garbage-collection (“managed language”) at its core.
whalesalad 2y ago
C# was a response to Java. Microsoft RARELY innovates. They look around and what is trendy and cool and copy it (usually in terrible fashion) and shove it down the throats of all the customers who can’t leave them.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]

lukeh 2y ago

Perhaps it was an era when everyone was trying to compete with (or embrace) Java?

rzzzt 2y ago
.NET and C# appeared to counter the proliferation of Java after J++ has been sidelined in court: https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigation_against_Microsoft https://en.wikipedia.org/wiki/Visual_J%2B%2B#Sun's_litigatio...
- giancarlostoro 2y ago
  Yep, there was also J# an intermediary language so you could run old J++ code on .NET iirc which obviously became defunct sooner rather than later since C# became defacto. I have yet to meet a C# dev who actually touched J++ or J# to be honest.
jahewson 2y ago
Yep, some interesting tidbits here https://stackoverflow.com/questions/1083368/whats-the-early-history-of-the-net-framework https://stackoverflow.com/questions/1083368/whats-the-early-...
chubs 2y ago
My recollection of the reason back then was that running on a VM would make the transition to 64 bits smooth, which at the time was worrying everyone a lot.

neonsunset 2y ago

Speaking of, today you can use https://gircore.github.io https://gircore.github.io for rich GObject (and GTK4) interop. It is relatively new hence not widely known but is already used by e.g. https://www.pinta-project.com https://www.pinta-project.com. It's a proper and actively maintained successor to GtkSharp.

giancarlostoro 2y ago
That gives me a messed up idea of using Vala to implement a main GUI and then embedding mono to let users expand your app using this.
- neonsunset 2y ago
  Embedding Mono today might be a mistake. You really do want to embed CoreCLR instead if you can, even though it's a bit more complex. 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 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.
  - giancarlostoro 2y ago
    Not specifically married to Mono, just what came to mind as I typed it. Regular .NET works just unfamiliar with how commonly it gets embedded.

adw 2y ago

And a massive success in games development, particularly on mobile. (Unity!)

lmz 2y ago

Did you forget Visual Basic? That was a COM-consuming, easier to use language.

giancarlostoro 2y ago
I low-key wish they would open source the compiler so the open source community could make an attempt at rebuilding the IDE. I have heard they cannot open source all of it, wish they would open what they can.
- chungy 2y ago
  Your wish is granted. https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn
  - lmz 2y ago
    My guess is they want VB6, not VB.NET.
    - giancarlostoro 2y ago
      Correct. There was something really nice about VB6 not needing any special runtime, just bundle any DLLs or OCX files you need and you're golden.
      - chungy 2y ago
        Memories of missing vbrun60.dll come to mind. (or whatever the name of its runtime was)
        giancarlostoro 2y ago
        It was an installer, installed all the DLLs, which if you bundled with your application, meant you were golden to run it as-is. Though you are technically correct that you need them, I think my statement still stands: You just need to bundle the required DLLs and OCX files and you're golden. https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/192461 https://www.betaarchive.com/wiki/index.php?title=Microsoft_K...

pjmlp 2y ago

WinRT is how .NET was going to be initially. https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ 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).

torginus 2y ago
Thanks for the article, I'll be sure to read it when I have the time - unfortunately there seems to be nothing in there about J++ and Ext-VOS which would be the most interesting to this discussion. 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.
- pjmlp 2y ago
  COM reference counting happens to be a big deal, that is why UWP applications are much slower than Win32 ones, it isn't only about the sandbox. 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.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-research-project-history-the-msr-white-paper-from-mid-1999/ https://web.archive.org/web/20190111203733/https://blogs.msd...

rbanffy 2y ago

> integrating it, and most of the internal teams treating it with animosity. Part of it might come from Longhorn and it’s attempt to use garbage-collection (“managed language”) at its core.

whalesalad 2y ago

C# was a response to Java. Microsoft RARELY innovates. They look around and what is trendy and cool and copy it (usually in terrible fashion) and shove it down the throats of all the customers who can’t leave them.

deleted 2y ago
[deleted]

deleted 2y ago

[deleted]