Microsoft donates the Mono Project to the Wine team
mono-project.com
mono-project.com
Mono made a lot of sense for running places where full .NET didn't, like in full AOT environments like on the iPhone where you can't JIT, or for random architectures that don't matter anymore but once did for Linux (Alpha, Itanium, PPC, MIPs, etc.). When Microsoft bought Xamarin (which itself was born out of the ashes of the Novell shutdown of the Mono effort) and started the DotNET Core efforts to make .NET more portable itself and less a system-provided framework and merge in a lot of the stuff Mono did a single more focused project made more sense.
Mono was still left out there to support the edge cases where DotNET Core didn't make sense, which was mostly things like being a backend for Wine stuff in some cases, some GNOME Desktop stuff (via GTK#, which is pretty dead now), and older niche use cases (second life and Unity still embed mono as a runtime for their systems). The project was limping, though, and sharing a standard library but different runtimes after much merging. Mono's runtime was always a little more portable (C instead of C++) and more accessible to experiment with, but we need that less and less, but it's still perfect for Wine. So, having it live on in Wine makes sense. It's a natural fit.
Is there good documentation somewhere for getting set up to develop with modern .NET on Linux?
You can install at the link below, and then making a project is just `dotnet new console` and run with `dotnet run`
My point is about running existing applications on Linux, there are still issues with running .Net GUI stuff under wine and Mono was not a perfect implementation.
I read in other comments that the newer .Net cross platform stuff is not a replacement for Mono for running this old applications. (nobody will rewrite them to use the current GUI stuff from MS since are old apps)
If I was building a cross platform native app with .NET I'd probably use Avalonia right now.
I think not supporting Linux was a tactical error, though. Some people will put up with a lot for Linux GUI support, and some of those people are the types who can resolve problems with your half-baked GUzi framework.
And, at the end of the day, you have a tool with an extremely rich FFI capability so whatever is available from C you can use as well.
Huh
Alternatively, just because you're on .NET doesn't mean you need to use Microsoft sanctioned UI toolkits, just as C++ has no "official" UI toolkit. You're free to pick up some GTK or Qt bindings if you want a native feeling and your application is already architectures correctly. Alternatively, throw Imgui at it if you just need dev tooling, or maybe try other cross platform toolkits in the ecosystem like Avalonia or Uno
Support reasons. Still isn't the year of Linux Desktop.
Were I live and work (IT and consulting in central south-east Norway) it has been the year of the Linux Desktop on and off since 2009.
That was the first time I worked full time at a place that deployed Linux for everyone and everything that didn't have a verified reason for needing Windows.
I think we had one 3rd party trading software running on a Windows machine and maybe the CEO and someone in accounting got Windows.
Everyone else was upgraded to Linux and it worked beatifully. It was my job to support the sales department with desktop related issues and it was absolutely no problem to do it while also being a productive developer.
Since then I have not worked on a place that required Linux, but I think most of the places I have worked on since has had Linux as an option as long as you supported it yourself, and some places also have been very active writing how-tos and working with me to troubleshoot issues that were related to Linux, since many of them were also Linux users.
At the moment I use Mac, but at my current job I'm also allowed to use Linux.
Sure, Microsoft could pay more employees to work on it faster, but Linux loves and prefers open source from Linux devs "untainted by Microsoft", right?
Works better in proton from my experience though, but I think that is due to making unity games run better
Sadly some Java tools stopped working if you run latest Java runtime because for some reason some crap was removed from Java and nobody made some easy way to add them back with soem package install.
I'd say it's the simplest and quickest way to go if you need to bang out a quickie app for Windows only.
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/?v...
Also very easy to throw something together on top of SDL2 with Silk.NET.
Practically speaking it is in a much better place than many languages considered by parts of Linux community to be more """linux-oriented""".
It's (of course) not portable
That’s why loading System.Windows.Forms still works, it’s not part of .Net 5+, but it can still load the assemblies on Windows (they still use GDI, etc under the hood).
https://dotnet.microsoft.com/en-us/apps/maui
"Build native, cross-platform desktop and mobile apps all in one framework."
I know my buddy uses it to write Android apps on his Mac that interface to an ASP.NET Core web site.
This was the same year Antitrust came out: https://en.wikipedia.org/wiki/Antitrust_(film)
Any support for open source or cross-platform stuff was a bulwark against claims of monopoly abuse, but none of it worked well enough to be a true replacement. Mono worked for some purposes, but it was far from the first party support cross-platform .NET gets today. Nowadays it sounds like .NET Core + third-party GUI libraries is the way to go.
For reference for those unfamiliar with the terms:
.NET Core was the name given to the cross-platform fork of the .NET runtime.
It was forked out of .NET 4.x and dropped support for a lot of things in the first versions.
It ran on various distributions of Linux and MacOS.
At the same time there were forks of other libraries/frameworks in the .NET ecosystem to have 'Core' variants. Often these were dropping support for legacy parts of their code so that they could run on Core.
Later versions of .NET Core brought over support for a many of the things that had been dropped.
.NET Core and .NET had stand-alone versions until .NET Core was renamed to . NET and became .NET 5.
So, if you want to do the most modern cross-platform C# you would use .NET 9.
I love .NET. It’s a great stack, especially for backend web apps. Blazor is a great SPA framework too. But I loathe how Microsoft continue to handle just about everything that isn’t the framework and C# / F#. It’s laughable.
.NET Standard includes various versions of things that MS doesn't even touch.
I stopped doing .NET stuff before .NET 5 so I'm not hugely up to date with the latest shenanigans.
It’s just funny for newcomers to peel back the onion more. Writing a source generator? Target .NET standard 2.0 (not even 2.1) for a whole host of reasons.
Visual Basic .net ! What ?
But for the last 20-ish years it's really only been applied to things related to the .NET Framework.
So, yes - Visual Basic.NET is a language - it's the language that replaced Visual Basic 6. It compiles to the Intermediate Language (IL) that the Common Language Runtime (CLR) executes. There are other languages that compile to IL, too like C#, F#.
The .NET Framework is really a bunch of libraries and tools that are packaged together.
The .NET Standard is a standard that allows you to build a library to a known set of supported libraries and IL / CLR features.
So, yes, depending on which specific part you're referring to - it's all of those.
I’m just sad the video is not readily available because the facial expressions enhance the spot-on vocal inflections.
We do have the vocal inflections: https://m.youtube.com/watch?v=wPO8PqHGWFU
everything is .net, azure, 365, now also copilot.
It is "Core" in a lineage sense, but there's no need to make that distinction any more. The term "Core" is out of date, because the experimental "Core" fork succeeded, and became the mainstream.
For what I do, it's not really "Windows development" in any meaningful way. It is business functionality with HTTP, message queues etc, developed on mostly Windows laptops, and deployed to mostly Linux instances on the cloud. Not that the host OS is something that we have to think about often.
For this, .NET 3.x "the full framework windows only version" services are regarded as very much legacy, and I wouldn't go near one without a plan to migrate to a modern .NET version.
However, YMMV and people are also making windows desktop apps and everything else.
They've now abandoned that strategy, and instead they use it as a way to maintain lock-in at the IAAS/PAAS level (Azure).
I am told that the C# language has evolved faster and better than Java. Despite its origins in .NET 1.0 being basically a "Microsoft Java".
But paradoxically there is now more diversity of actively used languages that target the JVM. e.g. Kotlin, Scala, Clojure.
https://en.wikipedia.org/wiki/List_of_CLI_languages
https://en.wikipedia.org/wiki/List_of_JVM_languages
Quantity of languages might be less important than: how many needs are served by those languages, whether the ecosystem is dynamic enough to keep expanding served niches, and whether the culture and community is likely to produce language support for a niche that matters to you ever or on a realistic timeline. The JVM does appear to have a lot more niches covered, but you can still do all the things those languages do in what's available for the CLI.
I don't know much about the current state of CLI and .NET beyond what I've read here, but it sounds like it's dynamic enough to keep expanding. I also don't know enough about the long tail of niche languages supported by each to know which direction they're headed.
That's the situation with the tools used for music production. In theory, any DAW (Digital Audio Workstation) can make any kind of music. In practice, they all move toward different kinds of music, and you'll run into increasing friction as you do weirder or more complex stuff if you pick the wrong DAW. Cubase can do electronic music, but you're better off with FL Studio or Live. Live and FL Studio can do orchestral, but you're better off with Cubase.
And I'd guess there's a similar dynamic with CLI and JVM and the languages that target them.
> It was forked out of .NET 4.x and dropped support for a lot of things in the first versions.
>An early name for the .NET platform, back when it was envisioned as a successor to the COM platform (hence, "COM+"). Used in various places in the CLR infrastructure, most prominently as a common prefix for the names of internal configuration settings. Note that this is different from the product that eventually ended up being named COM+.
For example, see the top comment in https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/o...
The current release is .NET 8
.NET 9 is about 3 months away from the usual November release.
A factoid that's shared sometimes (no idea if true) is that Microsoft now employs more Linux kernel engineers than Windows kernel engineers due to Azure.
The Microsoft of the Halloween Documents[0] is a different Microsoft from the one we see today that understands open source as something good rather than as a threat, and it started with Microsoft being forced to play nice.
"The cloud" as we understand it didn't exist yet.
Strange times.
Bona fides: I have used GCP for 3 years, AWS for 3 years, and Azure for ~ 1 year. As well as the more "bare-metal" types of cloud providers like Linode/Akamai, and Vultr -- all the latter of which are great for self managing your infra.
I also really find the ability to spin up Windows Server and Windows 10/11 etc super useful for builds, testing, Hyper-V.
I really like Azure for huge projects with many moving parts.
Is "historical context" not as clear as I thought? You're the second person to challenge this by pointing out the current situation when I'm talking about how we got here.
Microsoft Azure was first released on February 1, 2010
Microsoft released .NET Core 1.0 on June 27, 2016
Will it be cross-platform?
yes
mingw is a GNU's header/library environment (tools too maybe?) to create windows compatible applications. So I'd look into searching mingw .net and/or mingw mono.
also, ask your favorite AI, they're good at this type of question so long as it's not up to the minute news
The UI isn't native, is a Skia canvass with drawn controls. But it'll work on basically every OS and it's pretty good.
Also, you're not writing JavaScript, so that's a win any day in my book.
And unfortunately, the only stench I can't stand more than Google's is Microsoft's.
Following buzz I started to do a prototype with Flutter and stopped after a few days as I found out that most of the open source controls I was using had bugs on Windows Desktop. Then I moved to MAUI and discovered that in order to have some decent Rich Text support my only option was Blazor Hybdrid. Nedless to say I found bugs that prevented my prototype to work correctly. Then I moved to UNO and found that it doesn't have full Rich text format support. I was able to find some .NET open source libraries for doing text layout on Skia and with that I was able to find a partial solution that was however pretty complicated. Out of curiosity I investigated Avalonia and found that everything that I needed had full support. Being fluent in WFP I built the prototype in 3 days and I never looked back.
Your experience might vary depending on your fluency of WFP but I found that, considering Windows Desktop as a target platform, Flutter and MAUI are absolutely the worst options. In my opinion Uno is better than Avalonia when considering web application support but Avalonia has more coverage of the WPF api with respect to what Uno does for WinUi. And for sure marketing is the worst part of Avalonia while it is the BEST for MAUI and Flutter.
BUT That's now officially unsupported as all of Xamarin Forms is no longer supported and the MAUI replacement doesn't cover Linux nor does that look likely (MAUI is mired deep in problems due over-ambition, failure to resource and it seems a significant push in MS to use MAUI Hybrid aka web UIs within native apps).
It is like the Web folks, that don't get anything else, are now pushing where .NET goes, mostly since .NET is now under Azure org chart.
I have done Web and native since "forever", not everything has to be for everything.
When Microsoft teams behave as such, why should we keep paying attention?
For native Windows, Forms, WPF, and even MFC is way better in VS tooling than WinUI C++.
https://docs.tryphotino.io/Overview
Which lets you run Blazor (web framework) like a desktop UI across all major desktop platforms. Microsoft has MAUI/Blazor as a thing, but only targets Mac and Windows ATM, so Photino bridges the gap for Linux.
Photino lets you use anything other than just .NET but has pretty decent .NET support.
If you cared about disk or memory usage you wouldn’t use electron, anyway.
There's the first party MAUI which is an updated version of Xamarin Forms. The two best-known third-party implementations are AvaloniaUI and Uno. I prefer Uno, it has more cross-platform targets.
- OS X: MonoMac or net6.0-
- Linux: GTK+
- Windows: Windows Forms (using GDI or Direct2D) or WPF
- Gtk3: https://github.com/GtkSharp/GtkSharp
- Gtk4: https://github.com/gircore/gir.coreHistory here https://en.wikipedia.org/wiki/.NET
.NET Core 1.0 (2016) was the first cross platform prototype. It got good in a release in 2018 or 2019, I even forgot which now. And took over steadily after that.
We don't even think about it any more. "which OS is the prod env on" isn't a factor that causes any support worries at all.
Getting set up would start at https://dot.net/
And the download page, which should show you content for your current OS https://dotnet.microsoft.com/en-us/download
But also other targets are here https://dotnet.microsoft.com/en-us/download/dotnet/8.0
You'll want the latest SDK 8.0.x
I would say I’m not ‘new’ and even developed .net 4.5 for a number of years. I’m just as stumped by the naming mess that Microsoft made across the board in that space.
Edit: I say 4.5 because I mean the original thick .net which is not dotnet core, which I think is the way to differentiate between versions, but also all the sub libraries like the orm were iirc named the same but did different things.
They should have rebadged everything with a new name that didn’t involve a word that is fairly painful to google (‘core’) can be used in development as well as the name of a framework.
So let's say you google how to do something and the result could be:
- .NET Framework
- .NET core 1
- .NET core 2
- .NET core 2.1
- .NET core 3
- .NET 5+
On stackoverflow, answers sometimes include all versions varieties.
Not really. It's legacy cruft all the way down.
But the good news is that if you stay on the beaten path, using the latest SDK and targeting the latest Runtime, everything Just WorksTM.
For example, just download .NET 8 SDK on whatever platform, which is usually very easy on most platforms, and then run `dotnet fsi` to get into an F# REPL.
To a point. Making cross platform native desktop apps is still in the hands of 3rd party vendors such as Avalonia and Uno. MAUI was supposed to fix that oversight to a less than stellar results.
That's what you have to compare against, and .NET/C# falls flat.
Er, I don't think this assertion is backed by data. See for example https://pypl.github.io/PYPL.html
Is Kotlin the most "active", "hot", or "up-and-coming" competitor? Possibly. But the "largest"? Its deployed footprint and popularity are nowhere close to Java's at this point in time.
C# and F# get to enjoy the integration that is "much closer to the metal" as well as much richer cross-platform GUI frameworks ecosystem with longer history.
Win32? Silverlight/Blend? XAML? MAUI? They're all windows only.
Gtk? Qt? Sure, they exist, but they're ancient and limited to long outdated paradigms.
I don't know if you can get QtQuick with KDE Kirigami to work on .NET, otherwise that might be one option.
Kotlin Multiplatform is btw a solution for building the same code for kotlin native, JVM and web to target all the OSes at the same time.
While Jetpack Compose is the Android Version of Compose, Compose Multiplatform is Compose for Kotlin Multiplatform.
> subject to the quirks and specifics of JVM implementations, build-systems and package management
That's a massive advantage over the arcane package management and build systems of .NET
Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem.
I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.
> That's a massive advantage over the arcane package management and build systems of .NET. Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem. I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.
If you want to sell me on "advantages" of invoking Gradle or Maven over
dotnet new web
dotnet run
curl localhost:port dotnet new console --aot
echo 'Console.WriteLine($"Right now is {DateTime.Now}");' > Program.cs
dotnet publish -o {here goes the executable} dotnet add package {my favourite package}
Also, what's up with Oracle suing companies for using incorrect JDK distribution that happens to come with hidden license strings attached?
Well, that's where the problem lies, isn't it? The ecosystem for .NET is extremely limited compared to what's available for the JVM
And the way JVM packages are distributed, with native libraries, BOMs and platforms allows more versatility than any other platform.
The build system may be better in dotnet, but that only really matters for the first 10 minutes. Afterwards, the other tradeoffs become much more important.
Nonetheless, you could make this argument for select Apache products, but that's Apache for you. It does not hold true for the larger ecosystem and, at the end of the day, quantity is not quality, otherwise we would've all been swept by Node.js :)
Same applies to "packages that bundle native libraries".
First, they are always maintenance-heavy to manage with ever growing matrix of platforms and architectures. Just x86 alone is problem enough as all kinds of codecs perform wildly different depending if AVX2 or 512 is available vs SSE4.2 or even SSE2 without EVEX. Now add ARM64 with and without SVE2 to the mix. Multiply this by 2 or 3 (if you care about macOS or FreeBSD). Multiply linux targets again by musl and glibc. You get the idea. This a worst-case scenario but it's something Java is not going to help you with and will only make your life more difficult due to the reason below.
There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem.
Meanwhile
using System.Runtime.InteropServices;
[DllImport("libc", EntryPoint = "putchar")]
static extern int PutChar(int c);
var text = "Hello, World!\n";
foreach (var c in text) PutChar(c);
(I'm not sure if binding process on the ole Mono was any different? In any case, the above is a thing on Linux since 8 years ago at least)
Like with other false claims, the "better native packaging" one is easily disprovable. Just look at the list of supported platforms here: https://github.com/sandrohanea/whisper.net?tab=readme-ov-fil...
It even supports CoreML on iOS and macOS.
* Now applies to C# too but for completely different reason - you can usually replace data crunching C++ code with portable pure C# implementation that retains 95% of original performance while reducing LOC count and complexity. Huge maintenance burden reduction and "it just works" without having to ship extra binaries or require users to pull extra dependencies.
I'm not sure if you've used JNA before? That's been the state of the art for many years: https://github.com/java-native-access/jna
public interface MSVCRT extends Library {
public static MSVCRT Instance = (MSVCRT) Native.load("msvcrt", MSVCRT.class);
void printf(String format, Object... args);
}
public class HelloWorld {
public static void main(String[] args) {
MSVCRT.Instance.printf("Hello, World\n");
for (int i=0;i < args.length;i++) {
MSVCRT.Instance.printf("Argument %d: %s\n", i, args[i]);
}
}
}
Sure, and it's got many great libraries – but actually using those is horrible.
You're absolutely right about Rust though. crates.io and cargo are amazing tools with a great ecosystem.
The primary issue I've got with the .NET ecosystem is actually closely related to that. Because it's so easy to import native libraries, often there's no .NET version of a library and everyone uses the native one instead. But if I actually want to build the native one I've got to work with ancient C++ build systems and all the arcane trouble they bring with them.
> Same applies to "packages that bundle native libraries".
You seem to have misunderstood. The fun part of the maven ecosystem is that a dependency doesn't have to be a jar, it can also be an XML that resolves to one or multiple dependencies depending on the environment.
What is the reason to continue making statements like this one? Surely we could discuss this without trying making accusations out of thin air? As the previous conversation indicates, you are not familiar with C# and its toolchain, and were wrong on previous points as demonstrated. It's nice to have back and forth banter on HN, I get to learn about all kinds of cool things! But this happens through looking into the details, verifying if prior assumptions are still relevant, reading documentation and actually trying out and dissecting the tools being discussed to understand how they work - Golang, Elixir, Swift, Clojure, etc.
> You seem to have misunderstood. The fun part of the maven ecosystem is that a dependency doesn't have to be a jar, it can also be an XML that resolves to one or multiple dependencies depending on the environment.
Same as above.
> JNA
I was not aware of it, thanks. It looks like the closest (even if a bit more involved) alternative to .NET's P/Invoke. Quick search indicates that it comes at an explicit huge performance tradeoff however.
From https://github.com/zakgof/java-native-benchmark?tab=readme-o...
"Now let's look into performance of the native call only, stripping out the struct allocation and field access:"
Native call only (average time, smaller is better)
JmhCallOnly.jna_direct 1373.435 ± 70.343 ns/op
JmhCallOnly.jna 1346.036 ± 72.239 ns/op
JmhCallOnly.bridj 383.992 ± 50.000 ns/op
JmhCallOnly.jnr 298.334 ± 48.785 ns/op
JmhCallOnly.jni_javacpp 56.605 ± 8.087 ns/op
JmhCallOnly.foreign 49.717 ± 6.667 ns/op
That's definitely true, but it should be possible to reimplement JNA on top of the new FFM APIs for convenient imports and high performance at the same time.
> Of course the numbers can be presented in a much more .NET-favored way by including the allocations that Java has to do in the absence of structs and other C primitives.
Hopefully Project Valhalla will allow fixing that, the current workarounds aren't pretty.
I fully agree though that .NET is far superior in terms of native interop.
> As the previous conversation indicates, you are not familiar with C# and its toolchain,
I've been using .NET for far over a decade now. I even was at one of the hackathons for Windows Phone developers back in the day.
Sure, I haven't kept up with all the changes in the last 2-3 years because I've been so busy with work (which is Kotlin & Typescript).
That said, it doesn't seem like most of these changes have made it that far into real world projects either. Most of the .NET projects I see in the real world are years behind, a handful even still targeting .NET Framework.
> were wrong on previous points as demonstrated.
So far all we've got is a back and forth argument over the same few points, you haven't actually shown any of my points to be "wrong".
This conversation comes up from time to time. It is sometimes difficult to talk to developers who have a perception of .NET that predates .NET Core 3.1 or so and newer. Windows Phone and its tooling is older. I am sad UWP has died, the ecosystem needs something better than what we have today, and the way Apple does portability with MacCatalyst is absolutely pathetic. In a better timeline there exists open and multi-platform UWP-like abstraction adopted by everything. But these were other times and I digress.
The package distribution did not change significantly besides small things like not having to write .nuspec by hand in most situations. Nuget was already good and far ahead of the industry at the time it was introduced.
The main change was the switch to SDK-style projects files. Kind of like Cargo.toml but XML.
Adding a file to a nuget package (or anything else you build) is just adding a <Content ... /> item to an <ItemGroup>.
Adding custom MSBuild stage or behavior is done via .targets file for packaging purposes: https://learn.microsoft.com/en-us/nuget/concepts/msbuild-pro...
Which is why I linked you Whisper.net. It has a .targets file that manages platform-specific dependencies: https://github.com/sandrohanea/whisper.net/blob/main/Whisper....
As you can see, it is possible to make definitions conditional and use arbitrary information provided by the build system. It is very powerful. I don't know what made you think that I assume anything about .jar files.
For another example, look at these lines: https://github.com/U8String/U8String/blob/main/Examples/Inte...
Together with <PublishAot> property, invoking 'dotnet publish -o .' calls into cargo to build a static library from Rust, then compiles C# project, then compiles the produced .NET assemblies to native object files with ILC (IL AOT Compiler), and then calls system linker to statically link together .NET object files and a Rust object file into a final native binary. The calls across interop, as annotated, become direct C ABI calls + GC poll (a boolean check, multiple checks may be merged so less than a branch per call).
This produces just a single executable that you can ship to users. If you open it with Ghidra, it will look like weird C++. This is a new feature (.NET 7+) but even without NativeAOT, it was already possible to trim and bundle CIL assemblies into a single executable together with JIT and GC. As far as I'm aware, the closest thing that Java has is Graal Native Image, which is even more limited than NativeAOT at the present moment (IL linker has improved a lot and needs much less annotations, most of which can be added as attributes in code and the analyzer will guide you so you don't need trial and error). And the project that allows to embed bytecode in the .NET trimmed single-file style in Java is still very far from completion (if I understood it right).
I think https://two-wrongs.com/dotnet-on-linux-update is more or less representative of unbiased conclusions one makes when judging .NET by its merits today. You can always say "it used to be bad". Sure. It does not mean it still is, and the argument is irrelevant for greenfield projects, which is what I advocate C# is the better choice for anyway.
> I fully agree though that .NET is far superior in terms of native interop.
This is not limited to native interop. At its design inception, C# was supposed to replace C++ components at MS. Then, in C# 2, a focus group including Don Syme if I'm not mistaken pushed for generics and other features. Someone posted a history bit here on HN.
This and influence from the projects like Midori (spans, struct improvements), and subsequent evolution (including the existence of Mono) and especially after it stopped being .NET Framework and became .NET resulted in a language that has much wider scope of application than most other GC-based languages, including Java, particularly around low-level tasks (which is also why it's popular in the gaming industry).
Unfortunately, the perception of "another Java" hurts the ecosystem and discourse significantly, as the language and the platform are very unlike this claim.
MAUI is not windows only. I have a MAUI app on my android phone. Cross-platform? yes. Rich? Now, I wouldn't call it that.
> - Android 5.0 (API 21) or higher is required.
> - iOS 11 or higher is required
> - macOS 11 or higher, using Mac Catalyst.
> - Windows 11 and Windows 10 version 1809 or higher, using Windows UI Library (WinUI) 3.
Okay, where's Linux? That's what Mono was originally made for and where Mono really shines.
Also, the development experience isn't great either:
> - If you are working on Linux, you can build and deploy Android apps only
> - You need a valid Visual Studio or IntelliCode subscription
The getting started guide only exists for Windows and macOS and the forum post announcing experimental Linux support is full of caveats.
I don't think you and I would agree on what "cross-platform" means, especially in the context of Mono being donated to Wine, which is a heavily linux-centric discussion topic.
> - You need a valid Visual Studio or IntelliCode subscription
You don't: https://marketplace.visualstudio.com/items?itemName=ms-dotne... (DevKit, which is the licensed one, is completely optional - it gives you VS-style solution explorer. You can already get it with e.g. F#'s Ionide that works for any .NET file in the solution, though I use neither)
Or https://github.com/razzmatazz/csharp-language-server with either Neovim or Emacs.
> Okay, where's Linux? That's what Mono was originally made for and where Mono really shines.
Regretfully, you have not read the rest of the discussion that talks about this a lot, so here it goes:
Uno: https://platform.uno/docs/articles/get-started-vscode.html?t...
(Uno has more involved setup and build than Avalonia but has way better mobile targeting, and casual reports indicate smaller memory footprint)
Avalonia: https://avaloniaui.net + https://marketplace.visualstudio.com/items?itemName=Avalonia...
dotnet new --install Avalonia.Templates
dotnet new avalonia.app
dotnet run
Gir.Core (GTK4 and co., successor to GTK#): https://gircore.github.io/docs/use.html
ImGui with Silk.NET: https://github.com/dotnet/Silk.NET/blob/main/examples/CSharp...
Well, those sentences were quoted from Microsoft's own documentation...
Sure, you've shown that some tooling exists, but it's sadly not easy to discover or as well supported
So this "it's all for backend now" notion is surprising.
This must be the most unfriendly Linux install documentation I've ever seen though, it was not easy to find the names of those packages.
It's been there for several years now, hasn't it?
It's not. Microsoft provides its own apt repository you need to add first.
Does it not meet the DFSG?
$ apt search dotnet
p dotnet-apphost-pack-6.0 - Internal - targeting pack for Microsoft.NET p dotnet-apphost-pack-7.0 - Internal - targeting pack for Microsoft.NET p dotnet-apphost-pack-8.0 - Internal - targeting pack for Microsoft.NET p dotnet-host - dotNET host command line p dotnet-host-7.0 - dotNET host command line p dotnet-host-8.0 - .NET host command line p dotnet-hostfxr-6.0 - dotNET host resolver p dotnet-hostfxr-7.0 - dotNET host resolver p dotnet-hostfxr-8.0 - .NET host resolver p dotnet-runtime-6.0 - dotNET runtime p dotnet-runtime-7.0 - dotNET runtime p dotnet-runtime-8.0 - .NET runtime p dotnet-runtime-dbg-8.0 - .NET Runtime debug symbols. p dotnet-sdk-6.0 - dotNET 6.0 Software Development Kit p dotnet-sdk-6.0-source-built-arti - Internal package for building dotNet 6.0 So p dotnet-sdk-7.0 - dotNET 7.0 Software Development Kit p dotnet-sdk-7.0-source-built-arti - Internal package for building dotNet 7.0 So p dotnet-sdk-8.0 - .NET 8.0 Software Development Kit p dotnet-sdk-8.0-source-built-arti - Internal package for building the .NET 8.0 p dotnet-sdk-dbg-8.0 - .NET SDK debug symbols. p dotnet-targeting-pack-6.0 - Internal - targeting pack for Microsoft.NET p dotnet-targeting-pack-7.0 - Internal - targeting pack for Microsoft.NET p dotnet-targeting-pack-8.0 - Internal - targeting pack for Microsoft.NET p dotnet-templates-6.0 - dotNET 6.0 templates p dotnet-templates-7.0 - dotNET 7.0 templates p dotnet-templates-8.0 - .NET 8.0 templates p dotnet6 - dotNET CLI tools and runtime p dotnet7 - dotNET CLI tools and runtime p dotnet8 - .NET CLI tools and runtime p libgtk-dotnet3.0-cil - GTK.NET library p libgtk-dotnet3.0-cil-dev - GTK.NET library - development files
I've been using the script installer version intended for ci/cd as I actually like that installer more, it's the only one that really supports multiple versions correctly.
Do not under any circumstance trust Microsoft for anything at all.
They have a decades-long history of treating their best customers with contempt.
They will break or deprecate whatever you rely on, and they will do it without warning.
https://time.graphics/line/291016
This is quite overwhelming, but it can still be useful when reading an article about .NET that is either older or refers to history as you can quickly see where in time it is located.
For a historic summary of why it used to be a confusing situation (up until maybe 2020), see https://two-wrongs.com/dotnet-on-non-windows-platforms-brief...
That also has some background on why the Mono project found itself in a weird spot.
currently debian has a mono package but no dotnet-core package. i'm not sure why this is; usually when debian lacks a popular nominally open-source package like this, it's either because it fails to build from source, or because it has some kind of tricky licensing pitfall that most people haven't noticed, but diligent debian developers have
does anyone know why this problem exists for dotnet-core?
also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?
and, correct me if i'm wrong here, but doesn't c# allow you to statically allocate structs just as much as c does? i'd think you'd be able to avoid garbage collection about as much as you want, but i've never written much beyond 'hello, world' in c#
Otherwise, statics are placed in a static values array "rooted" by a respective assembly. I believe each value will be contained by a respective box if it's not an object. This will be usually located in Gen2 GC heap. My memory is a bit hazy on this specific part.
There is no concept of globals in .NET the way you describe it - you simply access static properties and fields.
In practice, you will not be running .NET on microcontrollers with existing mainline runtime flavours - very different tradeoffs, much like no-std in Rust. As mentioned, there is NanoFramework. Another one is Meadow: https://www.wildernesslabs.co which my friend is using for an automated lab for his PhD thesis.
Last mention goes to https://github.com/bflattened/bflat which supports a few interesting targets like UEFI. From the same author there's an example of completely runtime-less C# as well: https://github.com/MichalStrehovsky/zerosharp. It remains a usable language because C# has a large subset of C and features for manual memory management so writing code that completely bypasses allocations is very doable, unlike with other GC-based alternatives.
Does Debian require packages to work on all of its architectures? If so, that could be the issue. .NET Core only supports x86, x64, and Arm64 (I think Arm32 has been discontinued and RISC-V is experimental at this point).
It's possible that they object to .NET Core having certain license restrictions on the Windows port (https://github.com/dotnet/core/blob/main/license-information...). .NET Core is mostly MIT or Apache licensed, but the Windows SDK has some additional terms. Skimming the third party licenses, that doesn't seem like an issue (mostly MIT/BSD/Apache or similar).
I think the licensing situation is an interesting question: if you have software that's 100% open source when compiled for your OS, but requires non-free stuff to run on Windows, is it ok to include in Debian? It looks like none of the non-free stuff (like WPF) gets distributed with the non-Windows SDK builds. Binaries created from your code only depend on MIT-licensed stuff on macOS and Linux, but might depend on something closed-source when targeting Windows - though it looks like almost all of that stuff is either WPF (so you wouldn't be able to develop on Linux/Mac anyway since those libraries wouldn't be in the SDK on those platforms) or were removed as a runtime dependency in .NET 7. It looks like `Microsoft.DiaSymReader.Native` might be the only thing left. Maybe that's what is holding it back?
> also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?
"Reasonable" can be a lot of things to a lot of different people. People have been working on RISC-V support. Samsung seems interested in it. But I probably wouldn't recommend it at the moment - and Mono doesn't really have RISC-V support either.
They could get one of their people to become Debian maintainer.
Perhaps the Debian project would force a .NET package to come with telemetry disabled by default, but for as long as said employee can abide by the rules of Debian, I don't really see any reason it can't be done.
debian doesn't require packages to work on all of its architectures. luajit, for example, has not been ported to riscv64, mips64el, or ppc64el https://packages.debian.org/sid/luajit, though lua5.1 is https://packages.debian.org/sid/lua5.1. what the debian policy manual says about architecture-specific packages seems to be https://www.debian.org/doc/debian-policy/ch-controlfields.ht...:
> Specifying a specific list of architectures indicates that the source will build an architecture-dependent package only on architectures included in the list. Specifying a list of architecture wildcards indicates that the source will build an architecture-dependent package on only those architectures that match any of the specified architecture wildcards. Specifying a list of architectures or architecture wildcards other than any is for the minority of cases where a program is not portable or is not useful on some architectures. Where possible, the program should be made portable instead.
i don't think the license you link to would be a problem in itself, because it only applies to certain files which are not useful for running dotnet-core on debian anyway. debian has lots of packages from which non-free-software files have been removed. i don't know anything about diasymreader?
with respect to esp32 and ch32v003, what i meant to point to was not the risc-v architecture (some esp32s are tensilica!) but the limited memory space; jit compilation is not a good fit for 2 kibibytes of ram or even 520 kilobytes of ram
.NET 9.0 preview still includes ARMv7 builds for Linux: one based on glibc library, another one for Alpine.
Fedora [2], Ubuntu [3], and FreeBSD [4] build .NET from source themselves. A lot of work has been done to make it possible to build .NET from source [5] without closed source components, so it might just be a matter of someone being motivated to create the package for Debian.
[1]: https://learn.microsoft.com/en-us/dotnet/core/install/linux-...
[2]: https://src.fedoraproject.org/rpms/dotnet8.0
[3]: https://launchpad.net/ubuntu/+source/dotnet8
[4]: https://github.com/freebsd/freebsd-ports/tree/main/lang/dotn...
as for building from source, i see, thanks! or maybe it's unresolved legal concerns? nobody so far in this thread has known of any, though
https://bugs.debian.org/cgi-bin/%3Ca%20href=%22bugreport.cgi...
So far no one has mentioned licensing being an issue.
that seems to be from only a few weeks ago though
it doesn't seem to have come up on debian-legal in the last year or so https://lists.debian.org/debian-legal/ but debian-legal is also kind of a shadow of its former self
I think telemetry collection alone should be a good reason for Debian to consider repackaging it. I don’t want telemetry to be collected on my GNU/Linux machine, thanks Microsoft, but you already have so much telemetry from my Windows machine, please leave my other machines alone.
https://dotnet.microsoft.com/en-us/platform/telemetry
https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...
https://github.com/dotnet/sdk/tree/main/src/Cli/dotnet/Telem...
In any case, Debian would use https://github.com/dotnet/source-build and dotnet/dotnet, and could easily include the argument or a patch for this. It’s unlikely to be an issue. My bet it was not in Debian because there was no one to take initiative yet or there was but that person has faced a backlash by people in Debian who are similar to vocal minority here that posts FUD because of their little personal crusade.
i think the links you provide make it clear that the criticism is not unfounded
Does the wine project have the resources and knowledge to maintain it?
Or is it just so that microsoft can say they aren't the ones discontinuing it?
But he was in love with COM/DCOM, registry, and many other things that MS shipped. Some of these things made Gnome much slower than it could be.
Wikipedia says,
> Until 2020, Microsoft had not made any public statements about Wine. ... On 16 February 2005, Ivan Leo Puoti discovered that Microsoft had started checking the Windows Registry for the Wine configuration key and would block the Windows Update for any component. As Puoti noted: "It's also the first time Microsoft acknowledges the existence of Wine."
> In January 2020, Microsoft cited Wine as a positive consequence of being able to reimplement APIs, in its amicus curiae brief for Google LLC v. Oracle America, Inc.
It’s the exact same situation as downloading a Windows ISO from Microsoft’s website and running it with an activator.
I still don't trust MS's motives in general, but I think they at least recognize that Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standard when it comes to things like desktop gaming, and that this is a good thing for them.
On the server side, MS knows that Linux is by far the most popular server OS, and official support for running .NET backend apps on Linux from MS themselves is a win for them as well.
If the answer for .Net was 'no' then there are meaningful domains where people would just jump ship in a second. Research, academia, teaching, and certain government areas pop to mind. Keeping Linux support, because of that server dominance, is a core concern for them.
Dumping endless piles of cash into projects nobody cares about and pretending like you're the dominant player when you control some dwindling 2% of the market is stupid and more companies should learn that lesson
Remember when Microsoft was able to fight off the Web with piss-poor Internet Explorer? Until it didn't.
I'm not sure if it benefits microsoft in the long term, because the "backwards compatibility" features of Wine need to be implemented in Windows already as a part of the system. So in the long run wine/proton/mono will implement windows features on linux in an optional/replaceable/modular way in user-space while keeping backwards compatibility for older windows software, while windows is forced to implement (and distribute these features) with their OS and has to sacrifice backwards compatibility if they want to simply their OS.
I would say that the adoption of wine/proton helps the linux ecosystem a lot more because there wasn't a standard executable format for linux beforehand (static? tarball of program and dynamic libraries? .deb file? AppImage? Flatpak? Higher-level language like java?). How do you reliably link to libraries like mesa or even glibc? Now there is a solution: just distribute a windows program and test it to confirm it works in wine/proton. Perhaps it is better for DirectX adoption, but it seems like Vulkan/OpenGL/WebGPU are still superior in terms of cross-compatibility, regardless if you use wine or not.
By this logic there wasn't a standard executable format for Windows, either (static? zip archive of program and dynamic libraries? .msi file? installer program? UWP? higher-level language like C#?).
Sometimes running old software atop Wine on Windows is the easiest - or even only - option to have said old software work on new Windows.
There are perfectly fine _actual_ cross-platform standards like Vulcan and OpenGL. If your goal is cross-platform, making a Windows app that you hope will be converted well enough is a strange way to approach it.
Do you know how you can play the game on linux? Yes, using the windows version with lutris, which is 32bits too.
Windows goes back and beyond for compatibility with existing compiled software and Wine inherits that, is partially why Windows versions under Wine often have a higher chance of running than the native versions (ARK is a great example)
Projects like Flatpak attempt to solve this by the use of runtimes.
Steam has incentivized this with their Steam Deck Verified program. The Steam Deck being so popular means a lot of studios want their games to be verified on Deck, and if they're verified on Deck then they work in the Linux desktop version of Steam out of the box.
Next they killed of an open source competitor (Mono) of their product, stole the usefull bits to put it in .Net, and now they dump the leftover project (that's not competing with them anymore) back into the OS world.
How is that not a smart way of doing business?
What kind of moustache-twirly stupidity is this? Yeah, Microsoft maintained a shitty cross-platform SDK so that developers would make worse software, because that's somehow helping any of their main product verticals. By the way, those are (broadly speaking) cloud, client software, and games.
Do you have any evidence to suggest that there was a Xamarin-based application that would have directly competed with Office? How about Fallout? Now, do you have any evidence that Microsoft tried to make Xamarin worse at doing the thing that application was trying to do?
> Next they killed of an open source competitor (Mono) of their product
Microsoft's implementation is also open source, and has been for almost a decade: https://github.com/dotnet/runtime
> that's not competing with them anymore
Sure. Mono is only useful for legacy purposes. Microsoft's own design was always the reference implementation of .NET, regardless of whether it was open-source. Mono existed for the sole purpose of being an open, cross-platform reimplementation. Now that the reference design is itself open-source and cross-platform, Mono is mostly redundant.
a nitpick, they acquired Xamarin for half a billion dollars, that's not really stealing is it.
The "keeping [developers] from developing products that can actually compete" assertion is frankly absurd. .NET's real competitor is and has always been Java. Java, possibly the world's most-used platform that isn't JavaScript, has always had heaps more people working on it than .NET's entire ecosystem, let alone just the Mono project.
I think it's the same for any global enterprise: profit.
In that regard, "trusting" something like MS is like evaluating their stock: what do they make money off, what is a threat to that. Which makes it rather easy to "trust" them: if they can make money off SomeOpenSourceProject they'll help it along, if it doesn't help, nor threat, they'll ignore it. If it's a threat, they'll put (some) money towards fighting it.
For me the difficult part, and why I still don't fully trust MS, even with Github or VScode lies in their internal competition: MS has projects that directly compete eachother. Business-wise it makes no sense to me (and is the primary reason I'll stay away from investing in MSFT). But also their internal competion between profit now and delayed profit. MS has often done things (or not done things) that increase the bottom line this quarter, but harm them over years. In that regard too, MS makes no sense to me Business-wise. I guess having a cash-cow-"monopoly" for decades kinda absolves them of the responsibility to run the entire company in a way that makes sense business-wise.
You can argue that the my-thing-wrapped-inside-your-thing increases exposure to my-thing and that's a net good outweighing any other factors, but you can just as validly argue it helps divert from actual adoption of my-thing and facilitates never moving from your-thing, since no one has any actual empirical study, it's all just feelings and beliefs.
Maybe one logical argument that might have some meat is maybe WSL/Wine just means that the exposure vs crutch aspects cancel each other out (for every user who is exposed to foreign-thing and maybe decides to adopt it, there is another user who thanks to the swallowed version does not ever have to to move), and if that's true, then any imbalance in effects comes down to the the innate virtues of the two things. Both groups of people are equally exposed to both platforms and have equally good-enough use of both platforms, and neither has to actually change to get the benefits of the other, and so the user will choose whichever actually seems to serve their needs the best as their native platform.
I wonder if it's possible to make a desktop backed by WSL that would be a better experience than the current ad/spying-riddled Windows native desktop? Then MS would be forced to try to enshittify WSL so that it doesn't provide an escape and superior experience from the current Windows experience. Is WSL a good thing THEN?
At least for now, WSL has absolute crap access to hardware, not even just like gpus for gaming but even simple things like access to a usb-serial adapter. So, it's probably not possible to make a functional WSL desktop yet. Maybe such things will intentionally never be fixed in WSL just for this reason, so you can only ever use it for pure web app development no different from a cloud instance.
I've worked with Azure team, all greenfield they do for Azure goes on Linux as well. Windows Server is pretty much dead to Microsoft though it will be continue to be supported and released because $$$.
In the end we decided to just let the management think what they want. I've been more of a Unix person for 40 years but I kind of miss the "good" versions of Microsoft Server - in the 1990s / early 2000s it was a real contender. If they hadn't doubled down on weird things like Powershell it might still be a contender.
Sure, it's got some unique characteristic that more traditional shell users dislike but that's just a matter of taste.
Someone wrote some automation code that handles json payloads using powershell. When we tried to migrate to azure functions which uses 7.x by default things broke because users never cared to check sensitivity of key names.
It’s also slow even for interpreted language standards.
I’ll seriously never use powershell for anything serious ever again even though I admit syntax and design feels kinda nice.
It's just best to think about Powershell 5.1 and Powershell Core 7.x like Py2 -> Py3. Most of code works as is, some doesn't, and you should use latest when you can.
>Someone wrote some automation code that handles json payloads using powershell. When we tried to migrate to azure functions which uses 7.x by default things broke because users never cared to check sensitivity of key names.
Azure Functions are nightmare in its own. Not sure how much of that is Powershell fault vs Azure Functions.
>It’s also slow even for interpreted language standards.
Actually, it's blown Python out of the water at work. It's startup time can be painful as it's interpreting everything but once it gets going, it really moves. We use it to churn through 4GB CSV at work replacing a Python script, it's much much faster.
>I’ll seriously never use powershell for anything serious ever again even though I admit syntax and design feels kinda nice.
Your loss. Despite the few problems I run into, I really like it and wish more *nix people gave it a try. It's much better then bash nightmares I've seen.
NT also had OS/2 and Posix subsystems ((checks calendar)) about thirty years ago, now that I think of it.
I think that they don't care about going against the open soruce community, given that Microsoft uses a lot of open source software in their products (also, probably violates the terms of the GPL license of such software).
It's hazy to me when reverse engineering of APIs is and isn't allowed.
We're hard at work adding Luau (https://luau.org) as a supported language for both in-world scripting as well as client/viewer-side scripting. As a handy byproduct of that, LSL will also gain the ability to be compiled to Luau bytecode, allowing us to eventually (someday, at least) shed any need for our custom-patched version of Mono 2.6. More juicy details here: https://wiki.secondlife.com/wiki/Lua_FAQ
Source: I work at Linden Lab. If these sorts of things excite anyone, we're hiring! https://lindenlab.com/careers
Edit: quick hat tip to Mono.Cecil which I've used a couple of times to crack .Net components to bypass licensing code. It's not that we didn't pay for them but we couldn't be bothered to deal with license deployment and maintenance.
Free software is typically described as "free as in freedom" or "free as in free beer". (This is probably a limitation of English tho, my language has 2 different words for permissions and costlessness.) GP above proposes the "free as in puppy" variant, which means that it is a burden of maintenance. I can't recall any real examples for this.
Sorry but no it doesn’t. These words have the other meanings you mentioned, but they don’t include either of the meanings of “free”.
If you said you were giving away “gratuitous software”, native English speakers wouldn’t know what you were talking about. The only way to understand it would be to realize that those words are etymologically cognate to words in European languages that do have those meanings.
Strangely enough, I think the LaTex distribution qualifies, too. I tried to install it recently, and it wanted 1 GB of disk space! That's multiple times the size of the entire system disk when LaTeX was created...
Sooner or later a lot of the web is going to run on WASM, at which point we'll have a virtual machine running in a user program running on an OS which incompletely virtualizes the bare machine (hence why we've ended up with WASM). Extra gratuitousity if the browser is an Intel binary being run on an M* processor via Rosetta translation... Maybe eventually we'll realize that the OS needs to provide a full virtual machine, complete with window to draw in, filesystem isolation like Plan 9, etc. But, inertia will probably make it take while.
There is the TinyTeX distribution, which is smaller. (Despite its name, it isn't tiny, or small, or medium in size, but it is also large. But smaller than the default LaTeX distribution with all the possible packages, source code and documents.)
"Gratuitous" also has that definition, though it's far less common in use. See the dictionary definition, e.g., here: https://www.dictionary.com/browse/gratuitous
> 2. given, done, bestowed, or obtained without charge or payment; free; complimentary.
It's more of a stretch there, because the primary definition of gratuitous has a connotation of unnecessary, even undesirable. If you didn't have at least some hint of disapproval of a service, you'd reach for the word "free" long before "gratuitous".
Similarly you would say someone who’s gotten out of prison is now “free” (or libre in French or Spanish) but you wouldn’t say they’re “liberal”.
https://english.stackexchange.com/questions/118717/how-is-th...
However Mono is easier to embed into other applications and easier to port to new platforms. That is for example why it's used for the .NET/Blazor WebAssembly stuff. Microsoft still maintains their own fork of Mono for this specific use case.
Mono also implements some of the legacy Windows Desktop GUI frameworks like WinForms and WPF that Microsoft never bothered to port to their new .NET runtime. This is probably why the Wine developers might be interested in Mono.
https://dotnet.microsoft.com/en-us/apps/maui
I was pleased to see WinForms got some updates in .NET9. I really thought they'd left it. I still use it every day when I need to spin up a new tool to do some little task that needs a GUI.
Microsoft Build this year only discussed WinUI and WPF even.
https://www.reddit.com/r/dotnet/comments/1cy2u6l/microsoft_h...
But as I just had a Powerbook I used Mono to run it on OS X. At the end of the course someone from Microsoft came to the university to answer any of our question about upcoming features in .NET and C#. And as we were a small group I set directly in front of him with the shiny apple point at him.
Very interesting language at that time. .NET not so much. Also still remember that we were tasked to implement 3 sort algorithms of our choice. One of mine was bogosort and with Mono on PPC it could sort up to 7 elements, before becoming really slow.
This is my first time seeing Microsoft acknowledge Wine's existence, and in this case, it was at least in a friendly manner? Or could there be bad faith behind this 'donation'?
While I am still wary of Microsoft after their previous anti-competitive behaviors, I think they've taken a more pragmatic view of late, and realize that projects like Wine are actually good for their platform as a whole. I expect if Wine/Proton did not exist, we'd see more (for example) Windows-only games ported to macOS or Linux. With Wine/Proton, those ports are mostly not necessary, and Microsoft gets to say that Win32/DirectX is something of a cross-platform gaming "standard".
See <https://simonwillison.net/2024/Jul/13/give-people-something-...>.
When a publisher or manufacturer wants to end a product line, instead of shutting it down, spin it out as F/LOSS, and give it some seed money. If the thing is good, people will pick it up and it will survive. If not, the company still gains public appreciation.
This dovetails well as a potential solution into the problem we are discussing in the Smart TV, smart home, smart vehicle articles.
(if you respond, please, lets not get into his politics; HN is not the right place to have that kind of discussion)
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icaza, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the Mono that got merged into .NET, becoming the building block for multiple components and one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. It is also useful for initial stages of new platform bring-up process. Note that you are not expected to use it for targets that support CoreCLR due to a massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.
Not that massive; factor 1.8 as we found out recently.
The comparison we discussed was for unrepresentative code that used none of the features that make .NET fast (generics, SIMD, expected forms of inheritance and abstraction and devirtualization they enable, CoreLib APIs). The closest case in there was JSON serialization which CoreCLR was 385% faster at. It is unfortunate that you feel a need to say this, knowing that it doesn't even show a tip of the iceberg.
Please do not mislead casual readers here with such comments.
They will have a bad time running basic programs - the original Mono is outdated and cannot execute assemblies that target non-legacy versions, and the Mono that lives in dotnet/runtime (which you have to go out of your way to use on CoreCLR platforms) tends to have all kinds of regressions on user-provided code that is not as robust on runtime checks to ensure that Mono does not accidentally go onto the path that that it has especially bad regression on. Even CoreLib code nowadays uses more and more struct generics assuming monomorhpization which performs poorly on Mono. There is very little work done to improve performance on Mono with effort invested mostly in WASM area and to ensure it does not regress further. Major platforms like Android and iOS are in the slow but steady progress to migrate to CoreCLR/NativeAOT (there are other reasons not in the least much smaller binary size). And for WASM there is NativeAOT-LLVM experiment that is likely to make Mono obsolete for that target too.
The workloads that matter and are representative are the ones produced by C#, F# and VB.NET compilers as well as projects that care about exercising the standard library and/or produce recommended CIL forms (like https://github.com/FractalFir/rustc_codegen_clr).
What you say contradicts with the measurements, even the ones you made yourself (https://news.ycombinator.com/item?id=41101743).
I don't know what your motivation is to give Mono a bad reputation. I assume you're paid by Microsoft or one of its affiliates, are you?
People here are likely to run C# and F#, not Oberon+ that compiles to (terrible) CIL.
Why so arrogant? The CIL is good enough. It's a promise of the ECMA-335 to cope even with unoptimized CIL, and Mono indeed includes many optimization steps. Your arguments - especially concerning SIMD and other features supported by CoreCLR - are absolutely not relevant in this context. CIL is always the same (regardless whether the CIL was generated by your big C# or my small Oberon compiler), and if I feed unoptimized CIL to CoreCLR, it still has the opportunity to make use of the SIMD features of the given CPU if need be. As already discussed it's even more interesting to base the performance comparison on unoptimized CIL, because by the end of the day we all want to know how good the optimizers of Mono or CoreCLR are.
And you didn't answer my question, so I assume you're working for Microsoft or some of their affiliates, and your claims are obviously biased by this.
Comparison against Oberon+ string primitives allocates a new char array every time. Other operations allocated it to just null-terminate it (string constants are null-terminated already for example, or can be done so explicitly by compiler instead, in any case this is an incorrect design). Somehow, it failed the basic task of modeling C behaviors on the one and only high-level bytecode target that comes to modeling C the closest. This was the very first thing I saw when I opened the compilation artifacts with ILSpy.
In any case, my goal was to post a disclaimer and it is fulfilled.
So what? What do you think do the dotnet string or marshalling classes internally? And how should that affect the performance comparison if we feed the same CIL to both - Mono and CoreCLR?
But we can leave it at this; people can read the arguments at the given link, we don't have to repeat everything again.
All that said, probably C#.
A lot of what you’ll learn when you first learn programming is going to be applicable in any language though. Once you’re comfortable with C#, and can understand the difference between imperative, object-oriented, and functional programming, you’ll be in a good place to check out F# (or any other language, really).
Good luck with your learning!
Given modern Python means type annotations everywhere, the convenience edge between it and modern C# (which dispenses with much of the javaesque boilerplate) is surprisingly thin, and the capabilities of the .net runtime far superior in many ways, making it quite an appealing alternative especially for perf sensitive stuff.
export DOTNET_CLI_TELEMETRY_OPTOUT=1
All I see is a manager saying, "the data shows no one uses it"
I have a number of these devices running in the house doing various things.
Refactoring tooling is unmatched.
.NET native compilation toolchain supports this mode but it's not a default for a reason (causes binary size bloat too, musl is rather small, but ICU is very much not).
(just to be accurate - all C# and runtime code becomes a single static executable, but cross-compilation is possible between CPU architectures within OS only, with additional options enabled by 'PublishAotCross' nuget package that switches to Zig toolchain's linker so you can AOT compile for Linux targets under Windows, for "self-contained trimmed JIT executables" you can target any OS/ISA regardless of what you use)
Anyway:
dotnet new console --aot #or 'grpc --aot', or 'webapiaot'
dotnet publish -o .
As of today, ILC has become better at binary size baseline and scalability due to more advanced trimming (tree-shaking) analysis, metadata compression and pointer-rich binary section dehydration (you don't need to pay for embedding full-sized pointers if you can hydrate them at startup from small offsets). You can additionally verify this by referencing more dependencies, observing binary size change and then maybe looking at disassembly with Ghidra.
Also better capability for true static linking - you can make .NET NativeAOT toolchain produce static libraries with C exports that you link into C/C++/Rust compilations, or you can link static libraries produced by the latter in NAOT-compiled executables[0][1]. It is a niche and advanced scenario that implies understanding of native linkers but it is something you can do if you need to.
Binaries compiled in such a way will have its interop become plain direct calls into another section in it (like in C). There will be a helper call or a flag check to cooperate with GC but it's practically free. Costs about 0.5-2ns.
[0]: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
[1]: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Why .NET > Go in my opinion? - performance-wise the gap is not big and probably even .NET can be quicker - development time can be reduced, tooling is great for .NET and even funny-not-funny error handling is cleaner - still much easier to find people in .NET than Go where I live and work
Now it's time to verify those assumptions - I'm going to implement next real project in .NET and see how it went. Hobby or "trials" in .NET resulted in fun and speed, but it often happens on first date :)
Binaries will be huge tho compared to Go. I’ve a few CLIs that I that I my customers need to use, I’m planning to rewrite them in Go for this reason.
[1] https://learn.microsoft.com/dotnet/core/deploying/native-aot... [2] https://github.com/MichalStrehovsky/sizegame?tab=readme-ov-f... [3] https://learn.microsoft.com/dotnet/core/deploying/native-aot...
https://learn.microsoft.com/en-us/dotnet/csharp/linq/get-sta...
Although the SQL-like form isn't always favoured, and quite a lot of the time I use the plain OO one.
Oh yes, extension methods: do you want object X to support method Y, but can't change object X? Well, provided you don't need access to anything private, you can just add a method and do X.Y()
There are two main interfaces in .NET that have different behavior:
IEnumerable<T> which a sequence monad, much like Seq types in FP languages or IntoIterator and Iter (IEnumerator<T>) in Rust. This is what you use with whenever you 'var odd = nums.Where(n => n % 2 is 0);`.
IQueryable<T> which is what EF Core uses for SQL query compilations looks the same as the first one, and has the same methods, but is based on something called "Expression Trees" that allow runtime introspection, modification and compilation of the AST of the expressions passed to Select, Where, etc. This existed in .NET for ages and really was ahead of the time when it was introduced. You can write a handler for such expression trees to use LINQ as sorts of DSL for an arbitrary back-end, which is how EF and now EF Core work. You can also compile expression trees back to IL which is what historically some of the libraries that offer fast reflection relied on. Of course this needs JIT capabilities and runtime reflection, which makes it AOT-incompatible - calling .Compile() on such query in a JIT-less application will be a no-op and it will be executed in an interpreter mode. It is also difficult for the linker to see the exact types that are reflected on which means you have to annotate the types you want to keep and AOT compile code for. Which is why this mechanism is largely replaced by source-generation instead, closer to how it happens in C++, Rust, etc. An example of this is Dapper AOT.
var even = nums.Where(n => n % 2 is 0);
Blazor: It's Microsoft's way of doing in-browser C#. It can do quick-and-dirty server-side HTML, and professional-grade, in-browser WASM.
Why is this useful "for someone who develops web application backends"?
The nice thing about server-side Blazor is that you can make a management console, or otherwise port ops scripts, into a self-service page. Because you can choose to render on the server, you don't have to write an API, serialize your response, ect. You can do a SQL-ish query (with LINQ and Entity Framework) in the middle of HTML.
(Granted, for production-grade pages Blazor can run in the browser as WASM and use industrial-strength APIs.)
And making a cross platform app framework which looks like native UI is much harder.
In contrast, Unity's UI systems are all terrible and looking native isn't even one of their goals.
I'm a little out-of-the-loop here.
Does this announcement mean that Microsoft used to fund developers to work on this project, and now will cut that funding?
But:
> Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork.
Does that mean that this mono project and its associated repo and what is within the dotnet repo are not the same and could (if they have not already) diverge?
Since then, microsoft supports https://github.com/dotnet/runtime, which is MIT licensed
Mono has no reason to live anymore, hence the lack of commits and contributions
It is a dead project, I wonder what winehq has in mind here
edit: as pointed by the comments, mono supports .net runtime before the newer ".net core" (which is not compatible). Because wine wants to be able to run older windows code, they probably still use this.
Edit: To add, isn’t the above about ASP .NET Core? Mono is mostly about the time before Core, and it is not the same.
Edit: maybe this means WPF can be the best way to write Linux applications. After all, Win32 is the stable Linux API... nudge nudge, wink wink. :-D
On the website (where my quote comes from) it links to https://github.com/dotnet/runtime/tree/main/src/mono which is a mono within what you linked too.
So this is a case of 2 different mono's?
Sorry just trying to make sure I am understanding what is happening here properly given the exact same name in 2 places...
- Originally there was .Net Framework, by microsoft, for windows only. Versions 1.0 -> 4.8 were released.
- Then mono came along as a somewhat clean-room reimplementation of .Net framework, focusing on making it run on Linux. Though mono does not implement windows gui widgets, so for that there's stuff like Gtk#. And you cannot run windows GUI applications on mono for this reason, even though the core parts might be portable. Eventually Microsoft acquihired the Mono team.
- Later on Microsoft made the core of .net open source and portable, creating .Net Core. Or .Net Runtime, linked above, which is apparently the same thing (not sure when they dropped the "Core" part of the name). Applications written for .Net Framework can't just be recompiled for .Net Core/Runtime, there is porting work that needs to be done. And similarly as for .Net framework, even though the core is portable and open source, the windows gui libraries are not. So again windows GUI applications written using .Net Runtime cannot run on Linux. Not sure if there exists anything like Gtk# for .Net Runtime, allowing creating native Linux GUI applications with .Net Runtime?
- Finally, we have wine which is an implementation of the Windows API on Linux. And in a wine environment you can install e.g. .Net Framework including GUI libraries, so you can run .Net GUI applications that way.
While Microsoft doesn't have their own framework supporting Linux GUI apps on the modern .NET runtime (MAUI does Mac/iOS/Android but not Linux), there are third-party ones like Avalonia.
It is harmful to write new code that targets .NET Framework and existing actively maintained applications all have migrated to .NET. The ones that did not either have poor maintenance or authors that lack time as they don't owe extra effort unless they want to do that (or sometimes it is a skill issue, unfortunately).
It was called .NET Core until they officially retired the .NET Framework (ie v4) by releasing .NET 5.
This isn't really true. Mono functions as a complete replacement for the ".NET Framework" - something that can be used to run any .NET app, including "legacy" apps targeting old ".NET Framework" versions, on any supported platform, even when the app was built to target Windows.
dotnet/runtime is intended to run more modern applications that target ".NET Core" - basically, stuff that's cross-platform on purpose.
There are tons of subtle differences relating to these goals but also some glaringly obvious ones, like mono having an implementation of Windows.Forms.
> hence the lack of commits and contributions
Microsoft have been actively forcing contributors out of mono/mono and into the dotnet/runtime repo for several years now, while Wine kept a weird halfway fork at https://gitlab.winehq.org/wine-mono/mono . Formally transferring `mono/mono` and the Mono name over to Wine will in theory allow `mono` to more effectively accept code which works to improve legacy .NET Framework support for compatibility reasons, while dotnet/runtime can continue to evolve as the way to run intentionally targeted .NET Core code.
Anything that was in the old .net that isn’t in core today won’t ever be.
Then there’s stuff that was missing in the earlier versions of core that existed in old dotnet. Some of it they later realised was useful for newer apps or apps migrated to core. These pieces were ported over by Microsoft or replaced by 3rd party implementations (e.g. avalonia for xplat ui).
(.net core is actually officially just .net, they dropped the core from the name)
What are those Desktop apps you speak of?
Clearly, everything is a command-line backend pipeline in container with a web UI.
And everything that isn't can be easily deprecated. /s
More targets, much leaner (< 10 MB clr + mscorlib), less than factor two performance difference to current CoreCLR, written in C, easier to compile than CoreCLR, etc.
Yes, they have diverged. Just as Microsoft forked the CLR to create CoreCLR, so too has mono been forked. Features like multiple AppDomains have been removed from this fork. Here is an example pull request:
Is this true? The pre-releases and version 1 of .Net came with the source for a reference implementation of the CLR that ran on Linux or BSD. I can't remember what license it had and I thought Mono was a separate project, but maybe Mono was based on it. Not that it matters now.
Lagacy .Net never supported OSes other than Windows. Mono, released in 2004, was the first attempt to bring it to other OSes.
The Mono website has an archive of an old mailing list post which at the time talks about even-older origin of the project. It is (of course) heavily biased for Mono, and hilariously gives me an awkward shout out ;P.
So it ran on Windows, FreeBSD and Mac OS X making it the first non-Windows implementation of .Net, but it didn't run on Linux. It also had a fairly useless licence, so Mono was separate.
https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...
Edited to add: and thanks for the link. Only three developers and there's already drama! :-)
Mono is still really the only way to run older .NET (pre FOSS runtime/Core .NET) on non-Windows platforms.
So Wine has historically kept a fork of mono for use within Wine for supporting .NET apps.
Modern .NET can be built for Linux, etc so this is less relevant now but there are still a lot of apps that depend on old .NET and Wine still gets value out of that.
There are a bunch of downstreams that get used for various purposes (Microsoft uses mono for webasm embedded .NET for example) so it makes sense to give over ownership of Mono to the Wine community as they are best aligned with the original upstream's intended use case (as a full replacement for .NET).
So yes it's on life support but arguably more in the sense that it has since specialized into a bunch of downstream projects. The upstream will probably mainly be used for coordinating common improvements that all of the downstream forks care about (which are mainly Wine and Microsoft).
Also, I'm not sure how relevant Mono is in the context of Wine. .NET Core is no longer an OS component, but just a runtime that ships with software. Imo their focus should be on getting said runtime working, rather than maintaining a .NET fork.
https://www.bloomberg.com/news/articles/2016-02-25/microsoft...
This way will allow them to improve Mono accordingly? Who knows? /me-thinks...
but it is indeed the basis for Proton
Games themselves typically aren't .NET but ancillary components, like launchers or map editors, are.
Or is this more of a steward role rather than technical connection
Yes, Microsoft does do Linux these days, they even have their distro, but this still does not answer the question of why they would replace real Windows with Wine and risk compatibility issues, if they don’t have to pay anything for licenses.
I dont think this is how it works in the real world.
Even if it did, giving it away would be equally a write off as just shutting it down.
> The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
I kept thinking Microsoft needs to port a windows version for their handheld, doesn't want to use steamos, but also needs to work with 'interesting' hardware. Their answer would be a linux port imo, but having too much there could annoy trust regulators so they divested from mono. but I had zero proof for any of these hunches.
.Net Framework will be supported as long as Windows Servers OSes it runs on support it. If Windows Server team ever casts it out, it will die.
For example, Windows XP can't access the modern internet because it doesn't support TLS 1.2 or 1.3 and most of the web is now secure. The software still exists, but the world around it has shifted so it doesn't really work. If 95% of people end up owning electric cars, gas stations are going to become scarce. Maybe there will be workarounds, but the world will have shifted around the product. Let's say that all gas pumps were changed to wider-nozzle pumps. Sure, you could make an adapter, but that's the point: changes in the world around you end up necessitating changes, workarounds, etc.
It might be mostly read-only, but there's always little possible things that come up requiring work to be done on it.
No wonder Miguel de Icaza is now focused on Swift, Godot and Apple's ecosystem, all the promises done at Xamarin acquisition time are gone now.
Mono Develop killed, after being renamed into VS4Mac, gone through a rewrite, only to be killed shortly after the rewrite reached 1.0.
Xamarin.Forms rewriten into MAUI, with incompatible APIs.
MSIL Linker had a better chance as a critical piece of Blazor WebAssembly and Native AOT.
The whole dotnet reload drama.
Now Mono donation, and then .NET team is surprised .NET uptake on UNIX shops isn't as they expect.
In alternative universe when the Xamarin acquisition didn't happen, where would we be now?
The license cost was high, and the MS acquisition came right around the time React Native and Flutter started to enter v1. I think they'd of been blown out of the water pretty quickly. At least Microsoft allowed Xamarin to get into enterprise .NET shops pretty quickly. There's a lot of B2B form based apps written in Xamarin. I worked on a pretty big one that made (and continues to make) a lot of money.
I've long assumed the point of the acquisition was because Xamarin did basically all the hard work of allowing .NET to be cross platform.
https://www.codeguru.com/dotnet/net-nuts-bolts-the-joy-of-ro...
Or DotGNU?
https://www.gnu.org/software/dotgnu/
What happened to Xamarin looks like Microsoft took whatever IP was relevant, and left everything else go, which this decision is a confirmation thereof.
It is kind of interesting to see Miguel's feedback, now that he his allowed to talk about how things went down.
I assume he’s got fuck you money now though. I’m very excited to see what he does with Swift and Godot, Swift is a great language for gamedev.
https://x.com/migueldeicaza/status/1610665502598127616?lang=...
Second paragraph of the article by the way, just saying.
Mostly interesting in that it is a token of goodwill from Microsoft to Wine something which is in line with the current Microsoft view of the OS market but would have been very surprising not that long ago.
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...