Somewhat off topic, but all the excitement and hoorah surrounding .NET Core is beginning to fade for me.
It seems that the product is beginning to turn into .NET 5 (Core) instead of the original intentions of leaving behind the legacy chains.
Between the switch back to MSBuild, RC# breaking changes and the promise of even more breaking changes post-release, I've become a little disheartened.
Change in itself isn't bad, but .NET Core was supposed to be about open communication, and the later changes were never discussed within the actual community, instead it was decided by MS alone.
Hell, in this article, it took multiple attempts to get it configured when its in the release-candidate stage. No idea where this was going it was more of a rant than anything apologies for anyone who actually read it.
The changes have been announced well ahead of being designed or implemented; so at this stage are "proposed" changes.
There are issues on github where they are working through various designs; people are giving feedback, they are listening to them, iterating, improving - they written blogs about why, again taking feedback responding etc
So that's pretty early community on-boarding - its not like they have already designed and implemented it without consultation and did a surprise change - its still in an open design phase.
The changes were announced ahead of time, but within the discussion there hasn't really been actual consideration around not switching back to MSBuild. They've been pretty set on the it within the Github issues (#1433) and haven't provided too much reasoning for it outside of tooling. Of course it's not that alone either there is just a bunch of confusion around it right now on the direction of .NET Core.
From one of the end comments:
> If you want to work out how it should be made and be in the design team that talks about it... please do. [Link to MS Career Page]
I get that they have gave their reasoning (all those links were already grayed out), but its much more an announcement than it is a discussion. In the end though, it feels more like an executive decision than a collective push.
Yeah, they actually hold meetings with the community on Google Hangouts where they literally discuss every move in the open. Just because you aren't following it doesn't mean that it isn't happening.
Entirely aware they do, even watched the relevant part for the csroj piece today; however, not everyone has time to sit through the stand-ups. And when the discussion with the community blows up on Github things don't look as promising as they once did. Sorry I don't share your same sentiment, but I am seemingly not alone in how I feel.
If it really bothers you and you don't believe your concerns will be taken into account and there is a huge ground swelling of community support, its Apache 2.0 Licensed, fork it and make something better that fits with your vision: https://github.com/dotnet/roslyn-project-system
It seems perfectly in line with every other announcement from Microsoft over the past 20 years. Every time they start an exciting new project, they astroturf the snot out of the announcement, in the press and online, to make it seem like it's more production-ready than it is, and then it takes longer than anyone predicted, and the things that made the announcement interesting (like getting away from MSBuild) wind up getting scrapped. I don't know why this pattern surprises anyone any more. I'm still waiting for Bash on Windows to support RVM and bootstrapping a Rails environment, but, then, I'm still waiting for the filesystem improvements promised in Cairo.
It seems to me that at MS they have smart guys come up with a good idea. These people are deemed too valuable to actually do this so management hands off the work to some inexperienced people.
My company often does the same with things like refactoring or source control strategy. Good people are needed for project work so some intern gets to do a massive refactoring with bad results.
It's Microsoft, their things always start with fantastic idea/concept but the implementation and delivery never gets it nowhere near as hoped. Oh well...
I gotta agree that the excitement is waning – I don't know why they're moving away from the JSON file back to csproj files. These files are more or less opaque. Sure you can read them, but does anybody actually ever hand-edit them?
It's an obvious move to make migration easier for devs. I certainly don't want JSON project files, I just want to be able to take my existing .NET projects as is and build them on Core. The only place I ever want to see JSON is as a response to some client side JavaScript call, that is its only valid use imho, everywhere else it's not as good as the alternatives.
XML is one thing, MSBuild is another one. It's the only widely used tool where you can't really hand-craft (and therefore fully understand) a complete build file.
Compare Maven's pom.xml with a MSBuild file. Both XML, both verbose, but other than that, radically different.
There was a (very) brief period where I used a few hand-crafted MSBuild files. I don't remember it being all that bad (other than heavy learning curve) and there were even some things you could do simpler and nicer in a hand-crafted MSBuild file than what you see in Visual Studio's usage of MSBuild and the build files it generates.
I think a lot of people's issues with MSBuild are more to do with how Visual Studio uses MSBuild than with MSBuild itself. MSBuild has just about always supported wildcards and deeper incremental and partial build support, but Visual Studio hasn't. A lot of the hoops in hand-crafting an MSBuild file are there mostly if you want to make sure that Visual Studio can open the file...
Sure, but you have to look at the target audience, existing .Net developers; these devs in large already use MSBuild. They don't want Maven, they want their existing projects and solutions to simply open, build, and work as is. It's hard enough changing OS's, the last thing they want is for all the tools to change as well.
Microsoft is doing this because the .Net developers numbers are most likely dwindling (or at least stagnant, which is just as bad since it means there's not enough young blood coming in).
As a result the new solution must also cater to the new recruits they're trying to draw. I doubt many of those would like MSBuild, since it's not even liked by existing .NET devs :)
> It was made for tools, not to be written by hand.
...but people too often end up needing to read or write it by hand. That's the problem with XML. (Well, the other problem is that there is lots of data for which you'd want tooling for which a text-based markup format isn't ideal in the first place.)
"tools" don't always exist or may not be available. So, as with all software, it must be possible to edit the files as text with a good developer experience.
>Yes, but that should be the exception, not the rule
Yeah, like it has been with .NET development on platforms where Visual Studio doesn't exist (read: all of them except Windows).
"should be" is a very different creature from "is", and is also very different from "will be".
> the hate usually comes from the PDP-11 programming crowd, whose only tools are the CLI and an editor.
Also known as "the every other platform except Windows" crowd, which apparently is substantial enough that even the one outlier -- Microsoft -- finally is trying to move in line with the rest of the world by allowing Bash and Linux tools in Windows 10.
You can be dismissive all you want, but that doesn't change the reality that CLI+editors are modern development (see also: almost every new language's ecosystem pivoting on CLI tooling and editor plugins), not the past.
> Also known as "the every other platform except Windows" crowd
I am yet to see iDevices and Android developers being PDP-11 devs or guys doing development on our Fortune 500 customers, regardless of the customer OS.
Strange, it sure looks like that at Amazon, at Netflix, at McKesson, at Facebook, at....you get the idea
But enough empty hot-air "name-dropping"; just cool your bluster, dude. You don't have to get all "look at me I'm better than you, I have all the best words, great words like 'Fortune 500'" just because you don't like CLIs.
Agree, XML is fantastic and a much better choice than JSON for everything except being parsed by JavaScript. JSON has one use in this world, JavaScript.
I personally don't care much if it's XML or json, I just want it to be simpler and easier to use. And the RC1 demos of adding nuget packages by typing 1 readable line into project.json certainly where that.
If they make the csproj format package aware and treat files as included by default, I don't actually see any disadvantages over project.json. In fact, I think that a format that doesn't even have comments is terrible for this kind of stuff.
Yes I did. I needed to hook a custom build step in the build process of a Windows Phone application. But interfacing with MSBuild is not only editing the XML file, it is also about creating tasks in .net that can be called by MSBuild. In the end it was not that hard but still required some days of reading docs and trial.
Call me crazy, but I think long term this will be a good thing for Java. (I am one of those people who actually enjoys Java, I know call me crazy)
My organization for example used to be all PHP and JavaScript. This whole "static language" thing is new to them. They tried C# and thought it was the greatest thing since sliced bread, (along with Go). So they heard about Microsoft going "open source" and decided to give it a spin. Now with the 'boiling the ocean' article ringing true for many, people are starting to get some heartburn about having to get in bed with Microsoft.
I stand over in the corner and raise my hand occasionally and say, "How about Java?" every now and then.
Once you've used C#, it's really hard to go to Java. If they were radically different, it might be easier, but instead Java just presents itself as a worse version of C#.
Microsoft can fix their platform issues but Java the language can't really be meaningfully improved. So, in my opinion, it's still Microsoft's game to win or lose.
Microsoft has repeatedly demonstrated that they cannot fix their "platform issues", which also includes tooling.
For example getting back to an environment that uses MSBuild and Visual Studio for builds, dependency management, continuous integration and whatnot, after having used Maven, SBT, Leiningen and their ilk, feels like going back to the nineties. Even worse, your IDE of choice needs plugins to have working refactoring and it still can't handle automatic downloading of source code for third party dependencies, but at the same time manages to be bloated, and you still consider it the best IDE ever.
I also think .NET developers get too fixated on Java the language. We've got Netty, Apache Spark, Hadoop and Cassandra and we've got Clojure, Scala, JRuby and Groovy.
In other words a big ecosystem powered by what proved to be a multi language runtime not just in marketing brochures.
Honestly one of the big problems I have getting into Java-the-ecosystem is the huge number of frameworks, tools, languages, etc that all compete with each other. The solution to every Java problem is just more: more tools, more syntax, more languages. It's hard to get started in that situation.
If you're already well into it all, then one more thing is just one more thing.
> Honestly one of the big problems I have getting into Java-the-ecosystem is the huge number of frameworks, tools, languages, etc that all compete with each other.
Depending on how hard you look that is true for every language driven by open source: case and point is Javascript front end frameworks (Now the dust is settling a bit, and there seems to be Angular2/React/Ember, both with varying levels of overlap) Competition is a good thing. Choices are a good thing. What eventually happens is larger frameworks eventually emerge as winners, and absorb the good ideas out of the smaller frameworks. Spring Boot is an example of this.
> The solution to every Java problem is just more: more tools, more syntax, more languages.
That's the solution for 'Enterprise Consultants/Architects' maybe, but we normal java programmers just favor simple tools and jars these days. For example, I would roll over dead before I had to use Spring again, but I would much rather use some simple jars to stitch together an API like Jackson and Jersey, at worse, using something minimal like Dropwizard.
I am mostly windows dev and that is the thing for me with linux, you do it three times to get anything running. Maybe I do not spend enough time with linux but on the other hand I do not have time to do stuff three times to learn. In current work I have mac laptop... Suffice to say everything works out of the box even on windows our office VPN is doing weird things while on mac it just works.
Maybe I am too old for it, when I was 12 I had time to put linux on my pentium 100 then switch processor to amd and wonder that it worked becuase motherbord was still designed for "pentium" but now I just need stuff to work.
So I am not going to spend time on RC and convince my boss that this is latest shiny thing we should do our big project in. Just like the guy from boiling ocean...
As a linux dev I find the opposite. Everything I use works out of the box on Linux and everything on Windows needs config and fiddling -- and that config seems to always end up involving a GUI that I can never remember my way around.
I guess what I am trying to say is that our experience with different systems impacts how productive we are with them.
I wonder how it goes with the type of things I install. I suppose I am maybe trying to play with "fancy" stuff on linux that is not easy to install like .NET core. Because to install HTTP/SSH/FTP servers and configure is also quite easy for me.
Do you try to install some unusual things on windows maybe as well??
I've never deployed on a windows server I'm thinking of my dev box here.
I just install what I think of as standard dev tools. I guess they are not standard on Windows. Hence my pain... I pretty much would have to install cygwin to get something I'd be close to comfortable working with -- at which point a virtual machine is just easier (and then I can install the same OS as on the server I'm deploying on anyway).
Whereas I guess for you .NET core is a standard thing and it is (still) not a standard thing on Linux. Hence your pain.
Windows, OS X, RHEL all those are operating systems; Linux is not. It might seem pedantic, but one must suggest distro's: CentOS(Use RHEL docs), Ubuntu(I recommend Ubuntu Studio for Desktop), Debian, Fedora, GNU/Linux/.*. I might even be as progressive to name freebsd, pc-bsd, RaspBSD.
But sorry, I'm just unwinding a bit on HN, after work.
> Windows, OS X, RHEL all those are operating systems; Linux is not.
I'd consider "Windows" to be a family of related operating systems (but usually referring to the "Windows NT" OS). "Linux" as well, using the name of the kernel to refer to a family of different OSes built on top of it (while excluding others, in its common use).
Huh? What are you doing three times? Installing the SDK is incredibly easy. Using it in docker is literally as easy as `docker run -it microsoft/dotnet`.
>the thing for me with linux, you do it three times to get anything running
Meanwhile, I just spent a few hours editing reg keys and firewall rules to enable a Windows Jenkins worker when it takes about 30 seconds to add a Linux worker via SSH.
I have the opposite experience when it comes to software development. 9 times out of 10 the Linux/Unix instructions for compiling some software from github will be short and concise, then you look at the windows instructions and they want you to set a whole bunch of environment variables, link that here, move that there, and the documentation for everything highly technical is sparse. Then when something doesn't work it's sometimes very hard to find out how to get it to work. You search on stackoverflow, and all you find are the answers from people on Linux and they don't apply to your Windows system.
Also, IME almost every new language targets Linux/Unix before it targets Windows unless it's some proprietary language/made by Microsoft. Example: for a long time you couldn't even get 64bit versions of Rust for Windows while they were available on other platforms for a while.
It's getting harder to deny: Even MS has added a Linux ABI to attract developers (I'm not interested though). Lots of people on Windows (and OS X) even go through the trouble of running Linux virtual machines just for a dev environment.
What I usualy see is "Install packages A,B,C" ok it is easy fire up Ubuntu VBox type "sudo apt-get install A". All goes well then I install package B and then it turns out apt-get for my Ubuntu has only some older version. No problem I find that i can install package B in newer version from someones PPA. This one works but when it comes to package C it turns out that it is only compatible with package B v.2 but with A v.1.3 and package B v.2 needs package A v.1.4.
Then I give up, because I am not going to fiddle with it for hours just to find out that package from PPA does not work becaue I have not copied it to correct directory and I have not changed permissions to correct ones.
Ok I can setup ftp/http/ssh on linux server with apt-get and changing configs, no problem.
But If I have to add some aditional stuff it gets messy very quick.
If you needed .NET in a production environment I'm perplexed as to why running it on RHEL would be a good decision. The POC is excellent but I wouldn't be serving .NET apps to my clients using this.
We have six production nodes sitting behind a load balancer at three sites. That's 18 total nodes, all of which we're paying to run on Windows Server.
If we could run these 18 nodes on Linux, even with the associated support contract, we could see significant savings. All of this is a drop in the ocean compared to our database costs (we're using a massive Oracle database) but the savings could be enough for an extra employee.
You can argue the pros/cons of .Net in general, but we find it allows us fairly good productivity. We've also moved a lot of front-end logic into HTML/JS/CSS so if we ever moved platforms we aren't as tied, but right now MVC/EF is working fine.
This a million times over. We have a very similar environment except you can add in a mainframe and a few MS SQL Servers in addition to the ridiculously expensive Oracle stuff. However, the cost of moving VERY productive .Net staff to something else would be even more expensive. So for now, we just wait and see (while running a .net framework version 2 years out of compliance).
Maybe not now, but this is a move for the future so that .Net can survive in a world dominated by Linux. The second it's actually possible to ditch Windows and run my apps on Linux in production Windows will be banished from my datacenter. .Net is awesome, Windows sucks, I want .Net on Linux.
I'm keeping it on my radar due to cost differences in AWS. A .net web app using 4 EC2 m3.xlarge instances (2 front ends per AZ) would save over $6000 per year in hosting if using Linux AMI versus Windows.
Yes, the Windows tax is not cheap, nor are they nearly as easy to clone and manage in a virtual environment. Linux is simply a superior server in virtually every conceivable way but most especially financially.
As a total tangent, why is it everyone hates on Visual Basic, but loves C#? Both languages get compiled to Common Intermediate Language, so it's not like there's going to be some sort of magic speed increase by using C#. (Which, historically, was VB's supposed problem.)
Visual Basic (the latest version of which is VB6) and Visual Basic .NET are not the same language.
VB.NET is a C# skin. VB6 was an excellent productive environment, whose problems were the Basic language and its warts, and the community of which a significant percentage were clueless.
People who hate VB.NET hate it because it's basically a needlessly verbose skin of C#. People who hate VB6 hate it because they hated it 10 years ago when it was still dying (and they don't even remember why). The bottom line is that today no one actually likes either VB environment.
It's mainly a legacy association with VB6 as the tool for novice programmers. The name "Visual Basic" simply got tainted a long time ago for the more advanced crowd, and it's very hard to get past deeply ingrained perceptions. Also, if you learned C/C++ or languages with similar syntax such as Java (as many have), C# just looks 'more correct' to you.
The languages are too similar for both to survive in the community. It's extremely pointless for both these languages to exist. VB.net existed to help migrate over classic VB users but ended up being too much like C# to even do that effectively.
C# is definitely the more popular language, so there's no reason to waste time on VB. Nearly every open source project, sample code on stack overflow, etc will be in C#.
I don't know why anyone posts anything MS related to HN.
First post: rant about some perceived slight by MS.
Response to first post: yeah, that's what they do. They killed this thing I loved after I used it for a while.
Some other post: Embrace Extend Extinguish.
One small post: I think its ok! <- down vote down vote down vote...no such thing as group think here!
Please stop posting unsubstantive comments to Hacker News.
The parent comment was fine because it went into detail about specific experiences. But a reply like this is just kindling for flamewars, and we don't want those on HN.
I don't know man, the hello world look quite the same. I don't think C# dev have anything to laugh about. I would rather be concerned how Oracle is using Java in courts.
But technically Java is one of the more favorable languages we have out there in the world. Go look at tooling like Scala, Maven, how easy it is to get something running on a *nix box.
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World");
}
}
public class HelloWorld
{
public static void Main()
{
System.Console.WriteLine("Hello, World!");
}
}
For the world of me, the C# folk keep parroting about how much "better" C# is than Java, and having worked _extensively_ in both, I can't seem to see it, especially with Java 8. Maybe if you said C# is "so much better than Java" in the days of Java 6 I would agree.
I also hear the "faster" argument, but have yet to see any meaningful benchmarks proving this. In fact I see more showing the opposite, but maybe I am not looking hard enough?
Honestly for me the main difference are the IDEs. I started with Eclipse and the jump to IntelliJ was huge/great. But using Visual Studio was always a better experience.
Your point about the difference between the languages is definitely true re: Java 6. Java stagnated for a few years there while C# was improving with things I'd actually use. Java 8 is definitely an improvement and ultimately I think it would boil down to ease of use and familiarity when comparing them.
One thing I don't miss about java is server configuration. At the same time, I'm definitely relying on IIS doing things behind the scenes I probably don't know about.
IntelliJ now, at least in my opinion, is unmatched. Intellij feels more like a lightweight text editor now like a Sublime, but all the power of an IDE, whereas Visual Studio very much feels like a kitchen sink IDE. Intellij sometimes gets bogged down when it reindexes your files (which you can optimize by excluding certain folder), but Visual Studio sometimes brings my entire system to a screeching halt while I wait for it to do whatever it is it is doing.
Also, I know this is nitpicky, but having to press CTRL+K, CTRL+C, then CTRL+K,CTRL+U to comment/uncomment just feels obscene to me. I understand you can modify the shortcuts, and I am being petty, but CTRL or CMD+/ toggle comments off/on just feels much better, and that's probably one of the most used ones for me which is why I am probably nitpicking about it.
Yeah, like "how much money do I need to pay per developer on tools?", or "how much money do I need to spend on deployment?", both of which are major business-world concerns, and which strongly favor Java over C#.
For the first part... .Net Core can be developed without Visual Studio just fine, and to a certain degree so is traditional .Net.
For the latter, that's more runtime than language, for which Mono and .Net Core cover for reliably running on *nix.
Full disclosure: I'm one of those hippies that believes Java's/C#'s model of OOP is the 3rd biggest cancer in this industry, with 1st and 2nd being Oracle and Microsoft. I hope that makes it very clear that I don't exactly like either language, but I do believe C# to be a clear improvement over Java.
Java the language (syntax-wise) is just slightly worse than C#. JVM is better than CLR (or at least has a shit ton more development time on it). Java the ecosystem is a burning hell where passion is killed by infinite amount of AbstractPainAbstractManagerFactoryFactoryManagerGenericHelpers.
I think you're talking about Spring the ecosystem. Truly a burning hell, with your path dimly illuminated by ten trillion outdated stackoverflow and coderanch posts, and where at every junction you can choose either the XML or the annotations path.
It seems that the product is beginning to turn into .NET 5 (Core) instead of the original intentions of leaving behind the legacy chains.
Between the switch back to MSBuild, RC# breaking changes and the promise of even more breaking changes post-release, I've become a little disheartened.
Change in itself isn't bad, but .NET Core was supposed to be about open communication, and the later changes were never discussed within the actual community, instead it was decided by MS alone.
Hell, in this article, it took multiple attempts to get it configured when its in the release-candidate stage. No idea where this was going it was more of a rant than anything apologies for anyone who actually read it.