Live data from Hacker News

Announcing .NET Core 2.0

blogs.msdn.microsoft.com

131–140 of 145 posts

Re: Announcing .NET Core 2.0

#131
post #105

Earlier quoted context omitted.

There is no CLR on UWP, everything is AOT compiled to native code, excluding JavaScript. VB and C# make use of .NET Native and C++/CX are just a few C++ extensions that look like C++/CLI but compile to native code as always. One can also use standard C++ with WRL or C++/WinRT libraries. .NET Native shares the compiler backend with Visual C++. The issue is that the .NET Native compiler team doesn't care about supporti…

I once had to really compile one of my UWP apps to get it working on a locked down Surface Hub (otherwise, I just ever ran them in the debugger). My freaking god, it took 45 minutes to compile a small app...no way...they threw out everything that was good about the CLR for AOT that allowed them to what...run on embedded devices? It's really too bad, Win2D was quite nice.

Performance.

Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL).

UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together.

COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine.

C++ is still there for the kernel, device drivers, audio and graphical critical performance components like DirectX.

Everything else can enjoy the productivity of .NET languages and respective tooling.

Which meant that any of my WP 8.x and 10 devices run considerably faster than Android devices of similar price range, while having less overall memory requirements.

Re: Announcing .NET Core 2.0

#132
post #131

Earlier quoted context omitted.

I once had to really compile one of my UWP apps to get it working on a locked down Surface Hub (otherwise, I just ever ran them in the debugger). My freaking god, it took 45 minutes to compile a small app...no way...they threw out everything that was good about the CLR for AOT that allowed them to what...run on embedded devices? It's really too bad, Win2D was quite nice.

Performance. Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL). UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together. COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine. C++ is still there for the kernel, device drivers, audio and graph…

I get it: a UWP app might be noticeably faster with AOT vs. the standard CLR JIT, but for a UI program that isn't crunching numbers, you are unlikely to tell the difference. Also, the CLR, like the JVM, is no slouch when it comes to running things. As such, there is always a huge asterisk attached to AOT claiming it might improve performance, but it could also degrade it, it is hardly an obvious win. The way it was explained to me was that AOT is necessary for UWP to support IoT and lower end hardware, that on full computers you probably won't notice.

Also, look at all we gave up for AOT. Dynamic compilation in the DLR was pretty nice...and it was reduced to an interpreter in UWP because....no JIT. Granted, I was probably the only person to notice because no one else probably thought to cross the two.

The problem with Microsoft is that as soon as they move to the next thing, they basically abondon the previous one without having the next thing truly replace the previous one. So here comes UWP, meant for "different" things, but it gets all the new stuff while WPF is basically dead. Ya, want to use those new APIs? Sorry, you'll need to use UWP even if you have no intention of running on low end android devices.

So much good stuff, but you have to make a Faustian bargain to use them.

Re: Announcing .NET Core 2.0

#133
post #131

Earlier quoted context omitted.

Performance. Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL). UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together. COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine. C++ is still there for the kernel, device drivers, audio and graph…

I get it: a UWP app might be noticeably faster with AOT vs. the standard CLR JIT, but for a UI program that isn't crunching numbers, you are unlikely to tell the difference. Also, the CLR, like the JVM, is no slouch when it comes to running things. As such, there is always a huge asterisk attached to AOT claiming it might improve performance, but it could also degrade it, it is hardly an obvious win. The way it was e…

Yeah F# is a good example.

Two years after UWP was introduced still no roadmap in sight for .NET Native support, Visual Studio 15.3 just shipped with the F# team telling people to use VS Code instead.

I bet it will be joining Silverlight in a couple of years.

However Microsoft is not alone in these kind of decisions. I can think of a few similar ones from Apple, Google, IBM, HP, Oracle, Sun,....

Re: Announcing .NET Core 2.0

#134
post #108

Earlier quoted context omitted.

I have VS Code with a dozen plugins running, and using about 1GB two editor windows, each with a few tabs open, as well as the terminal (best point of integration imho) in each. Spotify seems to be using a bit under 200MB. For comparison, libre-office with a 60-row spreadsheet open is using 145MB. Frankly, it's not that bad... I've got 16GB on my laptop (thanks apple), and 32gb on my home desktop, though may go threa…

Many of us still have 8GB systems or even plain 4GB.

Well, Code and the browser are my main two applications... the rest take up very little by comparison. But, you're right, I wouldn't want to rely on a dozen electron based apps being loaded. That doesn't mean it isn't a good option for a lot of things.

Re: Announcing .NET Core 2.0

#135
post #133

Earlier quoted context omitted.

I get it: a UWP app might be noticeably faster with AOT vs. the standard CLR JIT, but for a UI program that isn't crunching numbers, you are unlikely to tell the difference. Also, the CLR, like the JVM, is no slouch when it comes to running things. As such, there is always a huge asterisk attached to AOT claiming it might improve performance, but it could also degrade it, it is hardly an obvious win. The way it was e…

Yeah F# is a good example. Two years after UWP was introduced still no roadmap in sight for .NET Native support, Visual Studio 15.3 just shipped with the F# team telling people to use VS Code instead. I bet it will be joining Silverlight in a couple of years. However Microsoft is not alone in these kind of decisions. I can think of a few similar ones from Apple, Google, IBM, HP, Oracle, Sun,....

