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

Announcing .NET Core 2.0

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

81–90 of 145 posts

Re: Announcing .NET Core 2.0

#81

Post by revelation »

sandGorgon wrote: post #19

Why are there so few new languages built on the .NET platform ? This is a genuine question - is there something about the JVM that gives rise to such vibrant ecosystems. Clojure, Scala, Kotlin, Groovy, JRuby : Most importantly, every one of them is in production use - not just as toy/experimental languages. And we havent even opened the Pandora's box that is Java 9+Truffle. There's a lot of broscience that .NET is su…

Wait, you believe outside of Hacker News (you know, "broscience") people use (or even know) any one of "Clojure, Scala, Kotlin, Groovy, JRuby"?

I think I have news for you. No company without a foosball table in the break room would remotely think of such a thing.

The users of VB.NET alone dwarf any of those languages. There is a reason Microsoft keeps updating that.

Re: Announcing .NET Core 2.0

#82

Post by pantalaimon »

Scarbutt wrote: post #38
dvfjsdhgfv wrote: post #35

Earlier quoted context omitted.

I'm sorry, but as for now, Electron is really not the best choice for a desktop platform, and you can't declare it a standard only because some developers choose it, mostly because it's easier for them to create or port apps using a familiar stack. In the future, certain things may change - the performance might be better and resource usage might get lower (although I honestly doubt - with browsers getting more featu…

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.

Re: Announcing .NET Core 2.0

#83

Post by vintagedave »

SiVal wrote: 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.

Re: Announcing .NET Core 2.0

#84

Post by jdc0589 »

merb wrote: post #59
Const-me wrote: post #39

Earlier quoted context omitted.

> is there something about the JVM that gives rise to such vibrant ecosystems Java. It evolves too slowly, that’s why people try to fix it creating another languages on top of JVM. MS did much better developing C#, therefore less need for alternative languages.

that might be true for kotlin, but probably not for Clojure, Scala, Groovy and JRuby

I'd argue it still could be true. The CLR has variants of a lot of those too, but they are much less popular. All those alternative languages for the JVM probably still would have been born at some point even if Java adapted faster, but they are as popular as they are due to Java's slow adaptation.

This isn't a very good argument, but name recognition is on totally different level with alternative JVM languages too. Most people have heard of Groovy even if they don't use it. Boo on the other hand...?

Re: Announcing .NET Core 2.0

#85

Post by WhitneyLand »

Perfect example of a strong technology that has really been hurt by strategic errors.

Whatever success .NET did have, it was still largely pigeonholed as just something for Microsoft stack devotees.

There was no technical reason the essence of the new core version couldn't have been a priority 20 years ago. Not only cross platform and open source, but acting earlier and more aggressively to dispel patent trap mistrust. It cost precious momentum.

No doubt hindsight makes it easy to say all this now, but there was still an issue of entrenched thinking about the way things had always been before, combined with a circle the wagons mentality.

One part of it I think was easy to see, was that free high quality development tools should have been widely available day one. How does it make any sense for a company to try and make $5000 off of a copy of visual studio, at the expense of platform momentum that is driving $200 billion a year in revenue?

Re: Announcing .NET Core 2.0

#86

Post by jackfoxy »

TensorMetric wrote: post #77
jackfoxy wrote: post #20

Earlier quoted context omitted.

The problem is F# does not use the Roslyn compiler (but does use other components of the Roslyn tool stack in Visual Studio) and it uses things in the IL (primarily tail calls) the other .NET languages do not -- and the rest of the Microsoft teams understandably want to move fast on all the initiatives surrounding .NET Core. This results in the Microsoft F# team and the F# community contributors playing catch-up. Eve…

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 how soon. Before today's announcements my personal thinking was that it would be this autumn. That's still possible. In the meantime I can still function in the F# world, as before. It just remains frustrating to branch out into some of the areas I would like to.

Re: Announcing .NET Core 2.0

#87

Post by jefe_ »

Yhippa wrote: post #34
jefe_ wrote: 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…

