I for one am extremely excited about having MS supported ASP.Net on Linux.
Mono is a great community effort, but the server side has always lagged Windows pretty heavily.
Having the same level of API and implementation support at a core level on Linux will be awesome.
Shall be interesting to see how this affects IIS market share in 5-10 years time.
TBH, this could help IIS in the long run, since it should improve adoption of .Net. This could also be the sort of kick in the pants that's needed to make IIS evolve into something people would choose on merit. The difference between IIS of today and IIS of 2020 could be very much like the difference between IE 6 and IE 11.
The difference between IIS of today and IIS of 2020 could be very much like the difference between IE 6 and IE 11
As a Microsoft developer with two MCSD certifications and an MCDBA certification, I actually laughed at this. IE11 is certainly better than IE6, but I find it unusable comparable to its modern day competition.
Abysmal plugin support, none of the nice usability features of Chrome (ex: Paste and Go on address bar, right-click Search Google for highlighted text, etc) and more leads me to believe Microsoft should give up with IE and start over with an IE branded version of Webkit or heck even Chromium. They could continue their Xbox marketing and call it Internet Explorer One and actually dominate the browser wars again. Leave the old IE classic on there for the small percentage of people that need ActiveX support (blech).
Web apps developer here, in terms of standards/proposed standards support, the situation is much, much, much better than it was with IE7/8/9/to a lesser extent 10. We develop primarily against chrome, and IE11-specific behavior (measured by # of defects) is less common than firefox-specific behavior, which is less common than IE10 specific behavior.
The plugin support may suck, the dev tools may suck, but in terms of the browser itself, it is much more capable than what they've had in the past.
Hmm, as a touch user my view is very different. Chrome's support for touchscreens is almost non-existant, while IE's touch version works even better than mobile safari on the ipad. I guess it's in the eye of the beholder. To be fair, I do use chrome on my non-touch laptops.
In terms of developers, that's a tiny change. Our users are using IE11 whether we want them to or not, but the massive effort they've put into bringing up the engine to speed with gecko, webkit/blink, is absolutely necessary to demonstrate on their other products before I would ever considering using it as a development platform.
Microsoft has definitely been putting its money where its mouth is w/r/t developers recently, and that's what they SHOULD be focusing on.
Developer tools in IE11 are much better than Chromes. Chromes have always been confusing and tedious, inherited from Safari. Apple has never really known how to build good developer tools.
And so you know, ActiveX is already in Chrome, but they call it native client. Supposedly it makes a world of difference in the Google Kool-aid camp.
Does IE11 even support ActiveX? I didn't think that it did.
I tend to use IE11 because it is lighter on memory usage than Firefox or IE and my machine has only 4GB of RAM. Also, it has a lot of those features. By default, I have right click and search with Bing and there are many accelerators that do the same thing. Plus, I don't see how so-called limitations in the shell should lead to an underlying engine change. I think Trident works well, although the main frustrating thing is that it doesn't work with a lot of IE only sites ironically (my company's old version of Outlook webmail, my credit union, etc.).
As someone who has to use IE11 on a daily basis, I would have to concur. I absolutely LOATHE using it and I'm most certainly NOT a Microsoft basher. About the only plugins that I can find that are worth anything (read as: works) on IE11 are Lastpass and Fiddler. So the OPs comparison is not a very good one.
Using IE 11 out of the box on a newly purchased windows 8 machine crashed on me. Continuously. It was the first application I had to start for windows authentication. I had to download the full chrome installer to get through the registration process that the vendor of the os and their browser couldn't. IE 11 is pretty bad.
>none of the nice usability features of Chrome (ex: Paste and Go on address bar, right-click Search Google for highlighted text, etc)
FYI IE has search X for highlighted text via accelerators, first introduced in IE8, though I'm not sure a search accelerator existed back then. It certainly exists now.
I saw some talks on ASP.Net vNext this week and the links between .Net web apps and IIS are weaker than ever. I'm sure that .Net web apps will still be deployed to IIS when they need to scale a lot, and are hosted on windows, but neither of those two are mandatory any more. A lot of sites and web services won't need all that and can use a self-host or lightweight host. OR new hosts/adapters to other web servers can be written. There's a lot more hosting and platform flexibility coming, which is exciting.
From what I can tell, the IIS team is embracing OWIN. Be sure to check out Project Helios (http://www.infoq.com/news/2014/02/helios). *Helios can be compared to OpenResty in the sense that the application runs directly on-top of the (core) web server, instead of a plugin/pipeline.
In my humble opinion, self-hosting is useful as long as it's feasible to reinvent the web server wheel. In terms of IIS that can include url rewriting, caching, compression, performance tracing, critical error logging, request logging, endpoint configuration including SSL (and SNI), zero downtime deployments, graceful shutdowns and much more.
The programming tendencies nowadays is to build highly specialized software (high cohesion), with only the needed dependencies (low coupling) and a small surface area to promote faster iterations (micro services).
Based on the above observation, the approach of Microsoft to release and endorse a cross-platform <core> .NET is commendable and is exactly what we need right now.
There's much to say about the downsides of the bring-your-own-x composition approach, but I truly believe the issues we face today will be addressed over time as the discipline and dedication of the programming community as a whole increase due to the increase in responsibility.
I guess IIS and Windows Server have an important role providing high performance HTTP service hosting nodes in Azure. If this effort from the .NET team can revive the future of .NET server-side development, the server team can capitalize on the integration of the managed stack on top of the kernel-mode http.sys web tier, to provide a first class hosting environment for ASP.NET applications on the Azure cloud. Microsoft is the one hosting provider in the world who can scale out Windows servers without having to worry about license costs.
Amazon and Google don't have to license their cloud technology, so why would Microsoft (be forced to adjust license costs. or to license it at all)? (Unless MS were to become the dominant hosting provider and some anti-monopoly law or regulation were to come into play, but right now they are far from there.) Licensing IIS is a side business to the cloud hosting business.
I wonder how it would compare in performance to latest PHP/Nginx stack which is rather very fast with good code. And then there is major improvements in PHP on horizon and already alternatives like Facebooks PHP implementation
Good questions. No answers, but I have this reflection to add. Over the past decade PHP has, by and large, put food on my table. Every year or so I evaluate my overall toolkit (ranging from languages to frameworks) and make sure I'm backing the right horse.
This year, I put a thirty-five dollar C# book on my holiday wishlist.
I'm gonna guess it would be around the same on a Linux server, because it's under a runtime, just like PHP. There's no reason to expect a drastic difference between one or the other.
On a Windows server however it's compiled and highly optimized. Which PHP/NginX/HipHop you also have a compiled environment and is just as fast or faster.
I have no data to back it up at all, but I'm going to guess ceteris paribus the performance differences are marginal at best.
I personally despise coding in PHP as much as anyone, but it has been used for a number of hugely successful projects, including Wikipedia and Facebook (that latter has even written a transpiler that converts PHP into C++). PHP is the bog standard on a LAMP stack so you know it will run on any environment, and there is a huge pool of programmers who know how to code it. Those are nontrivial reasons.
If you consider Wikipedia a good example of what PHP can do, we have irreconcilably different quality standards.
I think the technical debt of PHP is a huge reason why development of the software behind Wikipedia hasn't fixed any of the huge issues in the last 5 years.
Oh, I don't know... Maybe because of easiest imaginable deployment scheme? Comprehensive stdlib and lots and lots of libraries and bindings for everything? Its forgiving nature, which makes it try very hard to do what programmer meant instead of dying with cryptic error messages? Or possibly because of bazillion other legitimate reasons people have for choosing to use it...
Languages are just tools. Some are better than others for a specific task. This is a fact. You choose the language for a given task because it fits the task better than other options. That's all there is to it.
I don't currently use PHP, but I acknowledge that there are situations where using it makes sense. I'm just not in one of those situations in present. Saying that PHP is a bad choice in every situation is worse than stupid: it's simply wrong.
"Its forgiving nature", like VB's "On Error Resume Next" and JavaScript's automatic semicolon insertion, is not an advantage. Debugging with cryptic error messages is better than having no idea that the program is silently doing the wrong thing.
Its standard library is no more comprehensive than those of comparable languages.
The only advantage left, then, is the same one all the sibling comments bring up: it's already installed on the server.
So the question remains: Why would anyone who has a choice and knows that other languages exist ever use it for anything?
I'm a ruby developer myself (and also a huge advocate of ruby) I use PHP to mashup quick weekend prototypes to test stuff like third party API's, mini dashboards, etc. Because, nothing beats the convenience of uploading a simple PHP script to a server via FileZilla. It's what you build with the programming language that matters more than the language you use. And no, I refuse to be shamed for my programming language choices.
I know it's "cool" to hate PHP, but anyone asking this question obviously hasn't used it. It's a tool that solves problems fast and cheap. It's not for every application but it fits for some VERY well. And most of PHP's problems are the newb programmers it attracts, just like JavaScript. The language itself has tons of quirks but you can write good PHP just as well as anything else, and you can solve certain problems very fast with it.
The thing is there are better languages that solve the same problems PHP solves at the same speed or faster. This is why Ruby become so popular.
Javascript is a sad story though, it's an abysmal language (even with ES6, though that does make things better) but it enjoys a monopoly over the browser runtime space.
I think asking why anyone would start a new project in PHP is a very reasonable thing to ask.
If you want quick and dirty there is Ruby + Sinatra, Python + Flask or Go + Martini.
All of which are safer, have less 'quirks' as you say and are all faster.
None of them require any more work than the current PHP alternatives.
PHP may be superior to some languages in some regards, but it's definitely no longer the king of the hill of prototyping languages.
As a Java and JVM focused developer the openning up of .NET really excites me. First, because .NET is a fantastic framework in and of itself, but also because this hopefully will encourage Oracle to be faster and more competitive with Java features and improvements.
I'm not sure that's fair. Java 7 and 8 have made some great improvements. The release cycle is fairly frequent and it's actually possible to migrate software easily enough unlike the python 2.7->3 standoff.
I know what I am about to say is both heresy and insanity, but maybe we could get a C# implementation that compiles to the JVM?
I mean, yes, C# has been largely open-sourced already. But with the new compiler framework being opened up also it seems imaginable that someone could write a version that spits out Bytecode instead of MSIL.
I have nothing against the JVM, but am not a huge fan of the Java language (and also how the Java libraries have been forced to be developed due to limitations within Java the language).
Yes Java 8 made Java much MUCH better than before, but just because Java 8 is a around doesn't mean all the libraries and other underpinnings got magically updated overnight.
One of the primary problems with this is generics (java/JVM uses type erasure, CLR/C# keeps type information) and value types (CLR/C# has them, JVM does not); That's why you can implement the JVM on the CLR (see IKVM.NET[1]), but not the other way around.
I'm not a vm or compiler expert by any means but Gosu and Ceylon have implemented reified generics on the JVM somehow. It seems possible, but I don't know what the performance impact would be.
Well it's obviously doable — both the JVM and CLR are equivalent to Turing machines, so it follows that they can run the same set of programs. It just, uh, might be non-trivial. :)
The Eclipse IDE plugin works but is pretty slow. I wouldn't use it if I wasn't so used to autocompletion + documentation in my IDE.
The module system can use the central maven repository but it doesn't accept dashes in the name like jackson-core unless you put it in quotes. (Took me a while to figure out).
Taken at face value I think this is misleading - a typical F# generic type will be represented as a normal .NET generic type at the IL level. However, it is true that some types are erased, like unit-of-measure type arguments or types surfaced by type providers.
Type erasure on the CLR is exactly as it is on the JVM. Generics are needed for interop with generic libraries (which aren't used that much beyond collections anyways in core libraries).
Erasure is necessary when the type system is differently expressive from C#, which I beleive F# is.
It would be super difficult to represent value types, generics and the reflection metadata in the JVM without building some kind of giant abstraction layer. MSIL is rich, maybe overly rich. If you get rid of value types and generics from C# you're basically left with ... Java.
Most languages give you enough rope to hang your self with. Scala gives you options to choose brand, width and color from a wide selection. The flexibility of Scala was scary when I started.
Anyone that wants to bring something new to our projects needs to prove what is the business value. If it reasonable, it gets adopted.
So for Scala to be adopted on our projects, customers need to be convinced what is the business value of having their multi-site team learning it, instead of us using their already installed infrastructure.
I can dabble in alternative programming languages on my hobby projects.
Since the CLR was designed to be hosted, I don't see why someone just doesn't make a CLR host that runs in/on the JVM, similar to something like SQL-CLR.
I know you can do this, but it would be a bad idea anyway, to support two different IL's instead of just one..
One way to solve something like this, with much less effort and elegance, would be to make both langs output LLVM IR for instance, and jit the native binary from there..
Thats my point, i cant think in any way something like this would be a good idea, given the ammount of resources needed to do something like this for trivial results that would not payoff the efforts.
There is only one scenario that this would make sense, and its on Android, given it is tied to a jit runtime engine, but then , they could just drop CIL and compile from source in a intermediate their runtime would understand, the same one's java is already using.. so again.. no luck with that effort
None of the existing functional languages on linux could deliver on functional programming hype. Clojure is too ugly, Scala is too complicated, Haskell too arcane.
I thought the same too, back when I really started into F# (2007 or so). But is it really taking off? People are still scared, worried that "it's hard to understand" (despite it being the opposite). Or that "it's hard to find F# developers" (which isn't true, a: anyone good can easily pick it up, b: advertising F#, like Haskell, will get a lot of people to fight for the jobs since it's rare to get paid to work with a great language).
Microsoft itself does not seem to give F# much resources. It's there, they've made some feature additions, improved VS support a bit. But not even 10% of what the C# team has for features. Microsoft refrains from telling people "you should use F#" which is good advice for all but the most terrible of enterprise environments.
F# is amazing because it's a solid language with great tooling support and fantastic interop (C, .NET) for excellent library access. I honestly believe there's nothing that quite matches it. Scala might be closest with tooling and JVM access.
It just doesn't have too many selling points for an enterprise app today. I have looked at it many times but it doesn't offer enough for me to start persuading people to switch. Terse ML-based syntax, lack of ReSharper and C# moving towards the functional side all make F# a less attractive choice. And I don't care about type-providers and all that other jazz they are adding lately too much. I tried to be excited about units of measure, but there isn't even a way to annotate third-party libraries (no, I am not going to rewrite e.g. third-party physics libraries from scratch)!
You can certainly annotate 3rd-party libraries. You basically just copy the signatures of the relevant APIs, and decorate arg types and return types with units that enforce the semantics of the problem domain.
Say you have some unit-free external library like this, which you can't modify:
type RectLib =
static member Perimiter(w:int, h:int) = 2*w + 2*h
static member Area(w:int, h:int) = w * h
Wouldn't it be great if we could enforce in our code that `w` and `h` have the same units? Or that the result of `Area` has squared units compared to the result of `Perimiter`?
You can do exactly that, by defining extensions like so:
module UnitExtensions =
open LanguagePrimitives
type RectLib with
static member Perimiter(w:int<'u>, h:int<'u>) =
RectLib.Perimiter(int w, int h) |> Int32WithMeasure<'u>
static member Area(w:int<'u>, h:int<'u>) =
RectLib.Area(int w, int h) |> Int32WithMeasure<'u^2>
Now units are enforced by the type system:
open UnitExtensions
RectLib.Perimiter(1<m>, 2<ft>) // error - <m> doesn't match <ft>
RectLib.Perimiter(3<m>, 4<m>) // ok
RectLib.Area(5<m>, 6<m>) + RectLib.Perimiter(7<m>, 8<m>) // error - <m> doesn't match <m^2>
RectLib.Area(9<ft>, 10<ft>) + RectLib.Area(11<m>, 12<m>) // error - <ft^2> doesn't match <m^2>
RectLib.Area(9<ft>, 10<ft>) + RectLib.Area(11<ft>, 12<ft>) // ok
with emphasis on 'good'. A SME might not have 'anyone good', and if it's just a back office data entry application, you don't want to use F# (or any of them fancy stuff). You want something any dumb coder can change and add to.
A subset of F# can be used (more or less) as a terser C#. Functional languages make writing correct programs easier. I don't think modifiability of an existing program depends on the language as much from the quality of the code. F# is not difficult, just a bit different.
Functional languages seem to have this odd halo around them that for some reason they are thought to be obscure and non practical. It's probably due to a historical baggage. If Ruby was originally picked up by compiler experts and language afficionados and the only resources that one could find were references to topics in those domains I bet people would be saying the same thing about it.
The main problem for adoption IMO is not language complexity, but rather lack of educational resources that display how easy and nice it's to do simple things on the language.
But since the simple things are so nice and easy it's really straightforward to do something a bit more complex and most of the published examples focus on these more advanced things.
I would suspect that learning functional programming itself, after pretty much everyone gets started with imperative, could take as much effort as learning OO from the same imperative base (but of course a lot more people now start with something like Python and at least dabble with OO).
I.e. more than an afternoon or probably a month to get good, vs. the few days it takes to learn another language with familiar paradigms.
Not sure from personal experience because I learned functional style Lisp/Scheme really early, more than a decade before OO, which made learning Clojure a relative snap. OO in the form of C++ was harder for me, but maybe functional is just easier for my mind to wrap around. The quality of the Lisp and Scheme texts I used, especially SICP, also probably made a difference (the OO texts I used were good, but not as great, with the exception of OOSE (http://www.amazon.com/Object-Oriented-Software-Engineering-A...), but that's as much about great design of your project as well as what the project is making).
Is "ugliness" the main point of contention with Clojure? It's a Lisp, so sure people will love it or hate it, but I hadn't heard this criticism directed specifically at Clojure until now.
As someone who have tried clojure a little bit after it was launched , but after a while dropped; my personal view is that Lisps are great for small stuff, but once you need to go for something bigger, with big teams, the thing start to melt down.
And here is where OOP shines.. The probable "winners" of the languages of the next decade will be OOP ones that glue well with functional techniques and functional languages that are very good at OOP techniques.
F# is really good here, and from the OOP side C# and Java are also running for this trophy (again).
Maybe swift.. but we need to see if the adoption will have a limit, given its tied to a closed platform, and its also closed source
(But Rich Hickey is a bad ass and the framework design behind clojure is a piece of art)
> but once you need to go for something bigger, with big teams, the thing start to melt down.
The people in the Clojure community have already started exploring this issue. Component [1] [2], Jig [3], and others are trying to add just enough OOP back for the reasons you mentioned.
That is quite a while ago, back then it was mainly one guy who write a compiler, by kmow we have a awesome build and project tool, pretty good editor options, CSP, logic prrogramming, static typesystems, awesome validatiin librarys, a fantastic pattern match ...
In terms of organisation, I would suggest looking at the 'components' library, it takrs the good things of OOP design for things like managing services. Clojure has great namespaces also.
Well, thats my personal view. I suspect thats how lots of people feel too, given it has not seen any major adoption despite being relentlessly hyped for last couple of years[1].
Also, F# is already in top 20 with relatively little fanfare.
Nor is Clojure particularly aimed at the TIOBE audience. So they're both pretty useless metrics. But it is disingenuous to say Clojure has reached a mass adoption when it's one of the most popular languages on an OSS site. That it said not popular 'in the enterprise' or 'in the business world' then I'd agree.
There's some selection bias here. Github will promote languages that are classically open source friendly - or have a heritage in open source. Languages like Ruby, Javascript and Java will naturally feature higher in such popularity shootouts.
This may not be the case in the world of enterprise, closed-source software.
F# won't draw especially draw people away from those three languages though. It doesn't have the sort of type system Scala and Haskell people love, it isn't a Lisp or dynamically typed so most Clojure people won't care, and it doesn't work with Java so it won't draw people away who are using Scala on top of older Java systems.
I'm no expert, but I have the impression that F# has a strong type system, being an ML variant (perhaps sacrificing a bit for CLR compatibility).
I'm a big fan of Clojure and a dabbler in OCaml/Haskell, and I feel that F# has a lot to offer in terms of library access, same as Clojure/Scala for the JVM. In any case, I'm certainly happy its there in case I ever have occasion to work with .NET.
Doesn't Linux have a relatively close relative to F# in OCaml? Which has had some successes, like on top of Xen and at Jane Street, but as far as I can tell has taken the world less by storm than your other mentioned options.
F# is very close to OCaml (each language has a few features the other doesn't have). I love OCaml, but Visual Studio's F# integration is why I use F# now. The tooling for other functional langauges has seemed lacking to me, but having a legitimate debugger and intellisense and error highlighting as I type has been a delight.
I actually find Scala quite pleasant to use. What aspect do you find it being too complicated?
I've seen Scala code styles within a wide spectrum of OO <---> FP, which can be both positive and negative. My only complaint, is that compilation takes longer than Java code. I learnt to live with it for now, and I am sure the Typesafe team are working hard to address it.
I like Scala, but it seems like it tries too hard to accommodate every possible programmer. If you stick to the OO side of Scala and avoid FP then it's similar to Java. Add some higher order functions to the mix and you'll get a mixture of OO and FP that dynamic language users will love. If you don't like higher order functions then you can sugar them with for-comprehensions, and suddenly it looks familiar to Pythonistas. Pull in Scalaz and now you've got monads, monoids, applicative functors, and all the other goodies you'd hope to have in Haskell-like languages.
On my team we've got a mix of backgrounds. We've got people who've done Java, a gaggle of diehard Pythonistas, our CTO is a badass Rubyist, and I can't seem to shut the hell up about Haskell. Our Scala looks like it suffers from multiple personality disorder at times.
Scala: we like you. You don't have to try so hard to impress us. Just tell us how you really feel instead of trying to figure out what we want to hear.
Clojure is beautiful. EDN is beautiful. I've honestly never known anyone to start learning Clojure and not become enthralled with its syntax.
I don't even use Clojure outside of Riemann for work but when I was learning Clojure the more I learned the more fantastic I felt it's syntax was.
I have also started investing a lot of my spare time into learning F# which I also really like. It's my first ML and the aspects that assist with domain modeling are fantastic(discriminated unions, option types, etc, etc). Fsharp interactive opens up a lot of possibilities too. While I like it's syntax better than Scala's and it's very terse, it still just bolstered my opinion on the elegance of Clojure.
This is a pretty weird opinion. How could the idea that F# "delivers where other functional languages didn't" be anything but strange Microsoft hype? or is this a joke?
The existing functional languages (which also notably include ocaml and common lisp on SBCL), "on linux", happen to also run on OS X, BSD, and some of them on Windows too. Could you really think those all suck, but F# is great?
Respectfully, there is a difference between "It is feasible to compile an executable" and "has industry grade support and tooling".
If we discuss just tooling on windows, I heartily concur with the assessment that "F# delivers where other functional languages didn't".
I've tried those other languages. I've not yet met anything that would compare with the integration in Visual Studio with the F# command line, project tooling and the .Net ecosystem.
Unfortunately I've not tested F# on my Ubuntu boot, but on Windows as functional languages go it is an absolute joy to develop with. Clojure's toolchain comes pretty close, but not quite. For example, FFI to C is much nicer in .Net.
Whatever the overall company culture may be, Microsoft actually has lots of bright and well intending software folks working for them, and F# is clearly a labour of love brought to fruition there.
Sorry, I was a bit imprecise. I was thinking only about basic stuff like list operations being supported in the basic syntax, algebraic datatypes, pattern matching and optional mutability.
F# was developed from day 1 as an industrial tool. The point is to bring the practical stuff from those... ahem... 'arcane' languages to a platform with industrial tooling and an existing ecosystem.
F# can be used almost exactly like C#, and the ML-features can be used once understood.
While F# encourages immutability it can be used as a mutable language which means lots of familiar algorithms are easy to implement in it.
Downside (on UNIX) will be that it fits in less with the UNIX philosophy than OCaml or Haskell will (though, with AOT compilation it will probably get closer).
That's different than Haskell, sure, but in exactly the same way virtually every other ML-family language -- including Standard ML itself -- is different from Haskell.
As a .NET developer, I've oft complained to my coworkers that years and years ago, a Java program could be compiled and run as a desktop app, or in the browser as an applet, or theoretically in other contexts. Microsoft kept not figuring that out, requiring different and slightly incompatible libraries (say, between WPF and Silverlight). It drove me crazy. Same with WPF and Windows Phone.
I see this kind of motion as very positive and recognition that horizontal re-use is a desired feature (one of the reasons people like node.js).
The nuget package versioning/app local deployment model introduces a very different model for security patch distribution. Microsoft got their fingers burnt a few years back with the 'embeddable' SQL Server distribution, MSDE, when the Slammer worm hit and there were hundreds of systems redistributing MSDE which had to figure out how to deliver patches separately.
When .NET applications all share the installed .NET framework, all applications benefit from Windows Update patch distribution for .NET Framework fixes. But when all applications are distributing their own required versions of dozens of .NET core nuget packages, those patches won't be deployed until the app developer updates the nuget reference, rebuilds and ships their own patch.
Will patches be installed on servers that have never run the application but have it deployed, such as DR servers?
The mechanism describes seems to imply they won't as Microsoft Update won't know the vulnerable assembly is sitting on the machine waiting for a failover.
If they are using semantic versioning, like they say that they will be transitioning to, a developer of a package could specific a major and minor version of .NET, and the latest patch version would be automatically grabbed.
This would allow updating a package's .NET Core dependency, as long as it's a functionality or security patch, without breaking anything inside of the application. Just speculation though :)
It's per-package semantic versioning, not one big version for .NET Core. So you could have an app which has dependencies all over the place - old versions of some packages, new versions of others. Say you have application A, uses System.Foo version 3.4; then you have application B which uses System.Foo version 3.9. They're both old apps, the current version of System.Foo is 3.12. Now we find a security hole in System.Foo going back to version 2.3. MS is going to patch and release updated versions of every one of them, in case some application is still using 2.3?
It's not much different from the situation with statically linking C, is it? This argument was the exact one MS used over a decade ago explaining why they couldn't ship a linker for .NET. (And 3rd parties, including MS employees, stepped up to fix it.)
On the flip side, there's been few (none?) exploits involving remote code execution, except for loading code from untrusted sources. The other large ones that come to mind were a few ASP.NET security bypass issues.
So it's not like, say, someone statically linking JPEG reading code that allows code injection. It could be, as nothing stops unsafe code being published, but it's far less of an issue with managed code than MS has made it out to be.
It's also no different than the state with many bin-deployed libraries Microsoft has shipped for .NET in the past. But this is a radical change to the way .NET developers have to think about their dependencies on the .NET platform.
"Critical security fixes must be deployed quickly and holistically in order to be effective. We are fully committed to making security fixes as we always have for .NET."
So they apparently have some approach for this, but didn't really say what it is. It'll be interesting to see how this works - some form of machine-wide assembly redirects, perhaps?
I believe that they already have a solution and have already used it[1].
> This is the first release from Microsoft that uses Security Updates for .NET NuGet Libraries Support. This feature enables Microsoft to update app-deployed .NET NuGet libraries, for machines with the .NET Framework 4.5.1 or later version installed. This security bulletin was released on 10/14/2014 as part of the monthly “patch Tuesday”.
I hear that they still plan to have a mechanism for patching zero-day vulnerabilities. Don't know how exactly, but a slide in one of Hanselman's talks mentioned it.
The complexity of the .NET ecosystem as revealed in this article is baffling me.
And I don't even have the excuse of being in foreign territory here, I'm a C# dev since 2009.
The language itself is easy to learn, but understanding everything behind is quite a challenge (at least for me). I guess it's a feature of enterprise products.
Sometimes I wish I could leave work at work and not have to stay on top of my domain of expertise in my spare time.
Does anybody know it all? It's almost as vast as the Java world. A friend of mine is a C# web dev, they didn't know what I was talking about when I did WPF. I used Xamarin, but I don't know a hoot about Sharepoint.
I feel like most good Software Engineers realize this, sooner or later. I honestly don't know what the answer is.
Some move into management, others just leave the field for something else.
But I do know that this itself probably justifies the salaries that they're paid.
I'm psyched for the changes in the way .NET applications are being deployed. NuGet was already a great step, and having a well-factored .NET core framework in NuGet is only going to make it better.
Even little things like renaming the NuGet packages so that they are the same name as the assembly (hopefully "System.Web.Mvc" instead of "Microsoft.AspNet.Mvc" or whatever it is now) are a good sign to me that this push to create a cohesive .NET ecosystem around NuGet might actually succeed.
Unfortunately at least at our company this will take a long time to be fully embraced, but I look forward to the day when you can update the version of System.X that your team depends on without making it a system-wide upgrade initiative to move from one version to the next.
I have to say I'm very impressed with how ms is keeping .net a relevant platform. A few years ago, I started to worry that I was going to have a skill with a rapidly declining market value. While I still believe that being a polyglot is the best way to mitigate this risk(as well as just general professional development), I do feel like MS is taking great strides in keeping.NET developers employed.
I have my doubts. MS is clutching at straws. They should have fired Steve Ballmer a long time ago and this should have happened in 2006 - 2008.
Python/Ruby(and Rails) and node are probably deeply entrenched in developers minds by now. It seems company managements never learn. Developer mindshare is probably lost by now, my bet is, this is not going to save .net
I think that is the difference- I personally have never even seen a ROR site in any of the enterprise settings I've worked. I personally have written some tooling in Python, but its FAR from a standard or common language in my experience. (I have consulted at probably 40 different companies from Houston to Buffalo NY and many places in between.)
For the type of work I do, its .NET or possibly some Java. Web dev is using some flavor of ASP.net or maybe some mostly static php. Working in Etrm, you are going to use C#, java, or possibly C++ when the situation calls for it.(And a few enterprising companies want Obj-C for their BYOD iOS devices) Granted, this is my personal experience, and this is something that every developer can get myopic about. Development has an enormous breadth to it. Sure the Bay Area/startup scene may be all about ROR, but from what I have seen, its not something that gets used in medium to large businesses...
I don't want to sound conflictual but many Java/C* professionals use tools written in Python and Ruby daily. I'm thinking about Bitbucket (Django) and GitHub (Rails). They seem to work well enough.
"we’ll make .NET Core great for Windows, Linux and Mac OSX. This also enables the Mono community to innovate on top of the leaner .NET Core stack as well as taking it to environments that Microsoft isn’t interested in."
Seems like a pretty clear split - MS will cover the server-side + Win UIs, while Xamarin handles the other plats (IOS, Android, PS4 etc).
This plays to the strengths of both companies, and I would not be surprised if MS has some security in place - e.g. some kind of first option to buy Xamarin should another suitor come calling.
I doubt they would want to directly compete with someone who is 100% focused at that market and is already in a partnership with Microsoft. It just doesn't make any sense for them.
tbh I wouldn't be surprised if Microsoft just flat out bought Xamarin eventually.
Yeah, I was hoping they would pick them up sooner rather than later. I really like working with Xamarin, I am able to work in C# and share >75% of my code between iOS and Android but I am hamstrung using it on my own projects and it can be a hard sell to use it on commercial projects.
"I suppose the Xamarin guys need to eat but it's kind of disappointing they are not directly targeting iOS and Android".
Exactly! Clue #1: full Android emulator/debugger built into VS2015. Clue #2: Rosylyn and .NET native. Clue #3: Carving up .NET core into separate chunks for smaller deployments.
Maybe Xamarin was just a beta test for the real thing?
I constantly have issues with "Package Restore", where I need to restart visual studio or clean packages and reinstall them. Sometimes, my package.config will end up with multiple same package with different versions. I get a lot of those problems with MVC.
I like C# and static typing, but I prefer nodejs and npm when it comes to packaging.
The ASP.NET part is what has me excited - it wasn't clear from the article (it may be due to my limited knowledge of the ASP.NET stack) but if I could write a full fledged ASP.NET app on Linux using the often needed features like ORM, LINQ, whatever the equivalent of JSF is - that would be a great development. Right now on *NIX platforms nothing matches the maturity of Java/J2EE.
It still remains to be seen how much the of the tooling - debuggers, profilers, deployment tools etc. will be available on non-Windows platforms. May be that will become available as more and more people start using it in Production.
My understanding is that .NET core will not include tooling. This project's focused on delivering a framework only, the Open Source Community (Mono Developers in this case) will take care of the rest.
Now, Xamarin has been doing a good job of creating beautiful and powerful tools, so I assume the tooling will be really good. Hopefully one day we will see Visual Studio supported by Microsoft on Linux and Mac.
But I also hope other providers, like Jetbrains step up to make .Net amazing on Linux and Mac. So either way this is amazing.
This is a great resources, thanks for sharing. I usually use Xamarin Studio and Emacs in Linux and Mac. OmniSharp integrates with Emacs, that is pretty cool.
I think Microsoft will have to step up as well - they have an incentive to do so - Azure. If Azure becomes a #1 platform for people wanting to deploy ASP.NET web apps on Linux they will see some real traction if they make the tooling solid.
Otherwise sadly this will be just another niche, also-have thing.
I haven't used Microsoft products full time for... nearly 9 years, now. But if Visual Studio was supported on OSX/Linux, I'd switch to using it (even paying for a license) in a heartbeat -- it's an amazing IDE, and for some features it's unparallelled.
Visual Studio is not just an IDE and a Debugger. It has a Performance Analyzer, Code Coverage for Tests, Dependency Analyzer, Diagram Tools, Concurrency Analyzer, Javascript Analyzer, among others. VS is the complete package for sure.
I really wish for better Desktop App support. Many of the Windows applications I miss on Linux are written in .NET and running them with Mono looks terrible and often has a few problems. Or maybe I'm just silently hoping that 2015 is the year of the Linux desktop and it's sponsored by Microsoft.
A port of Xamarin Forms to Linux would make this possible. I hope someone would pick this up. Over time this could enable a single UI technology to target native UI's of all major desktop and mobile platforms.
With all this open sourcing and moves to address other platforms I've wondered if MS will soon roll out some kind of harness or wrapper app that can be used to host WPF built desktop apps on Linux and Mac.
If they ever decide they need Visual Studio to run on the Mac then I'm sure WPF would come to the Mac. Other than that I think they have given up on it.
Currently if you include xamarin, .net is among the best platforms if you care about cross platform development(with the ability to deploy native apps). And i don't see anybody who can replace that in the near term.
> ...is available as open source, and is supported by Microsoft on Windows, Linux and Mac OSX.
Somehow, the words Microsoft, support and Linux still don't seem to sound right in the same sentence.
I'd been your stereotypical Linux fanboy and MS hater since a teenager. But today I'm totally awed by how radically Microsoft has managed to change itself. I can't even imagine how hard the people inside Microsoft must have fought to make this happen. Well done, guys.
I really hope somebody starts a kickstarter for Rails 4.2 on IronRuby (based on .NET Core). I'm really keen to see how that will compare with JRuby (which is already quite good).
The biggest problem which I see with the .NET ecosystem is the lack of appliction servers like JBoss, Tomcat, Wildfly.. even Jetty.
Am I wrong or is IIS pretty much the only .NET application server ?
With OWIN[0], you can use any application server you want that supports it, there seems to be 5 as of now, including IIS and Kestrel (a dev server that runs under Mono) which aren't mentioned on the OWIN page.
IIS, though, right now is the de facto server for ASP.NET sites.
I know lots of people don't care about Windwos Forms anymore but it would been GREAT if they were also included in the Core, may be re-labeled as just "Forms" with as many platform independent goodies as possible. Native desktop apps are no longer for consumer at large but I keep finding myself developing new desktop app every now and then for development tasks. For example, right now I'm working on desktop app that allows you to quickly browse, slice and dice very large data files of order of 100s of GBs. It would be nice if I can release this kind of apps for all platforms using .net.
PS: I don't want WPF in Core. It's over-engineered uglyness I care lease about.
Winforms has a lot of really counterintuitive and cumbersome widgets. It's well-known and traditional and straightforward, but there's too much MFC baggage in the various widgets' behavior. The data-binding system is a mess, the DataGridView is utterly dire... so many simple things are just such a pain.
Unless you just want to throw some textboxes and buttons on a screen, it's just not good. I mean, ever do some dynamic forms and run out of window handles? Really?
I started working at Microsoft in 2007, and so have never been exposed to Winforms. It seems archaic to WPF, which can do almost anything. I don't bother with high level WPF widgets however, and mostly just roll my own because it is so easy to do (plus my interests usually require custom widgets).
I've been finding WPF development very slow going, I know this is partly due to inexperience but I suspect mostly because WPF and its tooling is not polished enough.
In particular I find myself diving into the XAML all the time, whereas I hardly look at the generated code in my WinForms application.
That was my experience with WPF as well - I would far rather use Winforms. (n.b., if there's a library & GUI designer for the web that emulates Winforms well enough, I would love that).
Sadly, there are some circumstances where XAML is virtually inescapable (e.g. constructing templates; you can use the deprecated FrameworkElementFactory, but it's pretty ugly).
Right, I'm well aware that he agrees with me. His posted ended with 'How is that plagiarizing?', a statement that he already knew the answer to (the answer being no). I was continuing the thought. And agreeing with him.
Except they did follow the "license". Specifically,
>> as long as you tell people where they're from.
Which they did. They even included the URL of where it was inspired from.
And even so, it's not up to you to determine what follows the license and what doesn't. It's up to the author and his lawyer(s). Microsoft may have already asked for permission to do what they did, none of us know that.
Furthermore, "not nice" would have been not linking at all. What was done is not "not nice". It could've been better, sure, but it's perfectly okay as is.
When Firefox was version 0.9 (2003?), I said it would take a large chunk out of IE's 95% market share and IE would become an also ran browser. I also said, later, that iPhones and iPads would take over mobile and dominate the internet and Google would be more important than Microsoft on a day-to-day basis.
In both cases I was made fun of and downvoted into oblivion.
So listen to what I'm saying now. In three to five years, none of you will be using .NET anything. Well, some of you will be maintaining legacy stuff but, new things? No. Especially in five years, no one will think of doing any new project in .NET anything.
As I said back in 2003, write it down. Check back with me. I'll see you then.
Well, it appears that in both cases you were wrong. IE still has higher market share than Firefox, with Chrome being the clear leader it seems (though some usage stats may show otherwise).
Even today, Microsoft is far far more important than Google for their users - not necessarily developers. If Google disappeared tomorrow, yes it would make it a bit difficult to work in the short term, but people will manage. If Windows / Offce were to say, vanish tomorrow, then millions of businesses will just collapse and cannot function at all.
Loyalties are cheap on the internet. You can say "no one cares about X". Just look at all the companies that switch between AWS and Azure these days whenever one or the other has an outage. Microsoft is making aggressive moves now.
.NET is a technically superior platform to almost anything else out there. True developers tend to gravitate towards what is the best. To see where .NET is heading you really need to look at Xamarin.
You act like you are the only one to have made those original predictions (re: IE declining market share, and iPhone being a big shake up to the status quo of the time). You weren't. Nobody else apart from you seems to be acting so blasé about predicting the death of .NET. To the contrary, most are thinking on the opposite end of the spectrum. F# is gaining a large amount of traction now (just look at its advance on the TIOBE index). As is Xamarin. As is Azure.
Java is dying a slow death at the hands of Oracle. None of the recent "improvements" to its core language were done correctly . Just look at their type erasure of generics. And their bastardised implementation of lambda expressions. .NET will serve as a natural destination for all those increasingly alienated developers and companies using the Java stack.
.NET was a huge advantage when it came out compared to anything else. Faster than Java, easier than C++, etc.
Now there is not as marked an advantage. There are now so many great frameworks and languages to choose from, and alternative languages for frameworks. There isn't much competitive advantage for .NET in the longer term.
Silverlight, from a development standpoint, was actually pretty great. You could write code in .NET with an infinitely customizable vector-based user interface, defined in a clean and consistent XML-based markup language. It could run in a browser, and even on a Mac.
You could develop using all the powerful Visual Studio tooling. It didn't crash all the time like Flash.
Using Silverlight and XAML was sort of like what I imagine web programming will be like in about 10 years. Except that you could do it back in 2007.
You have a high level language (C#) with reusable components (UserControls) and fantastic debugging, profiling, static analysis, and automatic refactoring.
Incidentally, that is where the web is just now heading. Higher level and strongly-typed languages (AtScript, Typescript, Flow, ES6+) with reusable components (Web Components) and better tooling (Firefox and Chrome dev tools)
It would have been great but they didn't follow through on their cross platform commitment.
They never have in the history of their company so I'm not sure why people believe this time they will. Open sourcing the core guarantees nothing if they move the Microsoft support at a faster pace and don't commit to keeping the other platforms at par.
Mono is a great community effort, but the server side has always lagged Windows pretty heavily. Having the same level of API and implementation support at a core level on Linux will be awesome.
Shall be interesting to see how this affects IIS market share in 5-10 years time.