They could also donate comparability with modern MsOffice.

This seems to happen a lot. The thing gets acquired, makes somebody rich, then is completely written off on the balance sheet 5 years later.

How is .Net/Mono connected to Wine?

Or is this more of a steward role rather than technical connection

This makes me curious. Could MS secretly be using wine for some of their Azure services?

Never miss a good tax write-off.

Is this a "dropped on community" project like Borg/Kubernetes fiasco with most PRs ending up in the following, and just corpo-sponsored changes and patches getting through?

> The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

I wonder what kind of a tax write off this can turn into

That's a funny way to spell "fobs off".

i think this is related to Xbox soon launching a handheld gaming device like the switch/steam deck. anything that directly refutes this hunch?

.NET now runs on Linux and other platforms, so what is the purpose of maintaining Mono separately at this point?

"Free as in beer" just became "free as in pony?"

Yet another piece of Xamarin/Mono that falls down.

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?

What is the mono logo? a gorilla with a hat? or a pile of poop? serious question.

"Donates"? A code base is a maintenance burden.

Yes, some things never change:

https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

Another perfect execution of embrace(Microsoft became the steward of the Mono Project when it acquired Xamarin), extend(Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork), extinguish(we recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET) for anyone who thought MS had actually changed since the bad old days.

More like going to the local library with a bunch of old books. It might be worth keeping them, but someone has to sort them out.

The Wine project apparently decided they wanted to keep alive an old version of a piece of software Microsoft has no interest in and Microsoft gave them the official repo instead of throwing it out.

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.

It's not like Microsoft can force Wine to take the codebase. In order for this to be donated, the Wine project needed to accept it.

Pretty much, by the look of it. But we still don’t know everything or what exactly the Wine project has on its metaphorical mind.

This gives me strong https://youtu.be/aCP27_vquxQ?si=WztFEXETGLcsAT51 vibes.

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.

Why would they want to use Linux though?

I’m a big fan of Miguel’s work. His comments have been pretty interesting. You also don’t have to read between the lines much to know how he feels about what’s happened to his tech.

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.

Where is this feedback you’re referring to?

It won't get new features, but will likely require maintenance to keep it running as new versions of operating systems are released.

Is there anything to suggest that there will be further changes? I mean, other than bug fixes.

"Supported"... Kind of. Showstopper stuff is fixed. Other stuff is not. My last company had two open bugs with .Net Framework on more recent versions of Windows Server that were year and half old.

.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.

One example, others are equally easy to find,

https://x.com/migueldeicaza/status/1610665502598127616?lang=...

Specifically, he has a port of the Godot editor for the iPad in the works.

> 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?).

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#?).

Windows NT (2000, XP, etc) used to include an emulator allowing to run DOS apps and win16 apps. I don't see why running older / obsoleted win32 APIs through an emulation layer won't be a good approach. Maybe even by adopting and running Wine.

> 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.

Sometimes running old software atop Wine on Windows is the easiest - or even only - option to have said old software work on new Windows.

i’d upvote this twice if i could…

I can’t remember, sorry. I met them at a tech meetup a couple years before I was using AWS and it didn’t stick in my brain. Except the funding source bit.

> stole the usefull bits to put it in .Net

a nitpick, they acquired Xamarin for half a billion dollars, that's not really stealing is it.

I don't think Microsoft viewed Mono as a competitor. Even before Microsoft acquired Xamarin for hundreds of millions of dollars, they already had a history of collaboration on .NET, including sharing test cases in order to help with compatibility, and co-developing integrations into Microsoft products such as Azure and Office 365.

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.

> kept a ton of developers busy learing useless Xamarin...

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.

winforms are supported in .NET, obv only for Windows

Yeah I think it also supports WPF. Can't remember where I read that.

I don't understand. How does that help cross platform?

All I see is a manager saying, "the data shows no one uses it"

I looked into it but some libraries I've been using wasn't compatible with AOT. I'll check it again when I have more time. Thanks.

This must be the reason. Wine seeks to be compatible with a bunch of legacy software, some of which will want to use the equivalent of .NET 1, 2, 3, and 4.x Framework and not just "dotnet core". (Or whatever the new thing is called in Microsoftese this week.)

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

