Hacker News Reader

Comment by pnikosis | Hacker News Reader

I learned C# a while ago when started a project in the now defunct XNA. I loved how I felt like home when moving from Java bit with some really nice differences.

I thought that after open sourcing .Net the C# adoption outside the MS ecosystem would be wider by now, but I feel it's not the case. Or am I missing a trend I'm not aware of? (which is very likely too)

View on HN

There is still wide resentment towards Microsoft, just go to /r/programming and check out threads about .Net, there's at least a few threads at the bottom going "EEE".

Plus dotnet core wasn't API stable until recently. I think we're still 1-2 years from mass adoption.

Also check @librexpr's comment above, there's a lot of confusion around.

It's still not really any where near finished is it?

I think they finally managed to get image manipulation in to replace the missing System.Drawing, but EF Core is still woefully half-finished.

The literally seem to have no clue about how people actually use their system and keep focusing on all the wrong things. Actually, it's more like some idealist programmers have become the core team instead of getting-it-done programmers, so it's all the latest fads instead of getting finished. The obsession with async isn't helping either, it makes the code so bad for no real-world performance gains.

My impression is they are moving super slowly and from the POV of an existing customer, the whole process has been a complete disaster. It might end up ok, but at the moment it's just a bad version of existing .Net.

Your paragraph about they "literally don't know how people use their system" seems obvious to me that you must be a 10x mega developer with insider knowledge. Idealist programmers, you're right! Async await offers NO benefits and was implemented in es6 as a mistake... probably corporate bullying.

Async is bad and you're pining for entity framework? We lead different lives.

It's slow going but I'm not sure that's bad or unexpected. MS bought mono and that blessed it as a platform that isn't dead in the water. Most existing projects are fine staying where they are until Microsoft hardens .NET core.

C# is significantly missing tooling. The tooling on Windows is okayish, but that's about it.

You have no cross-platform build and dependency management tool that runs on .NET Core (Using MSBuild and NuGet together requires Mono or the full .NET Framework), and there's only an early version of JetBrains' Rider IDE for non-Windows platforms, there's basically no working integration with any CI or CD system, and the library ecosystem is basically not existing, compared to the open source Java world.

This is just incorrect, and getting more incorrect every day. Rider is RTM, and works beautifully, particularly with .Net Core. It's trivial to setup CI/CD with Jenkins, or TeamCity, or VSTS.

What library support is missing on .Net vs the JVM? In my experience everything that's really useful has .Net ports.

It is trivial?

Then please help me — I'm trying to use C# more again — what I should use for dependency management, builds, and artifacts deployment (basically, an equivalent to gradle) on .NET Core. I'm seeing Cake, aka C# Make, but the C# subreddit told me that's useless and I should just use MSBuild. But that doesn't get me my dependencies at all, and doesn't run on .NET Core. I could write a bash script to invoke nuget and the C# compiler but that would be ridiculous.

For libraries, from http2 to time + date libraries, C# is lacking, in tmy last project I ended up straight up translating the parts of JSR-310 I needed.

I'm looking for a 1:1 replacement for JVM languages here, especially regarding tooling. Rider has proven much less mature than IDEA for now.

Trying to directly translate a Java-style workflow to .Net is probably going to be tough sledding; it's just not how things are done. You can do it, but you'll fight everything more than being on the happy path. The dotnet CLI tooling is relatively slick, from what I've seen.

What would the C# tooling workflow then look like? I haven't found anything that's reasonably easy to use with just .NET Core.

What were you using Gradle to do that you want a c# replacement for?

Basically everything. In my web projects, gradle runs css and js minification and compilation, and in game projects, it runs the asset preprocessing.

The build-time code is handled with gradle’s buildSrc folder.

I also obviously use Annotation Preprocessors to pre-generate code for my Java projects, and additional build tools to further minify and optimize the output (e.g., for Android, I also run redex over it).

Basically, gradle for me handles the entire build – fetching dependencies, building native libraries, running code generators, building Java code, binding them together, processing assets, compressing the result, and optimizing it all – and deploying the results.

In nice, and modular steps.

"dotnet publish" should have you covered for restoring from nuget, compiling and producing a deployable package. Is there something it's missing for your use case?

Noda Time might have what you need in a datetime library.

> "dotnet publish" should have you covered for restoring from nuget, compiling and producing a deployable package. Is there something it's missing for your use case?

Thanks a lot – this is the first time someone actually provided a useful solution, this might actually work well enough for simple projects.

> Noda Time

Also thank you a lot, that actually is significantly better than Joda Time in the Java world, and as result, actually useful (in fact, it feels like a 1:1 clone of JSR-310, at least from what I've seen in their API docs)

This is actually very helpful, thank you :)

Reply on news.ycombinator.com