Hacker News Reader

Comment by dvcc | Hacker News Reader

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.

View on HN

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]

There were two blog posts around the why:

Making it easier to port to .NET Core https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it...

Changes to Project.json https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t...

Scott Hunter, Damain Edwards and Jon Galloway recently did a live community standup video about them https://youtu.be/YJsQ3tnS7Ew?t=10m39s

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

Its OSS, nothing stopping you...

Damn I like to complain not code, that's why I'm on HN right now.

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.

Same with me. I like XML, the automated tooling it allows for and never got the point of the XML hate.

It was made for tools, not to be written by hand.

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.

Yea well, that's like, your opinion, man.

Yes, it is.

"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.

I think that the hate usually comes from the PDP-11 programming crowd, whose only tools are the CLI and an editor.

>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.

You might be surprised to hear, then, that the vast majority of programmers are in the PDP-11 crowd

It doesn't look like that on the Fortune 500 offices I tend to sit on.

> 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.)

I don't recall ever having a problem with hand editing XML, how is that the problem with XML?

Or the fact that in a lot of XML 90%+ of it is markup?

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 :)

> I certainly don't want JSON project files,

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.

Yeah I do. Sometimes it's easier to just change a project reference in a solution file and reload, rather than do it through VS.

Or when a merge has gone wrong[1] and the project won't even open in VS any more.

[1] The default tortoise-svn merge tool (it's name I can't remember having switched to kdiff) is particularly horrid sometimes.

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.

Hell, I don't care if its XML/JSON/XAML but I don't want to go back to MSBuild/CSPROJ.

Yeah, I do ocassionally.

> Sure you can read them, but does anybody actually ever hand-edit them?

Let me assure you, that yes people do. Sometimes that's the only option to getting the build working like you want/need to.

Csproj-files are more or less Turing complete, so you can do lots and lots of things that the standard GUI tools will never permit you to.

> Sure you can read them, but does anybody actually ever hand-edit them?

Sometimes yes, a targeted intervention into the .csproj file is the best/only way.

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.

Reply on news.ycombinator.com