Announcing .NET Core 2.0
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
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.
https://github.com/pauldotknopf/net-core-qml
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.
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.
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.
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#.
It's really too bad, Win2D was quite nice.
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.
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,....
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.
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.
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.
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.
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.
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?
- 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 - 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.
Ah, I missed one important one though:
- Cross-platform
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.
Source: https://www.quora.com/How-did-Spotify-make-a-multiplatform-l...
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:
https://media.coindesk.com/uploads/2015/01/Lighthouse-630x45...
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.
https://github.com/pauldotknopf/net-core-qml
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.
https://developer.telerik.com/content-types/tutorials/xaml-s...
I wish Oracle should do more with JavaFX, may be embrace JSX templates.
[1]: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Supported_...
Native or Web on mobile projects, again depending on the use case.
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.
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.
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.
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.
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.
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]
[1] https://www.lazarus-ide.org/
[2] https://forum.lazarus.freepascal.org/index.php?topic=24948.0
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.
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.
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.
How does it handle a lot of users hammering at the API at the same time?
.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.
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)
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 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).
One critique:
Why break semver?
https://github.com/dotnet/standard/blob/master/docs/faq.md#w...
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.
https://github.com/search?q=netstandard2.0&type=Issues&utf8=...
How many of those are irrelevant or invalid? That's just github. I already see the noise being created in slack and gitter channels as well.
Other than that I think dotnet core is an amazing engineering effort and I've been happy using F# on OSX with it.
Things are very hit or miss in F#-land with .NET Core.
https://blogs.msdn.microsoft.com/visualstudio/2017/08/14/vis...
If not, what toolkit would be recommended these days for this purpose?
https://github.com/pauldotknopf/net-core-qml
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.
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...
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 ?
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.
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.
I hope being proven wrong though.
https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...
Apparently lack of support wasn't enough to delay Visual Studio 15.3's release, just let the community deal with it.
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
https://www.reddit.com/r/programming/comments/6tppt4/f_and_n...
https://twitter.com/k_cieslak/status/896658073338695680
Of course he doesn't care about UWP support, as he wants to promote his own VSCode plugin.
"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.
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.
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.
https://docs.microsoft.com/en-us/cpp/windows/universal-windo...
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.
“Embracing Standard C++ for the Windows Runtime"
https://www.youtube.com/watch?v=lm4IwfiJ3EU
“Putting Coroutines to Work with the Windows Runtime"
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.
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.
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...?
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:
integer {
-?[0-9]+
}
really_bad_long_chopper {
<integer>L
} -> {
String original = match.group(0);
return original.substring(0, original.length() -1);
}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.
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.
I'm really interested in this, mind going into a bit more details?
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.
They act as if C# is the only .NET language and nothing will change if we don't speak up about it.
Java applications also in my opinion struggle to feel 'native' especially on Windows to the same level of niceness as C#/C++.
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.
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.
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?
Not a great experience, especially since I was able to get 1.1 working quite easily.
https://docs.microsoft.com/en-us/visualstudio/test/live-unit...
I know VB .Net might be implicit here, but I am not so sure as I dont hear much about it anymore and I think it is no longer adding new features
And I know that there is some F# support
So aside from those two (VB .Net and F#) ... any other languages have serious support for .net core?
FYI... interesting collection of .net core stuff here: https://github.com/thangchung/awesome-dotnet-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.
How much time do they need to catch up?
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.
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.
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.
Discussion of VB.NET language design can be found here: https://github.com/dotnet/vblang
For running typical webapps and services, the existing .NET APIs were already good enough and now we have pretty much everything else available.
Anyone know what that's about?