You mean `dotnet publish -r linux-x64 --self-contained` ? This will embed the runtime in the executable. You can also do trimming so it removes anything that's not used. Also, there's AOT but it's got a ways to go.

Sibling comments talk about self-contained. I'll just be pedantic and say that this has nothing to do with the language itself.

You can. It'll probably be bigger than the Go binary but you can.

The "fully static binary" only works because Go ships cryptography and most other usually host-provided features that other languages rely on host's libc instead, at the cost of performance, limited feature support and requirement to recompile everything in order to ship (inevitable) security fixes, which did happen in the past.

.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 .

Notes: gRPC tooling is a bit heavy, webapiaot template could be improved in my opinion

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...

Presumably being able to make money spinning up cheapo servers, via Azure, just reinforces that decision.

The .NET Core runtime was never a fork of Mono, it’s always been a separate code base.

gratuit (free as in free puppy) libre (free as in free software)

They dropped the "Core" suffix with v5 in 2020, since at that point there was no longer naming confusion.

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.

See https://news.ycombinator.com/item?id=41372165

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).

> not sure when they dropped the "Core" part of the name

It was called .NET Core until they officially retired the .NET Framework (ie v4) by releasing .NET 5.

Definitely C#. You’ll find tons more resources. F# is fantastic, but it’s not a good *first* programming language.

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!

It doesn't matter, if you want to "actually" use .Net you have to at least be able to read C#. And I guess some files still - as it was 3 years ago - need to be C#, for example in mobile apps.

Its an interesting question. I've found personally people with previous imperative/functional language (e.g. JS/Go/etc) have picked up F# quicker, and people with OO knowledge (C++, Java, etc) have picked up C# quicker. There's a lot of implied/conventional knowledge with OO that many C#'s dev forget they have (i.e. its all sunk cost to them). If you just want to cut and paste code however C# has more Microsoft provided doco so there's that.

C#

Honestly this is such an interesting question. Conventional wisdom would definitely say C#, but I’ve always wondered if that’s because imperative programming is easier than functional for a beginner, or because basically everyone starts with imperative. I’d be curious to see what would happen if someone started functional first.

All that said, probably C#.

not everything running on a 20-mips 32-bit microcontroller with 2 kibibytes of sram needs to be hard real time and failure-free, and of course the esp32 has hundreds of kibibytes

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#

GC is fine for many (most?) applications there. For example sensor stuff, display, networking, turning your lights on and off, etc.

It's even worse, since they dropped the core now and just call it .NET. So searching has become even more of a pain. It's also pretty much a mess, because many things were different between the versions.

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+

Many times there will be no clear indication what version the result was built on.

On stackoverflow, answers sometimes include all versions varieties.

I think Microsoft is completely allergic to naming anything with a unique name or term; in fact, it's almost like they pick names that will be hardest to find with a google search.

They finally started to admit where they're losers and stop trying to fight those battles.

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

And that's why they have a $3.08 trillion market cap

So we have to restart from scratch?

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?

It's been very hard to explain to my organisation that Windows Server is dead. We haven't deployed a system to it in two years, everything is some kind of dockerised linux thing but the "we're a Microsoft shop" idea prevails.

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.

Won't most apps use way more .net stuff than core? Mono was a way to run dotnet apps on Linux, killing it meant killing cross platform support for modern dotnet desktop apps?

EF ("entity framework") is the ORM. LINQ lets you write queries against any collection, such as a Dictionary or a List. So I write lots of "listOfFoo.Select(x => x.Name).ToArray()" style code with it, which compiles down efficiently.

LINQ is just the way .NET calls iterator expressions that are a staple in any language that claims to be good and modern.

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);

to be clear, my question about debian is not about whether i can install dotnet-core in debian; it's about why it isn't in debian's repositories rather than microsoft's. microsoft, to understate the case somewhat, doesn't provide the stringent protections for users that debian does

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

> Arm32 has been discontinued

.NET 9.0 preview still includes ARMv7 builds for Linux: one based on glibc library, another one for Alpine.

I would say it is .Net Foundation job to prepare and submit the package not Debian maintainers.

And yet, the win32 is the only one that is confirmed to work. Example: Game Neo Scavenger is available for linux with binaries for them. They dont work in any modern linux because (I believe) they were compiled for a 32bits version of linux.

