Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft donates the Mono Project to the Wine team

mono-project.com

Post reply on HN
Print view View original

221–230 of 509 posts

Re: Microsoft donates the Mono Project to the Wine team

#221

Post by runevault »

moomin wrote: post #206
runevault wrote: post #142

Earlier quoted context omitted.

Last I knew it is also considered pretty lackluster. Every time I read up on it it feels like, even beyond the lack of Linux support people just don't care for it. If I was building a cross platform native app with .NET I'd probably use Avalonia right now.

Yeah, the took an age delivering it, then it came out and most of the early reports were “It’s still not ready.” and then I think Microsoft just gave up. 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.

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.

Re: Microsoft donates the Mono Project to the Wine team

#222

Post by minkles »

commercialnix wrote: post #151
minkles wrote: post #52

Earlier quoted context omitted.

Oh wow so you write fancy crud apps on the web? I've already got 300 people who can do that in C# (.net core) already. Why do I need any Rust people? What I need is people who can write very complex rule and constraint engines, mathematicians and statisticians to deliver some business value, not crud monkeys.

> I've already got 300 people [..] Given the style of writing and argumentation you have prevented here, no one with leadership experience in the software industry is going to actually believe you. Maybe they're lateral to you. And, even then, arguing quantity of engineers over quality of engineers is a pretty bad argument, especially on this site. So, yeah.

I think you should look into a mirror and think hard.

Re: Microsoft donates the Mono Project to the Wine team

#223

Post by 486sx33 »

paranoidrobot wrote: post #208
aspeckt112 wrote: post #203

Earlier quoted context omitted.

Good write up that wonderfully encapsulates how stupid Microsoft’s naming is - you didn’t even mention .NET standard. 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.

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.

But….net is everything! And also nothing ! It’s a product? It’s a suite! It’s a system !

Visual Basic .net ! What ?

Re: Microsoft donates the Mono Project to the Wine team

#224

Post by Mogzol »

kragen wrote: post #205
MarkSweep wrote: post #204

Earlier quoted context omitted.

.NET Core is available for Debian, you just have to add Microsoft's APT source [1]. 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/…

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

I doubt it is due to legal concerns if Ubuntu, Fedora, and FreeBSD are all distributing their own builds.

Re: Microsoft donates the Mono Project to the Wine team

#225

Post by neonsunset »

kragen wrote: post #182
runevault wrote: post #144

Earlier quoted context omitted.

c# has the concept of value types (which structs are), which are stack allocated. Generics have seen more and more instance of getting a Value type like Value Task for stack allocated async objects. But if you add a class as a member of the struct that is going straight to the heap with all the GC stuff that entails

what about global or static variables of value types? i mean in theory you could stack-allocate whatever you want in your main() method and pass pointers to everything, but that sounds unusably clumsy. but with global variables and/or class variables there would be no problem except for things that inherently require heap allocation by the nature of the problem

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.

Re: Microsoft donates the Mono Project to the Wine team

#226

Post by deaddodo »

Kwpolska wrote: post #189
deaddodo wrote: post #72

Earlier quoted context omitted.

.net Core doesn't supply WinForms, but WPF is the far more common paradigm for Windows apps now. WPF is supported by projects like Avalonia on Linux. There are also a few other major alternative UI toolkits, more commonly used by cross-platform (vs Windows-exclusive) developers.

.NET Core does support Windows Forms just fine, but it’s only available on Windows.

[flagged]

Re: Microsoft donates the Mono Project to the Wine team

#227

Post by Rochus »

neonsunset wrote: post #219
Rochus wrote: post #214

Earlier quoted context omitted.

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?

I'm simply trying to caution against openly bad advice. People here are likely to run C# and F#, not Oberon+ that compiles to (terrible) CIL.

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

Re: Microsoft donates the Mono Project to the Wine team

#228

Post by MarkSweep »

kragen wrote: post #205
MarkSweep wrote: post #204

Earlier quoted context omitted.

.NET Core is available for Debian, you just have to add Microsoft's APT source [1]. 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/…

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

I found someone requesting that it be added to Debian:

https://bugs.debian.org/cgi-bin/%3Ca%20href=%22bugreport.cgi...

So far no one has mentioned licensing being an issue.

Re: Microsoft donates the Mono Project to the Wine team

#229

Post by neonsunset »

runevault wrote: post #221
moomin wrote: post #206

Earlier quoted context omitted.

Yeah, the took an age delivering it, then it came out and most of the early reports were “It’s still not ready.” and then I think Microsoft just gave up. 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.

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.

Does it really need help? I struggle to imagine a scenario where one would consider MAUI not supporting Linux to be an issue (if we discard superficial bad faith concern) when Avalonia, Uno or, if you care about Linux as the main target, Gir.Core exist.

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.

Re: Microsoft donates the Mono Project to the Wine team

#230

Post by neonsunset »

Rochus wrote: post #227
neonsunset wrote: post #219

Earlier quoted context omitted.

I'm simply trying to caution against openly bad advice. People here are likely to run C# and F#, not Oberon+ that compiles to (terrible) CIL.

> 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 smal…

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

Post reply on HN