Mono 5.0 Ships with Concurrent Garbage Collector
mono-project.com
mono-project.com
Pauses over 16ms are very noticeable on your phone’s 60 Hz display; it will cause dropped frames. So according to the graph, the large majority of pauses will still cause dropped frames.
"Even if those numbers are a significant quality of life improvement, there’s plenty of work left for us to get to no visible delays due to the garbage collector. We have already a solid pipeline of improvements coming on our next releases."
confirm this via experiment?
The code thread might hang, it scheduled rendering and animations will continue.
There are scenarios not covered by this hack, but largely these systems are responsible for masking many issues- in this case GC introduced pauses, but can happen in things as common as close()
Is the sole purpose of Mono now is to run .NET on mobile?
It's actually a pretty nifty API to use, and has some continuation as MonoGame. Notably, Stardew Valley is an XNA/Monogame product.
Window Phone 8 redesign was a consequence of WinDev, led by Synofsky winning their usual disputes against DevTools.
Nowadays they even support MonoGame on XBox and already apologized the process didn't went out as it should have been in first place.
EDIT:
Here they welcome MonoGame into XBox program
http://news.xbox.com/2016/03/14/letter-chris-charla-idxbox-u...
And here Unity is listed as one of the official Windows 10 game middleware
And does support AOT compilation to native code, while the work in CoreRT is currently on hold, until the .NET Standard 2.0 gets finished.
There was some talk about CoreRT and July but i forget where that news came from.
Mono actually works, today. It's hype is not ~5 years ahead of an actual implementation. It's not continuously waiting for one more generation of tooling to settle down, or one more standard to be decided or API to be implemented. Its "Getting Started" examples actually compile and run, consistently.
There are two types of languages/frameworks... the ones that people are excited about, and the ones people currently use. Mono's purpose is to serve the latter.
I really jumped on board the train back when Microsoft's sudden openness made them the #1 topic on HN for awhile, and C# suddenly found new life as a cool fad language.
I tried out .NET Core on all three platforms, started reading C# books, and even listened to the weekly "Community Standup" video podcast to be updated on the implementation's progress. I believe certifications are a bit of joke, but I was even thinking about pursuing a MCSD so that I might shift my career more from Java to C# with my next job change.
I had realistic expectations about .NET Core's implementation in the early going, as it was Beta and rapidly changing. But I grew disillusioned as it went to RC and and even RTM, and was obviously still at the alpha stage in reality. Completely changing the build toolset post-launch? Seriously? And everything is branded with a different name every time I turn around?
The documentation and community was never on the same page with the current status of the implementation. I could just never get even Microsoft's own basic examples to reliably build and run. Perhaps the "Hello world" console example, but not anything beyond that. I would put it down, and every 3 to 6 month pick it back up again to see if I could get the ASP.NET Core example to run. Sometimes I could, sometimes I couldn't. And it was always one or two more API's (e.g. Entity Framework) away from being ready for real professional use.
For awhile I was checking in every 3 months, and then every 6 months, and at this point I think I'm on an annual schedule. And currently I'm no longer seriously considering a career switch.
I don't mean to be too harsh on the PEOPLE behind .NET Core, as they seem to be smart, good people striving to re-invent a platform and extend its lifespan by decades. But I think that some realism is sinking in now that the initial hype wave has subsided. Re-implementing even a usable subset of a platform as large as .NET was always going to take WAY longer than people were originally supposing.
.Net core has not stood still in the last 6 months - the VS2017 release was a big milestone.
In the next six months we expect NetStandard 2.0 and .Net core 2.0
Money? Hedging it to be the future? Like the tech/languages/tools better?
I just had a bit of "grass is always greener on the other side" envy of our Microsoft team. They were in a bit more sexy position in terms of management focus, their tech stack seemed intriguing, and the more I tinkered with C# the more I liked it. It seemed like everything I loved about Java, with extra features and syntactic sugar over the parts that I didn't like.
.NET Core, and the idea of shipping your app with a self-contained runtime only megabytes in size, sounded amazing compared to the 300 MB Docker images we were building for our Java stuff. Everything about the Microsoft/C# team felt next-gen compared to the Google/Java team. I even bought a Windows Phone, and starting doing most of my web searches with Bing.
Since then, the Office 365 project got shelved, and most of that team is gone.
Microsoft is doing some interesting things to try and catch up with modern trends. But much of it is still smoke-and-mirrors at this point. The cold reality is that underneath all the "cloud" marketing, Microsoft's customer base is very much conservative enterprises and not-so-savvy SMB's. Customers are fine with Microsoft throwing in the cloud offerings as add-ons for the on-prem stuff... but the customer DNA still very much revolves around running on-prem software, one or two (or more) generations behind the current release. There just wasn't a thriving market for partners in the pure-cloud space.
A lot of my career has been like that. My perceptions driven by what's happening with my current employer, without having a clear view of where the overall industry is heading. It's really 50% luck that I'm a well-paid senior Java developer today... because there were SEVERAL points along the way when I was tempted by what a past employer was doing with Delphi, or Ruby, or something else that in retrospect would have been a major career detour or setback.
Next time I'm in Atlanta I would love to meet in person (btw thank you for putting your real live info online. I love learning about new people) and grab some beers (or whatever).
I went to GaTech and my company is technically based in ATL albeit we are virtual. email is whatever @ snaphop dot com
No idea how C# + .NET Core fits into this equation of pain.
The documentation and website material wasn't keeping pace with the actual implementation. Which for a full reference guide is one thing, but for the "Getting Started" hello world example on your main marketing page is another thing altogether.
I've spent more time than enough trying to find what package functionality moved to
You absolutely can build something complete using the framework. You just have to put in work to resolve these issues.
Microsoft has come across as uncommitted for many years now. Their guidance has been a recipe for pain. The path to success on their platform is to stick to the mainline.
It's not hype, it's real and it works.
Funny, because "it just works" has never been the case for the entire existence of Mono. Always a little behind, always all kinds of obscure bugs and unfinished implementations, etc. Even the commercial Xamarin offerings suffered from those.
Had a Gentoo server that needed a Perl application to fetch data from a MS SQL Server.
FreeTDS just would not compile, but Mono installed just fine.
I wrote Inline::MonoCS [0] and everything Just Worked.
[0] http://search.cpan.org/~johnd/Inline-MonoCS-1.000/lib/Inline...
Should tip you off.
Also, I run multiple website with databases, gb of record processing in queues etc. Also I'm building CI runner on .NET core and so far I've got 0 problems. so I would not call it "hello world".
I have 99 problems but .NET Core ain't one.
I don't believe it. If you haven't had problems with .NET Core, you haven't used it in a serious capacity.
I'm not even going to bother to go into the details; anyone is free to look up the issue list and the endless stream of issues, its all on github. The versioning, the nuget support, the package.json stuff, the huge fuss over targeting netcoreapp for the 2.0 preview...
.NET Core is the future, but its not here yet.
Its the closest its ever been with the new preview release, but honestly, I'm deeply sympathetic to other early adopters. Migrating to .net standard 2 will be painful.
Anyone thinking of using core right now: dont.
Wait at least for the 2.0 release version to roll out, or you're building on quicksand.
My only real problems have been using the new libraries (EFCore, aspnet core) and finding compatible libs. Documentation is a bit of a pain due to all the earlier changes that are fossilized in blog posts.
Other than that, it's been pretty smooth. Dev and test on VS/Win, deploy to Linux.
Though I've also done the same with Mono and it's been pretty good. Mono starts a lot faster - I don't get why "dotnet X" takes 5 seconds no matter what X is.
Fwiw I'm excited about Rust and use that too, and even have a few in-the-wild users of my Rust open source stuff. So I think the line about excited about vs actually use is nonsense used to justify shitty design decisions ala C++ or Go.
Every single example in the .NET Core documentation compiles and runs, please stop spreading FUD.
Version 1.2 with the release of VS 2017 now has all the appropriate tooling to make everything work well. The whole project is less than 2 years old and by the end of the year we'll have .NET Standard 2.0 with most of the APIs back, almost full compatibility and even better tooling.
I appreciate the effort in .Net Core, I think the info-marketing side could use some attention and with 2.0 some redress to the CTO types... for now, despite some adoption, it's not exactly proven out.
I will say that for a few of my early tests, it does about 60% more work than the node based app I ran against... though that was still more effort than I liked, and took a bit longer to write than the node version, either of which frankly exceeded the throughput requirements and could scale horizontally.
I'm looking forward to seeing what comes of things... I miss a lot of the integrations that C# + VS offered, but don't miss the lag that is so present in my mind even today regarding working in VS. I do love VS Code though, and haven't tried VS2017 so can't comment.
You've run every single example in the .NET Core documentation? Or you like opining about things you have no experience with?
Have you? Do you have an example of something that doesn't? Or are you talking about something you have no experience with?
mono is like a linux distro , .net core is like a linux kernel
for why i think my analogy still make sense
It is a process, and is generally going great. The challenge is tha Mono needs to ensure the larger API surface and to avoid regressions on existing behaviors and in some cases we have different substrates that are not identical.
I posted a link above with the plan that we have. But Github is a better source of information, you can see there all the shared code in the .sources files in the Mono/mcs/class directories
The class library implementations are converging (1) and some other bits are shared.
Historically Mono has supported the "desktop" profile style of APIs, so it continues to support that model. We rely on that model and the APIs that come with it for Visual Studio for Mac.
(1) http://www.mono-project.com/news/2016/11/29/mono-code-sharin...
Basically it's not obvious to me if this GC improvement widens Mono's lead over .net GC performance, brings Mono close to matching .net's lead, or brings Mono from terrible to merely bad in comparison to .net.