Live data from Hacker News

Announcing .NET Core 2.0

blogs.msdn.microsoft.com

71–80 of 145 posts

Re: Announcing .NET Core 2.0

#71

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…

It's because Microsoft's main client application platform's .NET runtime is not .NET compliant, resulting in their own language, F#, not be supported. See here https://news.ycombinator.com/item?id=15007166

They act as if C# is the only .NET language and nothing will change if we don't speak up about it.

Re: Announcing .NET Core 2.0

#72
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 trend for multi-platform software is to build it on web technologies. There's nothing for the user to install and they can access the software from anywhere there's an internet connection. If you need it to be offline and integrate into the operating system, then electron would be the next logical step in that direction. If you want deep, and award winning support, you're going to have to write your product nativ…

With GTK, QT, Tk, etc we used to have a fairly good near-native cross platform story before mobile happened. Apple's reluctance to accept non-native code, Google's pick of Java for Android and early smartphone resource limits made native code a necessity. Meanwhile the web developed into a universally supported application platform which made it inevitable that JavaScript made its way to mobile as processing power increased.

The desktop became just another platform to target. Few cross platform apps can afford to not target the web with all of its benefits like instant, no install required delivery. A whole generation of developers is growing up on Webpack, Babel and React.

Who can fault Electron for existing?

As a user I mourn the cost at which this new wave of desktop apps come. If it were only memory I could buy more – up to a limit – but many of these apps put us back a good 10 years in responsiveness and even screen real estate. My workstation feels like a two year old phone. Who thought unchecking “Show window contents while dragging” would ever make sense again?

Luckily, to get to the original question, we are getting new options. I'm quite excited about Xamarin, which lets us provide a good experience on mobile, against the native toolkit if we like, but also a fast, familiar desktop app.

This isn't worth anything as long as we can't target the web and this is where I hope WebAssembly will bring us.

I remain hopeful. We must be able to do better than ship web browsers to our desktop users, but maybe we're not quite there yet.

Re: Announcing .NET Core 2.0

#73
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're doing something interesting, you probably need to call native APIs for OS concepts that are unique to each platform. A cross-platform environment can't do this very well; and we drop into C++ APIs on Windows and Objective C on Mac to do this.

The sweet spot for cross-platform development is your business logic, and networking calls. That shouldn't change as you move among platforms, and that should be the area that cross-platform development gets right. If you're willing to do this in C or C++, everything will be straightforward, but you have to deal with the warts of C and C++. If you need a higher-level language, it better integrate well with the languages you need to do your UI and low-level logic in.

Re: Announcing .NET Core 2.0

#74

Earlier quoted context omitted.

The trend for multi-platform software is to build it on web technologies. There's nothing for the user to install and they can access the software from anywhere there's an internet connection. If you need it to be offline and integrate into the operating system, then electron would be the next logical step in that direction. If you want deep, and award winning support, you're going to have to write your product nativ…

With GTK, QT, Tk, etc we used to have a fairly good near-native cross platform story before mobile happened. Apple's reluctance to accept non-native code, Google's pick of Java for Android and early smartphone resource limits made native code a necessity. Meanwhile the web developed into a universally supported application platform which made it inevitable that JavaScript made its way to mobile as processing power in…

If only Microsoft would let us build native UWP apps in F# without having to jump through hoops with web frameworks

https://news.ycombinator.com/item?id=15007166

Re: Announcing .NET Core 2.0

#75

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…

If you think of the people that would naturally look to C# there are a lot of reasons why you might have an existing C++ codebase and migrate to a C#/C++ codebase. It's relatively straightforward to link the two languages where doing the same for Java is a lot more work. There are lots of legacy applications with decades-old business logic that can be glued into C# WinForms and work swimmingly. Java has this but the interop code is a lot of work.

Java applications also in my opinion struggle to feel 'native' especially on Windows to the same level of niceness as C#/C++.

Re: Announcing .NET Core 2.0

#76
post #69
post #17

Earlier quoted context omitted.

I'd agree with this but F# is increasingly moving towards first class support.

I will believe that when F# gets a spot in UWP, right now it seems on its way out with an open ticket for support since Windows 10 came out.

We should make a bigger fuss about F# support for UWP https://news.ycombinator.com/item?id=15007166

Re: Announcing .NET Core 2.0

#77
post #9

Earlier quoted context omitted.

i tried f# and it really feels like a second classe citizen ( at least on macos). Very few educational resources. You still need to spend a lot of time on c sharp to learn the frameworks, and then maybe move to f#.

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.

Re: Announcing .NET Core 2.0

#78
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…

> 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.

Re: Announcing .NET Core 2.0

#79

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…

There are plenty of languages built on the CLR [1], including variants of Clojure, Python, and Ruby. Then there's the "official" languages: C#, C++/CLI, VB.NET, JScript.net. I suspect what's going on is that 1) unlike Java C# has actually evolved so the need for "escape hatch" languages is lesser, and 2) .NET developers want to use languages with rich Visual Studio tooling. https://en.m.wikipedia.org/wiki/List_of_CLI…

Don't forget F#!
Post reply on HN