“Long GC latency can cause typing delays that are noticeable and lead to a bad typing experience. Pauses over 100-150ms are noticeable by most of us”
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.
Android and iOS both use separate rendering processes/threads for UI and animation to eliminate a range of issues that would otherwise be observable.
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()
A separate execution environment for animation can help, but usually not for cases where your GC'd code needs to change the rendering in response to user input. A good example which falls down often is scrolling.
Years ago a guy that worked on input devices said if the latency gets over 10ms 12 year old gamers start throwing things. I'm assuming that's because they can tell the button press slipped into the next frame.
"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."
Confirmed via experience of game and app devs everywhere for decades. It causes a discontinuity. Your eyes and brain have a lot of hardware specifically dedicated to detecting those.
It's purpose is for people who need to do professional cross-platform .NET work, today. As opposed to tinkering with hello-world examples, and keeping an eye on what might be the big thing down the road.
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.
>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.
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.
This is an exaggeration. We sell and ship a complex, commercial product built with .NET Core. Our (small) team has had some frustrations as things changed along the way, but it has hardly been a dramatic, nail-biting, disaster-ridden fiasco. We are very happy with the project and its rate of progress.
Personally I had much more problems with mono 1 year ago then .NET core today.
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 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.
I've got 2 projects working on .Net Core, and one about to go live next week. The tooling in VS2017 makes it even better.
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.
I think this is a little harsh on .net core - it is not as feature complete as mono yet, the point you are making is correct, but it's still usable right now, with some allowances and restrictions.
Unless it's come a LONG way in just the last 6 months, I don't think I'm being too harsh.
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.
I work for a company that does a lot in the SaaS backoffice space (e.g. Google Apps), and at the time we were launching a whole new product around Office 365.
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.
Steve thank you so much for your detailed answer to my queries of pure curiosity!
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
In my experience (from an end-user standpoint; I don't have much experience on the programming side of this particular front), C# w/ Mono is far less painful than that other "compile-once-run-everywhere" C-resembling VM-driven language.
No idea how C# + .NET Core fits into this equation of pain.
No, I'm saying that I would follow the then-current instructions for building a hello world ASP.NET app... and half the time those instructions simply weren't working even for a completely clean from-scratch environment.
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 can't say I have had issues when following the instructions on the MS site, but I did go down a rabbit hole trying to work with the Entity Framework tools, ultimately finding that they were not supported by the LTS release. There are a lot of outdated tutorials out there. Many of the new ones still don't acknowledge a DotNet Core version so it's something of a crapshoot. Libraries are often incompatible with the version you installed.
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.
.NET Core is not hype, it actually works, today. We have several services doing billions of requests daily on .NET Core while being faster to build, deploy and run than the Windows + full framework combination.
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 really like C#, and have loosely followed .Net Core, dipping my toes in several weeks ago... definitely better than in the past, I think VS2017 adoption can improve things... but it's far from without warts. 2.0 will take care of many of them, but even recently there's been some kerfuffles...
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.
Mono is focused on supporting mobile workloads while .NET core is focused on the server side.
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.
This is false, Xamarin is focused on mobile. Mono has been focused on other use cases since it has existed. We successfully built Event Store on Mono and ported it to .NET and have hit surprisingly few issues. On .NET Core, our six separate attempts to port have not yet yielded anything usable.
It was my impression that CoreRT work was put on the back burner ( not on hold ) so the team was able to focus on Core 2.0 release. Theoretically the team can move more resources to CoreRT as Core 2.0 is now in preview.
There was some talk about CoreRT and July but i forget where that news came from.
targets more platforms.
don't have to figure out the insane mess that is .net core cs
net framework. just do toyr regular c# or f# code and compile it wherever.
The just bumped to a new version in the newest betas. After Microsoft bought Xamarin those licensing issues appear to have gone, which makes sense given MS's strategy.
They working on a Unreal Engine implementation too. I really can't wait for that. It sounds like they in the final stages however, it has been there for a few months.
We are now sharing code between the two stacks. This means that we get to share bug fixes, implementations and performance improvements.
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
another development is the Mono now supports System.Nunerics which means it has the same SIMD support as tegular .NET, and a few more SIMD intrinsics are coming to System.Nunerics soon as well. it will be usable quite a bit more often when those drop.
The ideal comparison would be to run the exact same experiment on the exact same hardware on .net and see how it compares (ie, run Xamarin Studio on .net, open and build Xamarin Studio). But I would be interested in any quantitative comparison of Mono and .NET GC performance.
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.
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.
reply