Why did you select .NET Core versus other technologies?

It made sense throughout the whole stack. We're right on the edge of small-midsized, so we need to find technologies which our people know or can easily learn.

Database level, our DBAs are very SQL Server oriented and all of our primary data stores are such, the ORM for .NET Core, Entity Framework plays very well with it. This was probably the biggest factor. It has a decent Redis library.

Application Level, it is a managed runtime, strongly typed, performant, with a strong ecosystem of libraries. We're running calculations on data so out of the box performance is important. Scaffolding models into Controllers and Views is handled very well, along with migrations. Strong facilities for serializing and parsing Json & XML. Nice interfaces for integrating email and SMS services. It has a secure, extensible authorization framework (Identity Server). It has a strong debugger, when you make a typo, you know right away, so you can cut out the vast majority of issues by the time you're running it. Easily share class libraries across projects with a private NuGet repository. A nice implementation to get metadata in System.Reflection along with intuitive handling of generics. Support for lambda expressions and functionalish behaviors. Carefully considered implementations of asynchrony and parallelism.

For front-end tools I'm not as up to speed, but browsersync is built in, so that is running without any configuration. They have automatic minification of css and javascript on build, and some tools to work with Angular, Vue, React, etc. as well as an emmet clone which allows you to use emmet shorthand when generating html.

Dev Ops, the Visual Studio IDE is really comfortable for a wide range of people. Strong integration with GitHub & Docker.

Re: Announcing .NET Core 2.0

#88

Post by jsingleton »

gwbas1c wrote: post #73
SiVal wrote: 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…

I work on a cross-platform desktop application written in C#. We use .Net on Windows and Mono on Mac. The thing with desktop applications is that an "industrial-strength" one needs to look native; thus it's in our best interest to use the native language of choice. This means that our Mac UI is Objective C, and we're very good at integrating Objective C and C#. The other thing with desktop applications is that if you…

Xamarin makes this separation work pretty well. Not Xamarin.Forms but a core business logic project with custom UI projects for each platform.

I'm hoping this will turn into a good solution. Xamarin already supports Mac (in addition to iOS and Android) and when it aligns more with UWP (XAML Standard etc.) that could cover a large slice of the platforms you'd want to target.

React native could be another option. I hear Android support has gotten better and you can supposedly also target UWP: https://github.com/Microsoft/react-native-windows

I wrote this a while ago but it's still fairly relevant: https://unop.uk/cross-platform-native-mobile-app-development...

You could also look at https://github.com/AvaloniaUI/Avalonia or https://github.com/picoe/Eto.

Re: Announcing .NET Core 2.0

#89

Post by Rusky »

gwbas1c wrote: post #73
SiVal wrote: 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…

I work on a cross-platform desktop application written in C#. We use .Net on Windows and Mono on Mac. The thing with desktop applications is that an "industrial-strength" one needs to look native; thus it's in our best interest to use the native language of choice. This means that our Mac UI is Objective C, and we're very good at integrating Objective C and C#. The other thing with desktop applications is that if you…

> The thing with desktop applications is that an "industrial-strength" one needs to look native

I don't think this is the case for every application. It's definitely true for mobile apps, and it's probably true for desktop apps that are relatively small and/or use mainly standard OS GUI functionality.

But for things like Photoshop, or Office, or Unity/Unreal, too much of the UI is application-specific for it to really matter, and I think they benefit from a consistent cross-platform codebase and appearance.

Re: Announcing .NET Core 2.0

#90

Post by nightski »

GordonS wrote: post #78
dep_b wrote: post #63

Earlier quoted context omitted.

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…

> Electron means you need 2GB of memory for a simple chat app... No, it doesn't. Visual Studio Code is an extensible IDE that is stuffed with features - yet it doesn't use that much memory, and it's fast . And yet there are seemingly simple Electron apps that use a lot of memory and are slow - it seems, just like with any other framework, it's possible to write both good and crappy code.

I mean, I have one window open with one file right now and it is using 400MB which is kind of crazy.
Post reply on HN