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 manually deal with different bugs on every platform, you discover you would have been better off using the OS makers' preferred tech on each," and so on.
It's hard to tell how much of this emotional reaction is due to current reality, how much is leftover from old experiences that are no longer relevant, how much is just language preference (not platform quality), etc.
I could just try them all, but my experience years ago was that the cross-platform tech, when it worked, made things easy at first, but that final 5% of your code was always trying to find hacks to do what no one had ever tried before--very time consuming and risky (no guarantee of success). So "trying them all" won't really give me a true sense of where the technologies are in reality.
There's no rush in my case, but I do wish I had a more realistic sense of what the various desktop dev technologies were like these days in case I ever go back to it.
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.
> 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.
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.
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 natively for each OS using native APIs. There's just no way around that requirement unfortunately.
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.
Wait what? That's totally astonishing - I thought the entire point of .NET and the CLR was to be a language-agnostic runtime. Why can't you build UWP apps with it? How do they even know?
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 supporting the IL required by F#.
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?
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.
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.
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.
The idea is to only have bindings for QML engine and it's parts, with the ability to use .NET objects (properties, signals, slots, methods) with vice-vera (using dynamic).
It is very much in the early stages, but to me, the idea seems very promising.
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 used to think C++/CX could finally be what would make Visual C++ actually Visual and comparable to C++ Builder, but the talks at BUILD and the exclusivity of C# even for HoloLens and Fluent Design demos shows that it failed to gain momentum, being mainly used by Microsoft to write low level code.
The idea is to only have bindings for QML engine and it's parts, with the ability to use .NET objects (properties, signals, slots, methods) with vice-vera (using dynamic).
It is very much in the early stages, but to me, the idea seems very promising.
Sure, it is based on a language which some people have aversions against (for unclear reasons), but it in fact does cross-platform GUI development almost flawlessly, and almost completely friction-less (no, or very little, code change to compile on the three desktop platforms).
Try open up a stable version on your platform of choice, drop a button on the form, double click and write some code (with autocompletion) and compile ... and then import the project on another OS and compile ... It's all a pretty mind-blowing experience, just how productive and "Just Works" the whole thing is.
To expand a bit, it compiles to compiled binaries in the range of MB, uses native GUI libs on each platform (GTK or Qt on Linux for example)... and you can now link it with a language like Go if you need some heavy multi-core processing, or need to access stuff that FPC doesn't have good libraries for [2].
It was discussed in depth here on HN just 5 days ago [3]
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.
I wrote a cross platform JavaFX app a couple of years ago. I can't talk to .NET or Qt but I can at least discuss my experiences with that.
Firstly, there aren't any modern, serious, cross platform desktop development environments I'd describe as lightweight. That is not always a problem. If your UI needs are fairly straightforward and you want to use native widgets, then you can use Java+SWT or even AWT. It may sound ridiculous but for small utilities and such that want some buttons, tabs, menus and edits, you don't actually need a modern toolkit - and there are quite a few abstractions over native widget toolkits that work well enough if you aren't demanding.
Now what about the rest. You can see a screenshot of my app here - it's open source but I no longer distribute it:
I wrote a desktop app in Java for several reasons:
• It was a peer to peer app. Web and mobile don't really 'do' p2p networks.
• I had already written a library that was the engine of the app, in Java.
• Ignoring the P2P issue for a moment, my target market of early adopter cryptocurrency fans was split across several mobile platforms but all of them had laptops. Cross platform dev on the desktop is more mature than mobile.
• The app had a content creation component that wouldn't have worked well on small screens.
• I wanted to try new ideas in auto update technology, specifically, to enable signing keys to be held in a Trezor hardware device, and allow multi-signature auto updates. So that meant I couldn't distribute via an app store.
My experience of JavaFX was pretty good. It's the third gen UI toolkit after AWT and Swing. It's not abandoned by Oracle. It is however in maintenance mode. There is a reasonable sized team working on it but they focus mostly on bug fixes and rounding out the API these days rather than major new features.
JavaFX dates from around 2010, so it's a modern toolkit. To try and stay on topic, it's similar to .NET XAML. It has all the mod cons like a proper scene graph, support for fully reactive programming, GL/Direct3D based rendering with shader accelerated effects and so on. The design is very nice. The people who built it have done UI toolkits before and you can see their experience shining through. You can style with CSS and I found I could make a UI that looked like a Twitter Bootstrap app just by applying some CSS rules. Combined with a few simple rules (e.g. no menu bars, tree views, etc) I was able to make a UI that basically felt like a web app without actually being so. Nowadays I'd use TornadoFX which is a Kotlin framework that makes it even easier to use.
The big catch is always distribution. All desktop toolkits except Electron suck at this.
There's a tool that creates native installers for your Java app on Mac, Windows and Linux. The user won't know it's Java and doesn't need Java installed, but the resulting installers don't auto update at all. Acceptable if it's 1998 but not so much anymore. I rolled my own auto update framework as I wanted to make it high security anyway, and this wasn't hard, but it was never quite satisfying. I see that Electron uses a separate framework called Squirrel, maybe that's the way to go for Java apps too. But what I really want is an app browser.
I hit a few bugs along the way, none critical. JavaFX has spent the last few years with the team mostly focused on bug fixes and bringing features from internal APIs to the public API, and I felt it get more solid as I worked. Some glitches were platform specific but none were hard to diagnose or work around. It's no worse than any other framework.
Overall I much prefer JavaFX to the web platform. One was designed and implemented by a unified team with a unified vision. The other is a warty swampland which I'd describe as the product of evolution, except that evolution implies some kind of natural selection, which when talking about the web would be too kind. The web can do peer to peer video chat but does not have basics like a decent virtualised table or list view. JavaFX nails the basics all UI toolkits should have, but also supports things like composited h.264 and some basic 3D graphics. It can also embed WebKit if you find you need it.
My wish-list for JavaFX ends up being quite short. Integrate Squirrel for auto updates. Provide direct access to an underlying OpenGL context for more sophisticated 3D work (and let you force GL on Windows). Optimisations. Bug fixes. That's it.
Every technology has it's problems, and you should be careful what you use as your source of information. Always do your own research when choosing a new technology to fit your needs best, and talk to other people/consultants who have experience in this area and can point out problems before you commit to anything.
That's always a good suggestion and provides existence proofs, but you have to remind yourself that apps can take years to become favorites, so favorite apps tend to favor older technologies even when the older technologies might not be better.
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, there's just too much.
> 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.
> 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.
When I first used Visual Sutdio it was VC++ 6 and I upgraded my machine to have 256MB of RAM so I could run it. What features does VS Code have that VC++ 6 didn't?
I didn't use VC++ 6 myself, but I'll take a guess at a few things:
- IntelliSense
- Tasks for external tools
- Themeable
- Extensible through plugins, for which there is a large ecosystem
- Support for many languages, with syntax highlighting and linting (through plugins)
- Support for different debuggers (e.g. debugging a Cordova app)
- Support for different version control systems (TFS, Git, SVN...)
- Minimap
- Highlighting of all instances of selected text in the scrollbar (don't know if this feature has a name, but it's really useful)
- Ability to edit multiple lines at the same time
- Bracket matching
- Code folding
- Live, inline reference information
- Not sure if 'go to definition' or 'go to implementation' was a thing in the days of VC++ 6?
- Workspace zoom
- Support for screen readers
- Integrated terminal
It had most of those things, especially the important ones:
- IntelliSense - Yes
- Tasks for external tools - I think so
- Themeable - Yes, back then you could theme the whole windows desktop and native apps would comply.
- Extensible through plugins, for which there is a large ecosystem - Kind of, all the "plugins" came from MS.
- Support for many languages, with syntax highlighting and linting (through plugins) - Yes, not sure how many.
- Support for different debuggers (e.g. debugging a Cordova app) - Don't think so.
- Support for different version control systems (TFS, Git, SVN...) - Not sure, it predates everything on that list.
- Minimap - Don't think so.
- Highlighting of all instances of selected text in the scrollbar (don't know if this feature has a name, but it's really useful) - Not sure
- Ability to edit multiple lines at the same time - No
- Bracket matching - Yes
- Code folding - Yes (I think)
- Live, inline reference information - Yes
- Not sure if 'go to definition' or 'go to implementation' was a thing in the days of VC++ 6? - It was (not sure about goto implementation though)
- Workspace zoom - Don't know what that is.
- Support for screen readers - Probably via windows API's, but I'm not sure.
- Integrated terminal - not sure.
Sure doesn't look like a lot of process in the intervening 20 years.
By 'Workspace zoom', I mean you can dynamically change the zoom level of open files, without having to go through settings menues to increase/decrease the font size
I just opened a large project in VS 2017 - 1GB of memory usage, vs 250MB by VS Code.
Sure, 250MB is a lot by 1990 standards, but for something as fully featured as cross-platform VS Code with today's machines (and especially when compared to full VS), it's rather impressive.
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.
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.
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 features it's even likely to go the other way round), but as of now, Electron as a desktop platform is inferior when compared to a native app in all aspects.
In what respect? Start-up time, memory and cpu, speed, lack of native controls, poor optimization, complex debugging... What's the worst for me is the fact that you know there are certain parts of the app you will never be able to optimize. It's just like having empty loops inserted in different places of your app, only because of the choice of platform. Sometimes it feels like Swing in the old days.
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.
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 have some great videos on Microsoft Virtual Academy. Early on it felt like many packages weren't compatible (particularly PDF & Image tools), but as time has progressed many old packages have been converted to .Net Core. One project I converted was in PHP before, so I can't accurately speak to performance (obviously feels fast), but development speeds have increased greatly with IntelliSense vs a text-editor. Another project, I had a C++ console application that sort of needed to become a web application but wasn't worth the effort of rewriting. In relatively short order, I had a .Net Core web application using interop services to call the dll. I was later chided by some C# purists that it could have been rewritten in C#, but it was still cool to see how easy it was.
Ten years ago when I was starting out, Microsoft wasn't even a consideration when looking at toolsets, it was stodgy, expensive, and didn't run on a MacBook. Now, not only have they completely redesigned, and sold me on their development toolsets, but they've implemented an interesting alternative to AWS, and they've shifted my go-to machine from a Mac to a Windows machine. The turnaround is pretty remarkable (obviously they have remarkable resources, but still). I sort of want Michael Lewis, or someone, to write a book about the last decade at Microsoft.
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 interfacing it with Unity.
When I first started using Unity many years ago, we used to say it made making games fun again. I can say .Net Core feels the same for Web/API development.
Kudos to all those who put effort into bringing 2.0 out.
> 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)
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.
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.
I've had a similarly positive experience writing a CMS in dotnet core that currently runs my blog. Like you said, being able to stick everything I need in a Docker container makes life so much more easy then it was with ASP.NET in the past.
For the person that asked why choose dotnet core over another technology: the only other technology I've recently used on the backend had been node which paled in comparison to core's compute performance, documentation and ease of development (TypeScript helps a ton on node, but C# on Visual Studio makes things really simple and easy).
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.
Like I get that it feels like a big change (and it is), but you've gone and confused a huge population of library writers and users with the major version bump.
It doesn't break sem ver. Sem ver doesn't disallow revving the major number without making a breaking change. It only says if you do a breaking change, you need to rev the major number.
The idea is to only have bindings for QML engine and it's parts, with the ability to use .NET objects (properties, signals, slots, methods) with vice-vera (using dynamic).
It is very much in the early stages, but to me, the idea seems very promising.
Not specificly .NET Core, but Xamarin is already available for macOS and is, afaik, actively working on Xamarin.Forms coming to desktop, including Linux.
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.
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?
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 superior to the JVM - is that on sheer performance only ?
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.
With the exception of UWP support (which I'm sure will come), F#'s future seems pretty certain to me. There seems to have been a lot of interest in it lately, probably fueled by the current hype over functional programming.
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."
With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design.
MFC is mostly on maintenance and new application should use XAML + C++/CX.
C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead.
The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for the UWP kernel components.
Because most C++ devs would rather use something more standards friendly, there is work in progress to eventually replace C++/CX with C++/WinRT, taking advantage of C++17 features.
Not much, throughout my career I have learned that the best path is always to only use the officially supported SDK languages for production code.
All productivity or enjoyment using alternative languages gets lost in extra FFI layer, unavailable platform documentation, lack of support on the IDEs, poorer debugging, GUI tooling and code generation.
So I only use alternative languages to learn about new concepts and ways to improve my skillset, but in what concerns production code, the golden rule is 100% SDK languages.
Going back to your question, Java on UWP is only possible via the JVM provided by CodenameOne and I think it actually makes use of the Desktop Bridge, so that rules out Scala.
Rust still has a lot to catch up with C++ for using COM in a productive way, let alone .NET based languages.
UWP is basically what .NET should have been, if they had kept the original COM+ plans instead of going with the CLR. So any language targeting UWP needs to have seamless COM support, and ability to handle .NET metadata.
Point taken; it's obviously not a top priority for them, with C# remaining the primary focus. I guess that makes sense, since so many more devs use C#.
While dissapointing, I'm sure (well, I hope :) F# support will land in VS before too long. In the mean-time, VS Code really is a great alternative
> 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.
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...?
Beanshell came before Apache Groovy and had many dynamic features useful in scripting for the JVM. Groovy essential copied many of those Beanshell features, then added closures, which was Groovy's real contribution to the JVM ecosystem. Soon after there was some disagreement among its leaders over the syntax when closures are used as Kotlin-style builders.
Huh, I did't know there was lineage there. Coincidentally, I've actually used Beanshell; integrating it in to a project was a SUPER pleasant experience.
It was some weird find/replace thing I contrived in college to let you do weird crap like define a bunch named regexes and use them to match and transform stuff. Contrived example that chops the "L" off long literals in files with the (optional) beanshell integration:
The .NET runtime is not superior to the JVM and probably never has been. Certainly not in performance. The JVM stomps .NET CLR in performance.
C# has been superior to Java, as a language, for quite a long time (IMHO) and likely always will be. The libraries, well, I don't know. Pretty similar I guess.
The thing to consider about programming languages is there's no way to make money from them anymore. That means they're either loss leaders for some other product (Swift : iOS, C# : Windows), the result of academic research (Scala, Haskell, etc), one man's personal quest to redefine coding (Clojure, Groovy, Ruby), or the result of a company attempting to optimise its own processes or products (Go, JavaScript, Kotlin). Oh yes. And then there's C++ which defies categorisation :-)
So now you look at the categories above and what do you observe? That a lot of the developers will be essentially hobbyist in nature, or working on products that are often used on UNIX. These people will want to build on a cross platform runtime. Until recently .NET was not cross platform.
JVM bytecode is also a bit simpler than .NET bytecode and has better support for dynamic languages. Many languages are dynamic.
.NET always had AOT compilation from day 1, and now has .NET Native, which is the same backend as Visual C++.
It had forks being used to write Singularity and Midori, and official support for unsafe code if performance required it to, including ways to manually manage memory.
The CLR has native APIs for IL rewriting engines, via the profiler native API.
Supports value types, SIMD, and the roadmap to C# 8.0 will be adding more features bringing C# low level capabilities closer to C++.
Java will be getting some of these goodies as per Java Language Summit 2017, but they are all targeting Java 10 or later, while .NET is delivering them on 2017.
It was my understanding that it was hard to compare the JVM and the CLR in terms of performance. But I'd always heard that the CLR was faster because of support for true generics, unsafe code, and value types.
I'm really interested in this, mind going into a bit more details?
You do know that Google is backing Kotlin right ? And that Apache Spark that runs Facebook's ETL is in Scala.
Or that Clojure is used at https://clojure.org/community/companies ?
My guess would be because Microsoft technologies were to tied to windows. If you, a non-corporate entity is creating a new programming language with aiming at being mainstream, why would you choose a closed non-multiplatorm ecosystem?
Also, the JVM is better suited (much better performance) for running dynamically typed code.
You also seem to be confirming .Net has "superior performance" over the JVM, from where do you get that? .Net still has a long way to go to in being as mature/battle-test as the JVM is in linux IMO.
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.
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++.
I would say that the JVM has longer history of open source and a much larger ecosystem of libraries. If you're building a language on top of JVM you can take advantage of that.
Also pretty sure JVM has better performance because of better JIT and GC. The CLR had a second mover advantage to fix a lot of platform level things like utf8 strings, generics, tail calls, etc.
OK well .Net has Clojure, F#, C#, VB and Rosyln (compiler as a service). CLR vs JVM wise; both are highly optimized virtual machines with years of man hours behind each of them.
"You can now refer to .NET Core/.NET Standard libraries from .NET Framework projects and vice versa. No need to manually add interop NuGet packages – Visual Studio does this for you automatically."
Excellent. Hopefully developers moves over to .Net Core en masse now, and I won't have to wait long for all my third party projects to switch over.
Am I misunderstanding something, or does Entity Framework Core, even at version 2.0, not support translating LINQ code into GROUP BY in the generated SQL? That seems so unbelievable that I figure I have to be wrong here.
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?
Trying to get it working on Linux, I had to manually fix some permission errors, and now am stuck on this helpful error message: No executable found matching command "dotnet-net"
Not a great experience, especially since I was able to get 1.1 working quite easily.
I think C# is the one and only language to consider if you're doing anything serious in .NET. While F# is academically interesting and maybe OK for some personal or solo projects, you'll struggle to find developers for anything of substantial size.
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. Eventually F# will catch-up, but it is going to take time.
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.
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.
F# was supported on the MDIL compiler for Windows 8.x, then Microsoft did not consider the language relevant enough to support on the new .NET Native compiler when Windows 10 came out, almost two years ago.
Visual Basic .NET is still getting new features, though they recently announced they will stop keeping exact parity between VB and C# language features. (Instead, it looks like they are interested in making it easier to include C# code in your VB project and vice versa long-term.)
We've been running high-traffic production services for months, everything's been great. Leaner faster apps running on smaller, cheaper Linux VMs and containers. No problems encountered.
For running typical webapps and services, the existing .NET APIs were already good enough and now we have pretty much everything else available.
It's hard to tell how much of this emotional reaction is due to current reality, how much is leftover from old experiences that are no longer relevant, how much is just language preference (not platform quality), etc.
I could just try them all, but my experience years ago was that the cross-platform tech, when it worked, made things easy at first, but that final 5% of your code was always trying to find hacks to do what no one had ever tried before--very time consuming and risky (no guarantee of success). So "trying them all" won't really give me a true sense of where the technologies are in reality.
There's no rush in my case, but I do wish I had a more realistic sense of what the various desktop dev technologies were like these days in case I ever go back to it.