Do you know how you can play the game on linux? Yes, using the windows version with lutris, which is 32bits too.

And yet, Linux gaming is largely dxvk and proton.

Are those frameworks available in .NET 8 on non-Windows platforms, though? If not, I think that's what the GP was getting at.

I think MS wants you to use this?

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.

I think that's the intended implication - that it's "free to a good home" - meaning any new owner takes on a lot of responsibility.

That's what ’free as in puppies’ mean.

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.

To be fair, "free as in beer" doesn't work for a lot of people who don't drink (or do drink, but don't like beer). I don't think we're going to come up with a one-size-fits-all slogan...

What's your point? Don't take the puppy if you don't want it.. not everyone has a use for this software either.

Static fields may be placed on Frozen Object Heap. The values of static readonly fields may not exist at all if the ILC's static constructor interpreter can pre-initialize it at compile-time and bake the value into binary or codegen. Tiered Compilation does a similar optimization but for all cases. This is with JIT though which is not usable in such environment.

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.

there are ways (byref I think?) to pass references to stack variables around. And Statics depends. Static const even with stuff like strings would just compile directly into the binary, regular static still has to end up on the Heap.

getting one of your people to become a debian developer is similar in difficulty to getting one of your people to become a senator or a citizen of switzerland

You needed Powershell for Headless, SSH and Terminal to make sense. WSL required mindset shift at Microsoft.

It irks me that the default for servers still seems to be 5.1 which is anemic and seems to have really weird quirks and syntax differences from later versions. As if the default silent jsondepth thing was not enough converfrom-json hash tables have case insensitive keys. Really?

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.

> The CIL is good enough.

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.

MVC is something entirely else?

When using Microsoft repositories you need to explicitly opt out on telemetry collection.

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.

yes, i know about the microsoft apt source

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

Debian developers can do it right because they're not affiliated with the vendor, so they can disable user-hostile features and settings that the vendor enables by default.

Notably in that bug report the reporter says they cannot maintain it (not that I blame them, not a small work)

This is wild, apparently this stuff is in the Debian repos now? https://learn.microsoft.com/en-us/dotnet/core/install/linux-... So you can just apt install dotnet-sdk-8.0.

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 fully-cross platform

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.

Oh my god I forgot about .NET Standard. What were they thinking…

PSA for new players.

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.

If only. Class libraries still have to worry about this.

The word "liberal" definitely has the same definition of "libre"--ever hear of the term "liberal democracy"? That's exactly the same kind free they're talking about.

"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".

"Gratuitous software" would be excessive and unnecessary software. Which I think a lot of commercial (particularly "news") websites qualify for, and "modern" websites in general. NPM makes it easy to just install something, which requires all kinds of other things, which duplicate each other, etc.

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.

dotnet-sdk-8.0 should have the rest of what you need downstream from there. For other libraries and versions, you should be able to use NuGet with your project directly.

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.

The Request For Packaging arrived a week ago, its all still very fresh and new: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078132

Well here in the project readme there is a table with the sizes: https://github.com/rstudio/tinytex-releases (a bit outdated, they didn't refresh it). I downloaded TinyTex-1 for Windows, it's 338 MB uncompressed. It is _huge_ in my book.

.Net is "Microsoft Java". Like Java it was designed to do everything, but as desktop development died (and mobile development was locked down by Apple and Google, limiting it to their corporate languages), it pivoted towards networked applications.

Same with java - designed for embedded set top devices, pivoted to backend services.

That's also not part of the JVM or the Java language.

Jetbrains is a third party vendor here, too.

No and it's not even close. Kotlin only has a single Jetbrains Compose (I presume Kotlin Multiplatform is the same thing). It is also subject to the quirks and specifics of JVM implementations, build-systems and package management. Kotlin native partially bypasses this, but its performance is a factor of 0.1-0.01x vs OpenJDK (if there is new data - please let me know). This is very unlike NativeAOT which is on average within 90% of CoreCLR JIT but is also a performance improvement in variety of scenarios.

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.

    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}

> {my favourite package}

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.

    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);

    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]);
            }
        }
    }

> NET Multi-platform App UI (.NET MAUI) apps can be written for the following platforms:

> - 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.

For historical context: this was before the conclusion of the antitrust case that led Microsoft to start softening its stance toward open source. https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....

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.

