Honestly, I’ve been amazed at how good the tools have been. For cli and serverless dev, it’s been surprisingly great. It’s fast. C# is decent. The cold starts are not as fast as go, but not terrible. Memory usage is low.
It’s been a legitimately positive experience. When I started the port I was skeptical, but it is legit cross-platform. I would consider starting a project in it for lambda... I never thought I’d say that about a MS product.
Something over there is different, and I suppose it has been for awhile. I think it could get a lot more popular as non-ms devs realize that MS has built dotnet to work really well on Mac/Linux cli, far away from the weird tightly-coupled Windows/VisualStudio-hit-f5-to-do-the-magic-with-the-15-billion-auto-generated-magical-xml-files world. It feels well engineered instead of thrown together, which is nice.
Also, So far, I’ve pulled in no external libs other than the AWS sdk for the port either. C# with linq is a pretty complete toolset. I’m sure I’ll pull in more as I get more familiar, but it’s been solid on its own. Really nice surprise.
I've been keeping up with the latest developments, and it seems that they're finally starting to address the problem with tiered compilation stuff, which is fantastic. However, for now, waiting for 5+ seconds for a simple controller method to fully complete on a first post - with no way of auto-warming up (without using major hacks) on startup is just not acceptable.
Again, I really love .net, and contribute a fair bit to Signalr (core) myself, but feel this would really need to be addressed in an easy-to-integrate manner before it can be an absolute top tier language. They're addressing the other elephant in the room and providing a single-execuatable runtime-agnostic deployment option soon as well...which is amazing!
Overall though, for a language, you can't beat C#/core in my opinion and would 100% recommend it.
Disclaimer: I work on performance in the ASP.NET team.
To explain this a bit better, i'd definitely be happy even waiting 10+ minutes for all of my controllers/hub methods to be instant response. I could then subscribe to an event when it is ready and let haproxy/nginx or whatever else know that the server is "good to go". This way, the server goes into the pool, and everyone is happy. I remember seeing that the Bing guys did something like this, but again it was majorly hacky.
Thanks for all the great work you're doing on C#/.NET Core in general by the way.
We've had tiered compilation enabled since it came out as an option, but the first requests are still dog slow
I haven't built any production code in VS Code or .Net Core yet, but have started analysis for converting legacy .Net applications. I've also had interns doing some prototype work in .Net Core using VS Code, both on Macs and PCs. So far, so good.
I also used VS Code to do some React development. That worked out well also.
At this point, I'm hoping to get the legacy solutions converted in the next year or two, ditch my MSDN subscription, and move to VS Code full-time. Right now, I'm on a Mac, and running VS in VMWare.
C# is a lot better than Java. You have less boilerplate code (getter and setter in 2018, really?) and lambdas are great.
But really both are similar so you can pretty much just start with one and still find your way in the other.
Indeed Java has more boilerplate, but honestly I've never been bothered by it (as you can generate most within your IDE) and because its explicitly written down it can make code more readable.
And Java also has lambda's.
more text to read does not means "more readable", it means more effort to do
not always the case, but you can't argue that "less text is more readable" any more than you can argue "more text is more readable". what you want is, "just the right amount of text" which will depend on your tastes.
The bigger reason is one word: Oracle
Whether you go towards C# or other companies... Oracle is a horrible company.
That reminds me, I want to experiment some with AOT compilation and also the new GC plugins.
If it isn't, do you know (by chance) about some resource(s) for a total newbie/newcomer to the language?
thanks in advance.
Overall, the language feels pretty nice though.
Disagree, especially on the same level as the others with D, and especially concerning cross-platform ecosystem with Swift.
An example. If you want to use .Net Core you can't use entity framework, you have to use EF Core, which doesn't yet support mapping to views or stored procs, only tables.
Now you might think that's fine, maybe you only want to map to tables. But it's the same story all over the ecosystem. Many major projects have a separate netfx and core package, and many times the core package has restricted functionality. You will almost certainly find a whole host of things you need are missing.
And then you get the fact that ASP.Net Core is dropping support for .Netfx in the next release, so if you want to use ASP.net Core you are now limited to EF core too, which means you are making a full jump and can't just go halfway first. And .netfx is now not going to support .net standard 2.1.
The list of incompatibilities and restrictions just goes on and on. I certainly can't keep the full list in my head. So right now I'm not really willing to commit to a new project of any significance on .net core because I know there will be dozens of missing dependencies or features.
You could argue this is just want it's like at the cutting edge, and the gaps will be filled in time. But .netfx is clearly already going into maintenance mode, so the push to move to .net core has already started.
That's your only specific example - what other functionality are you missing?
You're not willing to commit to .NET core but you admit that NetFx is going into maintenance mode?
SQL Aliases don't work. So people have to put in registry hacks into C# code (YAY back to 2002).
Loads of missing functionality (e.g. GeneratePassword is missing in aspnet core).
It is just incomplete. .NET 1.0 was more together than ASP.NET core and that was in 2002.
We've lost loads of functionality in the spurious benefit of it running on multiple platforms. I was developing ASP.NET on Linux 5 years ago.
It is more churn and burn for the small amount of devs that use dotnet without Windows.
It's a pretty serious project, and for us, the benefits of our developers being able to natively develop on Macbooks and being able to deploy to Linux containers outweighs missing features.
Swings and roundabouts...
EF isn't a necessity, many shops prefer not to use it at all.
Core is the future so if one wants to keep using .NET at all they should find a way or switch to something else.
At least this one is not true: https://docs.microsoft.com/en-us/ef/core/modeling/query-type...
Again, I think C# is a great language. I just feel a bit decieved about what .NET Core and .NET Standard are capable of. If the version number matched the capability I would probably be excited.
EF Core has a lot of work that needs to be done (and features brought over) but for a lot of use cases, it works just dandy. I don't disagree with your comments about incompatibilities and restrictions - just wanted to set the record straight.
Everything is so low level and so unproductive it's silly, and the only redeeming features was how well it integrated into the windows setting. But now with 3.0 they're removing every non-core library, meaning, it's really not a good choice.
I'm sure it's fast, but if it takes longer to build and deploy, then it really doesn't matter to me. We can buy more iron a lot cheaper than we can buy more development hours after all.
And I agree that it's not ready, I wanted to do a quick hobby thing on my Mac, and despite the development environment working well with VSC (as good as regular visual studio really) it's just terrible to run. .net watch breaks on Mojave, and despite issues on the GitHub there isn't a real fix in sight.
Needing to reboot every-time you stop your development server for it to free the .net resource correctly is just silly.
And that's not to speak on entity. If you've ever tried Django and migrations you'll probably never work with entity again and not hate it. In face, entity is unproductive we've stuck with LinqToSql for a long while, yes I know it's slower, but who cares if I save enough development hours to pay for a thousand years of server time?
Btw, we use .NET core in prod, but we have weird DB access through a third party API, so I didn't need to think about data mapping.
It is still not clear if the design tooling will be migrated and DB drivers also need to run on .NET Core.
Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none, but this subconscious constant selling of their own tools sickens me slowly.
> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense. Either offer equal tools for all major tech or none, but this subconscious constant selling of their own tools sickens me slowly.
Of course they support their own tools, but you don't have to use Visual Studio, you can use VS Code if you like. But I can understand why people like Visual Studio - live unit testing alone is reason enough to use it.
And this is a scenario where your company can get an 80% discount (not sure this is doable) plus Resharper has a perpetual license you can keep after 1 year, just without updates.
I've made an account because this attitude irritates me.
1. This is patently untrue. The real reason is that a large number of developers simply have more important things to do (friends / family / children etc) than learning whatever is considered in fashion. Scott Hanselman even has a name for these developers "Dark Matter Developers".
If you have 10 years of experience working with .NET and all the parts that normally come with it, it makes more sense to keep within the ecosystem and keep up with the changes in the tooling if you want to stay up to date. There isn't much benefit for most people to look outside of it.
I've personally got sick of things changing every 3 months and build almost everything exclusively using full fat .NET because I know it isn't going to be gutted and changed in 6 months time unlike .NET core. It has also 16 years worth of development and documentation behind it. I don't need to spend half a day trawling through stack overflow posts.
2. Most software that is built in .NET is intranet software that will never be seen by the public. It is most likely hosted in a server rack in the basement. Almost 90% of the problems when developing in these places is internal politics, poor IT infrastructure spending and abhorrent legacy code. I could probably list another hundred common problems.
The whole point of VS is that you shouldn't have to go outside of the IDE very often. Thus why wouldn't Microsoft offer tight integration. If you don't want to see the tooling, remove it from your VS installation or use one of the many alternatives now (Rider, VS Code or setup your editor with Omnisharp).
I've worked in a variety of shops, both "Microsoft" shops and non-Microsoft shops, and I would most certainly agree with the GP That Microsoft shops tend to be dominated by developers who like the comfort of just eating whatever pablum Microsoft is serving, often even if that pablum will take years longer to digest than competitive alternatives. There is, in general, a tunnel vision that profoundly limits the options available to build solutions, at substantial project cost.
And it's understandable. If you're at a Microsoft shop you aren't going to challenge the norm if your first choice is SQL Server and BizTalk and Azure, etc. It's the easy, laziest option. Occasionally it might be the best option, but that's just accidental given that the choice was predetermined.
That's what Microsoft's core customer base cares about.
I dunno about this. The vast majority of costs in any project is contractors / staff rather than licenses.
I added up the cost of hiring 3 contractors for a month versus just buying a piece of software that did 90% of what the business needed. We were much more expensive.
> And it's understandable. If you're at a Microsoft shop you aren't going to challenge the norm if your first choice is SQL Server and BizTalk and Azure, etc. It's the easy, laziest option. Occasionally it might be the best option, but that's just accidental given that the choice was predetermined.
It is also kinda counter-productive for everyone else. If everyone knows how to do something in a particular language + IDE it makes things easy because knowledge can be shared without a steep learning curve.
e.g. I write lots of scripts using python, I mainly work in .NET shops.
I left instructions for the whole process on how to get the script to run for an adhoc support job I wrote 5 or 6 years ago. For whatever reason it broke (the db structure changed slightly). I have been in a lot of contracts since that job and it was just cheaper for them to call me up and pay me to fix the script than have one of their devs look at it.
The only reason I wrote it in python at the time was because I didn't know Powershell at the time and they said I could use what I wanted as long as it was documented.
I'm not sure if that is the original post.
There was a bit of backlash against it, someone even published a 5:01 Manifesto, but that site is not maintained any more :D
Hanselman is also one of those developers that can bang code out 24/7. I've met them. They can get a lot of stuff done, however there is usually someone like me that is picking up the pieces left behind.
Recently I worked with one and he banged out an MVC project, commented out all the tests I wrote after he changed the API I wrote and then went on holiday to Greece for several weeks and then was moved onto another project. Guess who had to clean up the mess ...
After a while you realise that it isn't worth the effort and just get a contract job where you earn twice as much and have none of the bullshit.
There are those argued that any innovation is unneccesary until MS launches a product for it, when it becomes a "must", ad nauseum. I'm talking about the developers who never discovered ORMs until MS pushed theirs, who let their products languish for years waiting for MS to address issues, and move lock-step with them on all fronts.... You've seen major motion with "Alt.NET" groups, and some pretty major internal revolutions based on the displeasure of community technical leaders (and their willingness/needs to hop off of MS solutions), that stem from this dissonence.
It can create some cross-purposes in their tooling when they're aiming at conservative C#'ers who want a unified MS experience and look at no other technical sources... Especially for the Enterprise devs, cloud-native architect, and cross-platform engineers who have clear needs that don't jive with those assumptions.
F# and .Net Core are the only reasons I'm still on their stack. It's a dream to work with, and addresses critical issues of cloud and distributed engineering that previously would have excluded MS and .Net from the discussion. Particularly with scalable cloud systems, OS licensing fees are often show stoppers for NGOs, non-profits, academics, and researchers
Although to be fair, they were taught this by Microsoft. Before Microsoft saw the writing on the wall and changed approach not that many years ago, the strategy was to provide a Microsoft solution for everything. Useful stuff from outside Microsoft would be either be cloned, or MS would simply not implement compatibility or integration.
The .NET ecosystem was, and still is, utter dominated by Microsoft at every level, unlike Java where multiple vendors provide implementations, innovations, certification etc. It's a bit unfair to blame the developers in the ecosystem for not pushing back hard enough against the organization that provided literally everything, from the software licenses to the professional certifications.
Because every ORM sucks outside of the ones built on top of Linq.
Linq is great because it makes a query language a first class citizen and it decouples writing the query and the implementation.
Linq => expression trees => provider => native query language of data source => data source.
Written correctly, you can pass expressions around like:
repo.Find(c => c.age > 65 && c.gender == “male”)
And the expression can be interpreted at runtime by either EF creating native sql or the Mongo driver creating a native MongoQuery or even an in memory List for unit testing.
No matter how good another ORM may be for another language, what made C#s implementation better was Linq + expression trees.
There was also another Linq/ORM I used back in the day for Postgres. I can’t remember the name of it.
However, my main complaint is not that they advertise their own products, which is absolutely fine, but the way how it is done is starving the .NET community from anything else but Microsoft. The way how all their .NET products are extremely tightly linked to a point where wanting to use something else but Azure or VSTS becomes almost unnaturally difficult, which is what I really dislike. For example, if I look at a nodejs product then I see documentation for all various integration points, with AWS, GC, Azure, etc., but when I look at a Microsoft library there is no documentation or integration points out of the box but Azure and that has a ripple effect on the rest of the community. Every library author only builds their tools optimised for Azure and don't even think about what else there is, which is quite upsetting.
They've made substantial efforts and improvements, so credit where credit is due. I think the broader .Net community needs to pull their thumbs out and take a hard look at why C# OSS has struggled the way it has, and how the ecosystem should be maturing.
The cross-platform, OSS-friendly, orientation of the F# community has been much more reflective of my technical concerns, platforms, desires, and predelictions.
So Google and Amazon should be scrambling to perfect the deployment plugins for VS.
True, microsoft is SELLING (some editions of) VS - but there I'm sure they weigh both demand from customers AND the potential earnings. If AWS and Azure features are equally in demand, of course they will focus on their Azure features first because they have benfits for Ms.
That's a pretty easy ask.
The built in support for GitHub is fine, so you can stop moaning about VSTS.
Also, you don't have to use azure or SQL server. You can close those tools and, poof, it's done.
One of the more ironic things is that there's a growing dissatisfaction with MS precisely because they're making it more flexible.
Lots of people just want stuff that works with no config, no mucking around with command line tools.
That MS are proudly going 'run dotnet blah' is actually, in a lot of ways, a bad thing. Why can't I just click a button, and why clutter tutorials with lots of pointless command lines?
The 'no hassle, no fucking around with shitty console tools' programming alternative is going away.
The problem is often trust. Like so many Microsoft projects, to me the goal of .Net Core seems to be to get as much people as possible on to a proprietary language and/or get as many devs as possible onto developing stuff that doesn't hurt Microsoft. There's no guarantee that MS will not pull the plug at some point, and then soon after that .Net and .Net Core will start to diverge, and MS will lure in as much devs as possible with proprietary functionality that everybody wants but is only in .Net, not in Core. Or they'll just pull the plug because of whatever reason, like they did with Silverlight and Xamarin.
Don't get me wrong, I kinda like C#. But right now .Net Core feels like it's been developed by Microsoft, not like it's open source. I'm not entirely sure but is looks like the community developing .Net Core is made up almost exclusively of MS people.
I looked for the stat to back this up, but I believe either AspCore or NetCore was one of the most active in terms of community pull requests for a while. I mean first, there is the sense that it _is_ open. If they do anything too evil, take it and fork it. You may say that is a huge undertaking, which leads to my second point:
In my day to day I don’t have time to contribute much to such a large project. Having the backing of a large company does present some issues, but it also lends some stability you need for a large project. This isn’t some mall pet project that takes off and fizzles. I feel the same way about Angular- I don’t like some of what they do- I prefer Vue- but can be confident it’s not _going away_ soon because Google backs it. In the case of .NET Core, though, even more so since it’s such a large part of core operations. So while even more community support would be nice, from a standpoint of trusting the product, it’s enough that it’s open source and the process is transparent even if dev hours are paid for by MS.
In the end, I think some distrust is valid, but some of it is kneejerk reaction to old MICROSOFT that is gone now.
This is my biggest reason for losing enthusiasm for .Net Core. Despite all the noise about open sourcing the development on GitHub, it still feels like Microsoft treats .Net like a Microsoft platform, not an open platform. And I'm not talking about Windows vs Linux. More that the design direction for .Net seems to be largely set by internal Microsoft politics. For example, the recent ASP.NET Core running on .Net Core vs .Net Standard decision seems to be driven by how tightly tied the .Net Core runtime is to its underlying OS.
Compare to Java with the JCP (because Java is often compared to C#). The JCP is far from perfect (e.g. all the drama with modules). But, regardless of my views of Oracle, when I'm using Java I don't worry as much that I'm tying the long-term stability of my tech stack to the whims of a single company (even with the new JDK licensing snafu).
On a side note, I'm really confused when I see people talk about how great the new tooling is. Sure, the dotnet CLI tool does more out of the box. But it still can get hairy very fast because of all the design baggage it inherited and shoved under the covers with the fancy new SDK abstraction. And Microsoft keeps cramming more and more complexity into NuGet which makes it a pain to integrate with third-party tooling.
Lastly, for the record, this isn't an anti-Microsoft rant. I think they've done a lot of great work with .Net Core---the standard library updates, cross-platform runtime, Roslyn---and I still am very productive writing .Net for my day job. Like I said, I've just lost my enthusiasm.
A good language is only part of what makes it appealing, having a large diverse open community is often more important as it ensures mature bindings are quickly available for new technologies and 3rd party API's, it influences whether the language will be used to create new technologies (instead of just playing catch up and making clones of what's in other languages), whether libraries are able to succeed on merit so it doesn't discourage the community to invest in developing a variety of competitive options and whether there will be an active community available to quickly answer questions and resolve issues.
.NET Core will never have the community of other popular languages, unless you're happy to use Azure and want to be locked into using Microsoft technologies there are much better platforms to risk your business on instead of committing to one whose future is controlled by self-serving interests.
I don't get all this hate against Microsoft because they suggest or prefer things they worked on as solutions, without actually tieing you to them. Do you work on software for years and then tell everyone to use something else?
If it was actually tied to their other services then I could see the reason to avoid it, but if using .net core without windows, azure, or sql server then I dony see how you are actually tied to it
Unless you want to be locked into a future centred around using Azure and Microsoft technologies, there are better, more open vendor-neutral languages with more diverse and mature libraries you could be building on.
Over half of the VMs running on Azure are Linux. Microsoft knows that the future is not selling Windows licenses.
Agree about the Windows licenses.
The C# compiler (Roslyn) is completely free and open source, as are a number of .NET components: CoreFX - Core foundational libraries, CoreCLR - runtime.
As well as PowerShell, VS Code, Typescript, ASP.NET Core, MVC, Blazor, F#, Z3 Theorem Prover, etc.
And that's from just the first few pages of their Open Source page: https://opensource.microsoft.com/
Do you people do any basic research, you know just googling or reading the license?
No. So far, only Microsoft has implemented the language spec and as long as no one else does it, no one can. Prove to me that "anyone can implement it" by pointing to someone who has done it, instead of relying on some theoretical "it could be done" fantasy.
The amount of effort, time, energy needed is just not something anybody else outside of MS is able or willing to put into implementing the language spec.
Yes I am sure that it takes a lot of time, but anyone who is willing and able can do it there is no-one stopping anyone from doing it.
The spec is open, the source code for pretty much everything is now open and is sitting on github, it has been ported to MacOS, iOS and Linux and it runs on both x86 and ARM what more do you people want?
At least 3 serious, large scale long term non-Microsoft implementations.
Or something like https://github.com/SandipKumar05/C-sharp-Compiler and then you can argue that if it only implements a tiny part of the spec it doesn’t count and that proves it’s a Microsoft conspiracy?
The real problem with developing in .NET is Windows. Everything else is stellar. Hopefully at some point in the not so distant future Visual Studio will run on Linux and then we will all move to greener pastures.
Your uncool technologies might be cooler than you think. ;)
It makes sense for them to offer tooling for their own services but that doesn’t mean they don't support other software / services as well as their own.
I can still use MariaDB with Entity Framework and push changes to the schema with update-database.
Visual Studio has extension support so 3rd party devs can add to it because MS might not be the best people to build the tool for a 3rd party, the 3rd party might just well be.
AWS provide an extension for managing AWS though Visual Studio called AWS Toolkit which makes pushing code to lambda a breeze.
That's a really weird thing to say, by what measures do you mean? In terms of market share, they are AWS, then Azure, then a big gap, then Google. In terms of maturity of the managed services, it's Azure, then AWS, then Google. Google in particular has a lot of "tickbox" features just to say they have them but when you drill down they are far more basic than either Azure or AWS.
Visual Studio is littered with SQL server and Azure tools which doesn't even make sense
Why doesn't it make sense? I use those tools regularly! The VS team, using their own product to develop their product, is generally super responsive to the user community.
The web portal is the best example, you can't use that with just one browser. Some things only works in Chrome, others are only broken in Chrome.
VS works great with other tools (i.e Oracle Db tools) with the same level of integration !
The misconception is the problem, and MS should work on that ...
That's the reason I'm phasing out Visual Studio and phase in VSCode. I mess some features but it's a much more open and leaner tool.
Or people choose what works for them? Or they have to deal with sunk costs?
> They just swallow anything which so-called MVPs and conference presenters force them down the throat, primarily Azure which is by all measures inferior to the other two and they don't even know.
Please get off that high horse of yours before you hurt yourself. Nobody is forcing anything down anyone's throat. Your argument is so petty. People go to microsoft-centric conferences and listen to MVPs for microsoft-centric products and talks. It's like you complaining that a linux conference or talk doesn't talk about windows products and hence are forcing inferior linux products down their throats. What do you expect when you go to a mysql conference? Talks about SQL Server?
> Visual Studio is littered with SQL server and Azure tools which doesn't even make sense.
A significant portion of windows development involves SQL Server and Azure interaction? You do realize that much of what is in Visual Studio is a result of customer surveys and usage data ( telemetrics )?
This is why I cringe at fanboyism. Whether it is F#, Ruby, Rust, etc. People get so irrational and consume by zealotry.
Microsoft have announced that they will be porting WinForms and WPF over to .NET Core so that they no longer need the heavyweight .NET Framework. However, this DOES NOT make WinForms/WPF cross-platform. They will still be restricted to Windows but will allow you the benefits of .NET Core, such as allowing side-by-side versioning.
Confusing, ASP.NET Core can actually also run on top of the Full .NET Framework right now, although it was announced this won't be a trend which will continue.
> features such as dependency injection
And DI isn't actually a feature limited to ASP.NET Core, .NET Core itself has DI "built-in".
They've come back full circle to forking Java for Windows only usage. .NET is the closest competitor to Java as it gets in terms of similar ideas, a VM, a bytecode for your VM, a C-like language to be compiled to said bytecode, and so on. .NET IMHO is the only serious alternative to Java and a damn good one at that, and I would dare say vice versa though I will always prefer .NET personally, I wouldn't mind Java at least.
I'm feeling more fearful that they acquired Xamarin just to destroy it.
you can even write a bunch of lines that will automatically register all your controller dependencies. (of course autofac makes this more simple). but I actually prefer explicit registration (i had the implicit variant on guice and as soon as the project was big, implicit is a mess).
I by and large held to that but here I sit, banging away at some C# code. This is day 3. Did you know if you specify a path in JSON and apply it to Use app.UseStaticFiles with a single trailing slash, instead of a double, it'll bring down the .Net kernel in flames.
Not confidence inspiring in the least.
I have been coding quite a bit of PowerShell Cmdlet in C# lately, on Windows and Linux, and it's very nice that I can pass around .NET datatypes interactively, and in a script.
Very happy that Microsoft is making this effort.
Kotlin/Scala/Clojure are nice, but my experience is that just because an organization is working with Java, you shouldn't count on being able to work with some other JVM language. At my current job, we've been forced to give up on Clojure (a language I love) because the higher-ups have decided we should stick to Java.
I really hope especially Kotlin will gain more traction in the coming years, but in the meanwhile there is at least an order of magnitude more jobs in C# (where I live).
With .Net you get F#
.NET and C#/F# are pleasant and I wouldn't be opposed to going back to them, but job-wise it seems safer to stick with tried and true Java.
Regarding things that might be better I think the linq support in dotnets collections is better than the streams support in java since java has kept more old collection libraries.
> It offers developers modern tooling that can scaffold projects, build, run, test and deploy using incredibly easy-to-use CLI tools.
I think this is one place where the abbreviation CLI should be avoided, since it means two completely different things both of which are somewhat plausible here at first glance. "Command line interface" -- even though this is a Microsoft-derived thing, you can do everything using the command-line tools you're used to from Unix, node.js, etc.; "Common Language Infrastructure" -- even though this is happening on Mac and Linux as well as Windows, you can do everything using the Microsoft .NET tools you're used to from Windows. I'm pretty sure the first of these is the intended meaning, but I had to think about it.
I don't think it would be my go to choice for projects currently, but its an option I would happily consider and I give Microsoft a lot of credit for moving in this direction.
That being said so far the reasons I've had to look at it were modernizing older .NET projects and last I looked there were so many incompatibilities be between .NET core and .NET standard that the projects would have been almost complete re-writes, somewhat of nullifying its advantages against other choices, but that was a while ago.
@alexmuro: best of luck finding quality in the pool of programming talent.
Not knocking .NET Core, I use it a lot... but this just doesn't seem like it tells you what's special about it
For me personally, there are 3 main reasons that I have been super excited about .Net core:
1. It is C#, in my opinion the best statically typed language. The easiest way I have described it to other folks is it is Java++. Combine it with really good intelligence, and it is like the code “flows out of you”. Part of the reason for that is the effort put into the language itself (getters/setters, lambda functions, etc), but equally and possibly more important is the support of Microsoft, so this is a language/toolset that is being used daily to make itself better. (In my opinion this is why Jetbrains is so good, the developers use their own tools constantly).
2. It is cross platform from the ground up. I can’t understate how great it is to have an alternative to java
3. Rosleyn: being able to compile and potentially be as fast as C++
Just my 2 cents
Roslyn is the C#/VB compiler and analysis tool. Yes, that allows you to compile C#. No, it doesn't have anything to do with performance. That's where other things come in, like RyuJIT, or .NET Native.
Not criticizing Rust which is a very new and different language - I am just comparing it's current state to something as established as .NET now that it's cross platform.
F# is probably a better competitor to Rust than C# though.
Ionide doesn't seem to require mono, ATM, for tooling in VS Code. VS Community Edition on the mac has autocomplete, full F# support (better than VS2017 in some areas), I think that might be cross-platform too (it might want Mono installed for other reasons, though).
The transition to .Net core has had some start-n-stop moments, and delays in core components that couldn't start until the framework was relatively mature. So on the fringes of tooling there have been some issues that had to wait for multiple dependencies to resolve. A delivers to B delivers to C delivers to D, and then we get a nice IDE.
Most MSDN documentation has parallel examples in C# and F#. There were offical F# tutorials, examples, demos, and templates at RTM, though the editor situation was grim due to the .Net Core project format wars. Those have since been resolved.
In general, though, the C# code from early tutorials will be relevant and easy to port as F# code is highly code-compatible with most normal C# code.
But then I would say that ;)
IMO "Typescript" should have just been a compiler variant for C# that was more scripting oriented with associated tooling.
Nice infrastructure around the language + speed +... not being Rust (with all the difficulties that come with the language)? Is pretty interesting
They would be utterly mistaken on all accounts.
"well I need to go faster than Node..."
.NET is generally faster than Node.js, at least based on most benchmarks I've seen.
" so do I need to go to C?"
Is there any other official/stable extension mechanism for Node?
"Java is slow too."
That one, I agree, is false. Java is at least as fast as .NET.
"But the C library ecosystem is _rough_...."
The C library ecosystem is very rough. The lack of memory management and the overall creakiness of C showing its age are easily apparent.
The goal of RyuJIT is understandable code and predictable machine code. HotSpot aims for performance at all costs. Many HotSpot features have been moving over to RyuJIT, even more are planned. I've always been envious of HotSpot. The main feature I've been envious of is its namesake: it aggressively optimizes hot spots. .Net now has this (tiered compilation), but it's still ultimately as-conservative as the compiler a few years back.
The hill that Java has to climb over is the extreme degree of "enterprise code." ASP.Net core is designed with the predictable performance profile of .Net in mind. Java has, well, this.
Even without the intrinsics C# is beating the JVM on the benchmark game already. Though I think those benchmarks may not all alllow hotspot to do its thing.
(I looked at Avalonia UI and mono/xwt. Not sure how stable/reliable they are.)
Code editor, GUI designer, UI framework, runtime library, debugger, everything is included and it's being developed actively for nearly 2 decades.
I understand that it is not supposed to run .exe files (no idea why, okay), but overall it sounds like awful usability.
It is a blast to work with LINQ and Lambdas and I really miss it in other languages. EF Core also matures quickly and we sucesssfully connected it to mysql and sql server.
So far there hasn't been a problem we couldn't solve in .Net Core.
For a small side project I used .Net Core Razor Pages very productively. Only needed the SDK and visual studio code. Planning on moving more small stuff away from python to .net core based on that.
Really looking forward to Version 3.0 and Kestrel replacing IIS for good.
I don't get it. They rewrite the whole think from scratch and there's still code they can't show the source for... I have a feeling there is still push back inside Microsoft against Scott Guttrie and the open everything crowd.
Local files, if you want, make everything lightning fast. Hosting your own web-browser lets you hook into whatever you want, and handle it however you want. A local server makes hosting whatever you want simple, too. There's a pre-existing plugin and component model for serving rich content... Every knows HTML and CSS, and sharding off chunks of the app to a genuine web app is straightforward...
A well factored, MVVM, WPF should be relatively easy to port to this model, and there are mature databinding libraries to handle the plumbing...
Maybe it's just me, but I'd rather take the pain points of a known technology than another 10 years of uncertainty and no cross-platform story.
IP, host header, origin header can be checked as defense in depth, but can't prevent local privilege escalation from non browser clients and are quite fragile even in browsers.
(or use a secure non TCP/IP based communication channel)
That is such a different threat model though. A native app has a lot more permissions than a web page. Trying to protect one native app from another is not really done much. Like, are MS Word documents encrypted so Slack can't read them from disk?
I don't know about the current status of the GUI layer, other than that I've heard plans for WPF to be ported over to .NET Core. I don't know if or when that will actually happen.
They'll still only run on Windows, but it's a nice option for teams that want to move their existing apps over to .NET Core and take advantage of the quicker update cycle and improved performance.
it's probably more stable on linux than if you host in inside iis.
hosting in iis is a pita btw. it's easier on windows to create a service and proxy it inside iis (if you need multiple different applications).
however compared to just systemd+dotnet+nginx it's way harder to debug if something goes bogus.
Can't say that I've used in production on Linux, but everything I've seen so far for .NET Core on Linux seemed fine and .NET overall as a platform has been historically pretty solid. It would be strange if it would be really flaky in production with all the engineering resources Microsoft is pouring into it.
And despite all the hate, Microsoft does have great engineers and great engineering processes in most core teams (Windows, Office, .NET, Visual Studio). They're held down most of the time by legacy stuff, management and marketing, but that's a bigger discussion.
Having taught and worked 4 years professionally with Java I believed I'd make the switch to C# easily.
This was not the case. But not by lack of understanding C# or .NET Core.
Mainly .NET Core and C# felt like a few years back in time. A lot of boilerplate, configuration, and a lack of libraries/alternatives.
I don't necessarily need or want a full-bodied UoW ORM when designing a microservice. It felt like I was trying to practice DDD designed for a monolith; while many of the programmer practices of DDD feel cumbersome when designing a more minimal microservice. Even the concept of a "Controller" feels misplaced for a microservice; request handler functions seem more appropriate.
Some findings I had when I tried it:
- Model validation is very optimistic; casting JSON numbers to strings automatically and vice-versa. To me this feels completely unacceptable. I've never seen something as surprising with regards to validation. While there are ways around this that requires a lot of work and code. In the end I worked around this by parsing the JSON input using JSON Schemas and ignore .NET Core model validation completely.
- The JSON deserialization is a separate step before the model validation; throwing 500 errors if JSON is formatted improperly. If you want consistent error handling and more than just the basic error output across your entire application (deserialization, model validation, business rules, app errors, etc...); good luck. .NET Core makes it difficult to achieve that goal. Same here I used a JSON Schema parsing library to overcome most of my problems and completely ignore .NET Core out-of-the-box features.
- Entity Framework feels as defacto standard; where basic SQL would do in Node or Go. It's a difficult sell to your colleagues if you'd argue EF is redundant and overly complex for the task at hand.
- I first tried to write .NET Core in VS Code like I do Nodejs, Python and Golang. It worked, but I would recommend anyone to use either Visual Studio or Rider instead. The auto highlighting, code hints and refactor tools are just so much better using those tools. Also I frequently ended up deleting the *.sln files and recalculate them using the CLI tool using VS Code. VS Code support for C# + .NET Core is just not mature yet.
- To set an environment variable in Linux the convention is UPPER_CASE. C# / .NET Core uses UpperCase__Double__UnderScore. I know it's minor, but it just feels weird and out-of-touch with linux devops, probably due to a windows-first approach.
- Lack of a popular alternatives like Kotlin or Groovy that provide a more lean & mean approach to tackle simple tasks or build basic microservices. (I don't count F# which is more in the functional domain)
- No out-of-the-box support for measuring test coverage in Linux. Community alternatives are lacking.
I'm convinced .NET Core is a step forward for the C# community. I'm not convinced it's a step forward for others.
And like you say, all the cited advantages of .NET Core just seem to be fixing things that were broken compared to Java.
Yet I completely acknowledge that there seem to be a huge number of people who really love it, and there are some clear technical advantages. And now that Microsoft seems to be genuinely (for now) no longer hostile to open source and mostly out of the patent-trolling business, I would be open to adopting it. But when I actually do try it, I don't experience the advantages that I thought I was going to.