Live data from Hacker News

Announcing .NET Core 2.0

blogs.msdn.microsoft.com

91–100 of 145 posts

Re: Announcing .NET Core 2.0

#91

Earlier quoted context omitted.

Microsoft's own .NET Native runtime is simply not .NET compliant https://news.ycombinator.com/item?id=15007166 This is unacceptable and should be fixed ASAP. F# is a mature language existing for more than a decade, there is simply no excuse to let this slide.

Microsoft had to fix the C# compiler. The result was Roslyn. It's actually amazing that Roslyn was a successful project. Probably most software projects that ambitious fail. The project would have failed if they tried to make it F# compliant at the same time. Speaking as someone who makes his living writing F# code, I'm as frustrated as anyone about this, but there will be a successful resolution. I just don't know h…

If it's going to be fixed this year, then why isn't it even on the official road map? https://github.com/Microsoft/visualfsharp/issues/2400

Re: Announcing .NET Core 2.0

#92
post #18

I wish I had a better sense of where cross-platform desktop app platforms stood these days: Electron, Java, .NET, QT. All I hear are "Eww, Electron is ridiculous, slow, heavy Web junk for desktop", "Eww Java is blub, insecure, and half-abandoned by Oracle", "Eww, .NET is Microsoft and unreliable for anything serious on non-MS OSes", "Eww, by the time you pay the license, learn QT, learn the odd variant of C++, and ma…

The first things you should do is identify what it is you're trying to create, what your skills are, and what your options are. Also, what platforms you need to support.

The more platforms you need to support with the fewer people, then the more web-based options may appeal to you. Electron works well enough for a lot of applications, and gives you the big three desktop environments. Judicious use of Cordova gets you the two big mobile options. It won't run as buttery smooth as native, and is very easy to let bloat if you don't keep on top of your dependencies.

Java is a bit less liked for desktop applications, mainly because they tend to look clunky, or are otherwise requiring a larger runtime as a prerequisite.

.Net has similar issues. For desktop applications the Xamarin tooling, now in the box, is a decent option, but you will get a few headaches. While I personally prefer C# as a language to Java, the latter is definitely got a bigger community.

QT, etc, are non-starter if you also need a mobile platform.

In the end it really depends on what you need to accomplish and what skills/tools are brought to the table. I'd lean towards using Electron/Cordova for any proof of concept just because it's easy to move fast on that side. I also happen to like Node a lot. You may also want to consider ReactNative as a first or second pass depending on your targets, again.

Re: Announcing .NET Core 2.0

#93
post #63

Earlier quoted context omitted.

For the desktop, electron has mostly won really, the web browser becoming the primary most widely used platform for delivering applications made shipping a desktop application with an embedded browser the next obvious choice.

Electron means you need 2GB of memory for a simple chat app like Slack to talk about the application you're building in a fully featured all bells and whistles included application like Visual Studio that only takes 700MB of your memory. Compare what Visual Studio + ReSharper does versus what Slack does. I have no idea what 70% of the features in Visual Studio do yet I'm using it professionally for years and years, t…

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 threadripper at the end of the year with 64-128gb. It's there to be used.

VS Code is much more responsive than Visual Studio... and the plugins and integration are great. Integrated terminal, and the git integration are nice, though I wish they'd get closer to full 3-way merge support.

Re: Announcing .NET Core 2.0

#94

Earlier quoted context omitted.

I see Electron as an example of the "Worse is Better" theme.

No, usability matters. I've removed the Slack app because it's way too sluggish, just use the website when I want to check it. I've tried Atom but it felt just not right, mainly because it lacked a certain snappyness - so I'm back to Sublime. Sure when the users don't have any alternative they might bear with it, but a major selling point of a native app is that it feels right.

Agreed on the slack app... but I've been using VS Code very happily, especially since the integrated terminal was added, which is a feature I've wanted in my editor for a very long time... The terminal was pretty sluggish on some things at first, but works well... still not much of a fan of hyperterm, which shares the same terminal integration modules.

Most of the electron apps I've used I don't use much... except vs code, and for what interactions I have they aren't bad. However, most of my time is in one of several browser tabs, vs code, and a terminal window. I keep Goofy (fb mobile as electron app), and Spotify (electron iirc) open... that's about it.

Re: Announcing .NET Core 2.0

#95
post #64

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 does it handle a lot of users hammering at the API at the same time?

For the most part there are similar caveats to .Net as anything else... you want to remain as stateless as possible at the request level, and you want to avoid blocking on IO as much as possible. There are async versions of most things, and you just have to use them... It's easy to do things that will sink you.

.Net and .Net Core can do API services very well, and can scale very well. It doesn't mean you can't still shoot yourself in the foot easily.

Re: Announcing .NET Core 2.0

#96
post #15

I have been absolutely loving .NET Core since I started using it this spring. Currently running two applications in production, one on a Windows Server with IIS and another on a Centos 6 server with Docker. Docker was surprisingly easier than configuring Web Deploy to IIS. There have been a few things that are oddly documented, but generally documentation has improved over these months as user base has grown. They ha…

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

Re: Announcing .NET Core 2.0

#97

Earlier quoted context omitted.

Microsoft had to fix the C# compiler. The result was Roslyn. It's actually amazing that Roslyn was a successful project. Probably most software projects that ambitious fail. The project would have failed if they tried to make it F# compliant at the same time. Speaking as someone who makes his living writing F# code, I'm as frustrated as anyone about this, but there will be a successful resolution. I just don't know h…

If it's going to be fixed this year, then why isn't it even on the official road map? https://github.com/Microsoft/visualfsharp/issues/2400

You're absolutely correct about .NET native not being .NET compliant...sigh...there are just higher priorities for such a big company. As quoted in the comments " [F# native support] depends on the Core CLR team improving support for a couple of big items. dotnet native is and AOT compilation are absolutely a goal for us ... they just are longer term than this roadmap anticipates."

It's actually eye-opening how few the number of people at MS who actually write code is. I suppose if there were more coders they would be stepping all over each other and never get anything done.

Re: Announcing .NET Core 2.0

#98

Earlier quoted context omitted.

Microsoft had to fix the C# compiler. The result was Roslyn. It's actually amazing that Roslyn was a successful project. Probably most software projects that ambitious fail. The project would have failed if they tried to make it F# compliant at the same time. Speaking as someone who makes his living writing F# code, I'm as frustrated as anyone about this, but there will be a successful resolution. I just don't know h…

If it's going to be fixed this year, then why isn't it even on the official road map? https://github.com/Microsoft/visualfsharp/issues/2400

You might want to take a look at this announcement RE: F# https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net... (does not mention native, but does address other deficiencies)

Re: Announcing .NET Core 2.0

#99
post #18

I wish I had a better sense of where cross-platform desktop app platforms stood these days: Electron, Java, .NET, QT. All I hear are "Eww, Electron is ridiculous, slow, heavy Web junk for desktop", "Eww Java is blub, insecure, and half-abandoned by Oracle", "Eww, .NET is Microsoft and unreliable for anything serious on non-MS OSes", "Eww, by the time you pay the license, learn QT, learn the odd variant of C++, and ma…

Don't forget Delphi and C++Builder. Windows, Mac, iOS, Android, Linux Server, cross-platform UI framework with native controls as well as native-themed ones. Runs on the GPU, vectorised, fast. Two languages, including C++ and Object Pascal (similar to C# in feel, but not C-style syntax.) Very large set of libraries for app development, server development, etc.

I quite liked C++ Builder pre .Net days, tons of useful libs included and community projects like Jedi.
Post reply on HN