Introducing .NET Core
blogs.msdn.com
blogs.msdn.com
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.
Well OWIN supports self-hosting so perhaps this will not bode well for IIS outside of enterprise environments.
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.
https://www.mail-archive.com/ozdotnet@ozdotnet.com/msg11187....
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).
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.).
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.
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.
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.
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.
For more info, see
http://www.asp.net/vnext/overview/aspnet-vnext/aspnet-5-over...
http://www.asp.net/aspnet/overview/owin-and-katana/getting-s...
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.
You don't need to convince me that PHP is a clunky, unpleasant language. My point is that there are still legitimate reasons to choose it.
Symfony 2 is quality engineering. It's quite nice just to browse the source.
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 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?
Because that shit gets the job done. Pick the right tool for the job, sometimes PHP is the right tool.
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.
This year, I put a thirty-five dollar C# book on my holiday wishlist.
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 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.
This already rules it out from our projects, due to the way our customers manage their IT stacks and development environments.
So I don't need to ask permission to several IT departments to have C# on our projects, but I do need to do it for Scala.
I decided to never do Java again, and until now I have zero complaints, because I have plenty of offers to pick from.
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.
https://www.reddit.com/r/programming/comments/2iszra/ceylon_...
Have you built any production ready apps or libraries in it? How was the transition from writing Java? Did anything cause you pain or surprise?
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).
Ceylon doesn't have enums but you can emulate them like this: http://ceylon-lang.org/documentation/1.1/tour/types#enumerat...
Otherwise it's fairly straightforward to translate java into ceylon.
I love immutability by default. Only 10% of my variables/fields are actually mutable. I could reduce that percentage further if the jvm had TCO.
Erasure is necessary when the type system is differently expressive from C#, which I beleive F# is.
Brian Goetz - Stewardship: the Sobering Parts
You can write stored procedures in .NET and Java instead of the engine's own language. Or extend the engine with new functions.
Most of the commercial SQL servers allow this.
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
Please don't hold your breath. Millions of programmers die every year from hope-influenced asphyxiation.
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.
Also, F# is already in top 20 with relatively little fanfare.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Rank 19. Clojure Rank 46. F#
Source https://jaxbot.me/articles/github-most-popular-languages
FWIW on that TIOBE list Delphi/Pascal is listed as more popular than F#.
This may not be the case in the world of enterprise, closed-source software.
Most of the enterprise projects are not even using Git!
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)
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.
[1] https://github.com/stuartsierra/component
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.
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.
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.
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.
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.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).
In Europe yes.
Check Skills Matter webcasts, Norwegian Developers Conference or Øredev.
It is mainly used at financial and insurance industries for data modeling and big data.
This is why type providers were so big for the language.
> Microsoft refrains from telling people "you should use F#" which is good advice for all but the most terrible of enterprise environments.
I already saw some presentations where this was explained as not wanting to scare the traditional enterprise guys.
I kind of understand them, for our customers JVM == Java, .NET == C# or .NET == VB.NET for projects that used to be VB 6 shops.
So how to sell F# to these guys? By making it easy to integrate into their exiting code, as library code not full stack replacements.
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
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>
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>) // okI'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.
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.
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?
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.
I would say F# is an implementation that includes all the good parts of Ocaml the language and .Net the ecosystem.
Very good tooling. A feasible multithreading story. Industry level support.
A pet of mine: Has ecosystem support for real time graphics (OpenTK, Monogame, etc).
I like F#, but this just isn't true:
- Polymorphic variants
- GADTs
- Module system
The last one, in particular, is one of the best features of OCaml.
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).
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.
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.
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).
.NET 1.0 allowed it, but very few people ever used it.
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.
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?
> 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”.
[1]: http://blogs.msdn.com/b/dotnet/archive/2014/10/28/asp-net-mv...
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 :)
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.
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.
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.
But I do know that this itself probably justifies the salaries that they're paid.
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.
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 every professional developer is happy when all the hipster kids moved to those platforms.
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...
https://github.com/Microsoft/referencesource/blob/master/LIC...
"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.
tbh I wouldn't be surprised if Microsoft just flat out bought Xamarin eventually.
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.
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.
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.
Otherwise sadly this will be just another niche, also-have thing.
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 think I'll pick up a C# book for Christmas.
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.
Could you describe what non-Windows OS stack works with .NET. Can I use MySQL/Postgres with it ?
PS: I don't want WPF in Core. It's over-engineered uglyness I care lease about.
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?
In particular I find myself diving into the XAML all the time, whereas I hardly look at the generated code in my WinForms application.
This is why I never liked frontend web development, it is such a pain compared with what native toolkits are capable of.
Maybe webcomponents will finally fix this.
You can write things like button.Left = label.Right + 20 and it will synthesize the data binding code automatically.
As far as doing GUIs? The golden standard is Delphi, and from the MS camp, Visual FoxPro.
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.
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.
.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.
I spend my nights coding in Ruby!
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)
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.