Ya, I wouldn't single out MS as particularly bad here, but they used to be much better about this than the other companies. Now they are reaching down to parity, and developer support used to be their greatest strength.

Re: Announcing .NET Core 2.0

#136

Earlier quoted context omitted.

Couldn’t agree more. I’ve been using .Net Core 1.1 daily for the last couple of months building out a reasonably large Web API for a game. The platform, tools and C# as a language are a pleasure to work with on both my Mac and Windows machines (small caveat on VS for Mac, it’s still a bit lumpy) I’ve been using Unity for about 8 years and I’m finally confident building a backend using .Net and basking in the joy of i…

> building out a reasonably large Web API for a game. How are you hosting this? Can you share any experience? I built a Web API using .Net 4.6.1 and when it came time to host it, Azure DB, Azure Web App became quickly super expensive. I'd be curious to know if you've find a cost-effective hosting solution for hosting .Net Core APIs in a Production-like environment for a SaaS website (which is what I'm building on the…

I'm not OP but maybe I can chime in. My employer runs a fairly large application platform on Azure and I've used Azure for personal projects a few times.

Let me start off that you can host (ASP).NET Core projects just about anywhere, so using AWS is definitely a possibility. I myself use basic Azure functionality though. Here's what I do when costs are the limiting factor:

For storage, Azure used to provide a small (20MB) db instance for free in their 'free tier', but that doesn't seem to be available anymore.

As an alternative you should consider using Azure Table Storage instead of Azure DB.

While Azure DB offers a fully-functional SQL server instance, it will cost at least $5 per month to use on a basic plan. Using Table Storage (Azure's 'NoSQL' solution), on the other hand, is way cheaper. For a fairly small application with less than a hundred users my average monthly bill is $0.00. Even if it scales to a hundred thousands users (while it isn't really built for that) the costs for using Table Storage would probably still be less than a dollar per month.

Alternatively, you could use SQL Server Compact. This should be possible on Azure but I would not recommend going this route though.

As for hosting, my personal apps almost exclusively make use of the Free tier for App Services. For what my apps are doing this turns out to be efficient enough. If that's not enough, a simple Shared hosting environment is also pretty cheap at less than $10 per month.

It only gets expensive if you really need dedicated VMs running for you but even then $50 per month for a dedicated machine shouldn't break the bank if your SaaS business is actually going somewhere, plus scaling it up or out is dead simple. On average I spend more time per month babysitting the single VM I have with RackSpace where I run old (non-azure) webapps than our entire team spends managing our azure environments (DTAP) with hundreds of apps and databases.

Re: Announcing .NET Core 2.0

#137

For those of you who are using VSTS: CI/CD or VSTS: Build please note that we're still updating our hosted build image but that should be done in the next few days. We'll also be sure to update the docs here with the list of what is supported: https://www.visualstudio.com/en-us/docs/build/concepts/agent...

I just realized that Hosted VS2017 is still using Visual Studio 2017 (15.1 Update). That's two versions behind now. When is it going to get the 15.3 update?

Re: Announcing .NET Core 2.0

#138
post #126

Earlier quoted context omitted.

Fully agree with you regarding that prominent member. Of course he doesn't care about UWP support, as he wants to promote his own VSCode plugin.

Also sad to see those members who liked his tweets.

We can forget about UWP support, it isn't going to happen in the near future, who knows if it ever will.

"The F# team is currently focused on .NET Core tooling in Visual Studio and further support for .NET Core as it evolves. There is no ETA for .NET Native/UWP support at this time."

-- Phillip Carter [MSFT]

https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...

Better focus on C# and C++ and call it a day.

Re: Announcing .NET Core 2.0

#139
post #136

Earlier quoted context omitted.

> building out a reasonably large Web API for a game. How are you hosting this? Can you share any experience? I built a Web API using .Net 4.6.1 and when it came time to host it, Azure DB, Azure Web App became quickly super expensive. I'd be curious to know if you've find a cost-effective hosting solution for hosting .Net Core APIs in a Production-like environment for a SaaS website (which is what I'm building on the…

I'm not OP but maybe I can chime in. My employer runs a fairly large application platform on Azure and I've used Azure for personal projects a few times. Let me start off that you can host (ASP).NET Core projects just about anywhere, so using AWS is definitely a possibility. I myself use basic Azure functionality though. Here's what I do when costs are the limiting factor: For storage, Azure used to provide a small (…

Thanks. Very useful info.

Re: Announcing .NET Core 2.0

#140
post #138

Earlier quoted context omitted.

Also sad to see those members who liked his tweets.

We can forget about UWP support, it isn't going to happen in the near future, who knows if it ever will. "The F# team is currently focused on .NET Core tooling in Visual Studio and further support for .NET Core as it evolves. There is no ETA for .NET Native/UWP support at this time." -- Phillip Carter [MSFT] https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net... Better focus on C# and C++ and call it a day.

I really can't stand C#. F# is what drove me to .NET in the first place.

And I don't like going back to C++, is there any GUI/XAML tooling for it? If not, I'd rather use something like Rust.

Post reply on HN