Mono implemented the GUI stuff like Windows Forms, do the latest windows cross platform stuff support that? Can you run .Net GUI windows program on linux without Mono but using the latest .Net thing ? I know it was not possible in the past.

Is .NET open-source? Will I find it in an open-source repository?

Is there a way to build a GUI app with .NET on Linux?

Will it be cross-platform?

> 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.

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

This uses Win32 API. I will post numbers in a bit. .NET interop overhead in this scenario usually comes at 0.3-2ns (i.e. single CPU cycle which it takes to retire call and branch instructions) depending on the presence or absence of GC frame transition, which library loader was chosen and dynamic vs static linking (albeit with JIT and dynamic linking the static address can be baked into codegen once the code reaches Tier 1 compilation). 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.

It's a fork with a lot of modifications (mostly removing deprecated stuff and making it cross-platform). You can still see a lot of ancient stuff in the sources such as referring to the base Object class as "COM+ object" (.NET was originally envisioned as a successor to COM).

>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...

Correct, the bytecode wasn't even 1:1 compatible. They then brought over missing pieces, and consolidated .NET Framework features into .NET Core, thus becoming just .NET to end the dumb naming war, since everyone calls it .NET anyway...

If true this would be huge. I got burned on the whole silverlight, Universal Windows Platform, WPF etc. All these new and improved solutions had all sorts of issues, no designer, no or weaker accessibility stories, bloated, slow etc etc. C# + Winforms would be appealing. Some of the performance with larger datasets in the new solutions (tables etc) was just surprising. I really feel like Microsoft got so distracted chasing phones, tables, touch etc they forget just basic line of business application development which they could and should have owned.

I had to check; you're right, no official support for Linux. Windows, macOS, iOS, Android. You can kludge Linux in with hacks.

After having gouged Red Hat and Suse for years with their bogus Linux patent racket and bankrolling the infamous SCO Unix lawsuit. Make no mistake M$ coming over all We Love Linux was like Donald Trump turning up at the DNC.

.Net Core on Windows has support for loading assemblies that reference COM interfaces and the win32 API, along with other things that aren’t supported elsewhere like C++/CLI.

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).

Kind of suspected people might actually be doing that. “You may live to see man-made horrors beyond your comprehension.”

More or less. any version of .NET >= 5 is cross-platform and is a direct descendant of the "Core" side of the fork, and so has no "full framework, windows only" variant.

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.

That's correct

The first Macs to use Intel processors were released in January 2006

Microsoft Azure was first released on February 1, 2010

Microsoft released .NET Core 1.0 on June 27, 2016

Well, to be fair .NET Standard wasn't a framework, it was a standards/compatibility label and compilation target.

.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.

Yes, .net is for azure cloud webapps, that's how modern software is made. Then wrap them in electron to make them native.

No it's way better than Flutter. Avalonia really works on desktop.. :). Also the model is WPF so whoever know a little bit of legacy .NET framework will be able to write Avalonia apps in no-time

Then you're not talking about what I was talking about in the post you replied to with a framing that suggested you were disagreeing. Did you click the wrong reply link?

Absolutely!

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

I use buzz merely as a proxy for community size, support, etc. Will have to try them out as you said to really know.

Copilot is just Clippy II+.

Branding be branding, yo.

It sounds like .NET is on the way toward becoming the Java competitor it set out to be.

This was probably copying Sun's "we put the dot in .COM" advertising. Yes, this is stupid.

No, Microsoft's .NET only supports WinForms on Windows. They do have an official cross platform GUI toolkit in MAUI, but it strangely does not support Linux.

For this, having wine in charge makes sense - though, as with many things wine you could be waiting a while.

I've had pretty good success running WinForms apps in wine, and just straight up installing latest version of dotnet in wine.

Works better in proton from my experience though, but I think that is due to making unity games run better

With commercial applications that want to just take their existing code and have it run on Linux with only a couple lines changed, Avalonia XPF will do that

Because X's mean moar marketing power... Like the Extreme X870E X motherboard... There's multiple X's and Extremes and the X's mean extreme... so it's moar extreme!!!

I don't think it's very productive to contribute to projects that are the victim of strategic sabotage.

Oh yeah I agree lack of Linux support is a major issue. Just even without it there are so many other issues I dunno that Linux support helps much.