4 ms·

I think Microsoft is about to take off. Businesses are going to move to Azure and use dotnet core. Today we've visual studio on mac too. Plus, visual studio co

I think Microsoft is about to take off. Businesses are going to move to Azure and use dotnet core. Today we've visual studio on mac too. Plus, visual studio code on Linux. Who wants to deal with Java BS when their master pisses of people with these idiotic moves. Not to mention Rider IDE.

wil421 8y ago
From what I’ve been told C# is really great to work with and fixes a lot of issues people had with Java. Can anyone who’s used both recently comment?
- metalliqaz 8y ago
  I don't use it, but I know that I see a lot more job postings in my area for C# coders than Java coders.
  - kjeetgill 8y ago
    Out of curiosity, what's your area? In SV it's Java shops as far as they eye can see.
    - bunderbunder 8y ago
      From what I've seen, it varies wildly with the job market. I'd expect to see more Java shops in SV because Java's huge open source ecosystem makes it a much better platform for doing, for lack of a better term, "tech company stuff." Also, SV is heavily influenced by academia, where .NET was just a flat-out no go for a long time because it only really worked on Windows. But I see a lot more .NET for the kinds of in-house enterprise development jobs you see in regions like the Midwest. For that kind of work, there's usually not much in Java that you can't get on basically any other platform, too, and .NET/C#'s better ergonomics will let your team be more productive at the kinds of stuff they're doing. (I'd bet Clojure is even better still, but Clojure doesn't look good in khakis and a polo shirt.)
      - kjeetgill 8y ago
        You're not the first one to mention it to me, but what "better ergonomics will let your team be more productive"? Honest question since, as an outsider to C#, the library ecosystem seems anemic coming from java.
        bunderbunder 8y ago
        So my sense is that, for utility-type stuff, the library ecosystem in Java feels bigger because its standard library is anemic. That basically forces Java to have a bigger library ecosystem just to achieve the minimum set of tooling you need just to hit the minimum bar for being a usable general-purpose language. Joda Time, Apache Commons & Guava, Jersey, Hibernate, etc. - heck, even Dropwizard - are all libraries whose .NET equivalents are just different bits of .NET itself. Similar for Java Mission Control, for that matter. Where .NET pales, IMO, is for stuff like Hadoop that, while astoundingly helpful for some problem domains, isn't so useful for most enterprise development work.
    - metalliqaz 8y ago
      Connecticut
- raptaml 8y ago
  I use both and you are right. As language C# fixes many things one could be unhappy with in Java. But Java has it's eco system which is definitely unmatched in quality and quantity...and that plus the ultra optimized and battle-tested JVM is what makes people stick with it.
- meddlepal 8y ago
  That was more true a decade ago. The feature gap has narrowed a lot in recent years. I'd also argue the JVM in general is still a better platform than the CLR.
- bunderbunder 8y ago
  I am a relatively recent transplant from C# to Java. I'm still getting my bearings, but my general sense is that Java has an amazing ecosystem in the large scale, and that makes it much easier to tackle the hard problems, but is the absolute pits to work with for everyday challenges. IOW, Java makes the hard problems easier and the easy problems harder. Concrete example: .NET has nothing comparable to the Hadoop ecosystem, or to International Components for Unicode. Concrete example: Compared to what's in .NET, a lot of stuff in the core Java libraries feels very half-baked. Streams, for example is missing a lot of useful features that I am used to seeing in every comparable library. There's not even a mapi in there. Bifurcating it from iterables and the rest of the collections API also creates some ergonomic annoyances that don't exist in, e.g., .NET or Scala's equivalents.
  - Retric 8y ago
    From what I recall .NET has built in almost all of International Components for Unicode features. You can still use ICU from C# if you want to, but I have never personally seen anyone do so. See: GenICUWrapper A tool that generates a rudimentary C# wrapper around the C API of ICU4C. ICU Dotnet - .NET bindings for ICU http://site.icu-project.org/related http://site.icu-project.org/related or https://github.com/sillsdev/icu-dotnet https://github.com/sillsdev/icu-dotnet There are also .Net options for Hadoop so I am not sure what you mean exactly?
    - bunderbunder 8y ago
      There are options, there are always options, but they are typically 2nd class, incomplete, poorly supported, or otherwise substandard. For example, first line of the readme for icu-dotnet (emphasis mine): > icu-dotnet is the C# wrapper for a subset of ICU4C
      - Retric 8y ago
        ICU4C has quite a bit of cruft at this point, so the useful subset is perfectly reasonable. You can always add anything to these layers you want, but it's really not worth the effort.
brightball 8y ago
It would take some serious, consistent and repeated reports of .NET doing very well on Linux servers in production for that to happen. C# is a really nice language, it's just being mostly stuck in the peripheral environment that's the issue. We need highly visible success stories. As it stands right now, if your company is developing on .NET for the most part you are locking your developers out of the entire *nix ecosystem...from server licenses to command line tools to open source libraries to databases. Combine that with how difficult Microsoft makes it to get your data out of SQL Server even for things like Elastic Search and you're in for a world of licensing hurt down the road. I honestly still don't understand how anyone chooses a stack that locks you out of so many options and imposes so many constraints. I get that Microsoft is improving...but they have a big hole to climb themselves out of.
- FieryTransition 8y ago
  Agreed, not to mention how many of the frameworks and tools you would use in the .net world but on .net core either isn't fully implemented on linux, performs worse than on windows and generally is risky since it's not really tested software and it didn't have many iterations on the linux system to allow for improvements. So it's risky to choose it for anything that's supposed to run in production, unless you are really sure it works for the specific task you know you will use it for. Take things like SignalR for .net core, ServiceFabric, many microsoft server only products in Azure, (third party Akka.Net) don't support linux so well yet. Some of them are getting there but it's kind of risky to use due to the lack of being used in production for a while or it's lacking a feature or something is missing. It's been a while since the announcement of open source support, but it's seems like a slow process. It generally gives a vibe that they would rather have you use azure on windows, than support a completely open development ecosystem. They should put more weight behind the open source movement TBH. But it's an improvement, maybe they will get there one day. But right now I wouldn't choose it either for many things, considering the alternatives on linux. And last time I tried running code on linux and windows, the linux version was considerably slower for identical c# code. Might have been a missing compiler optimization, who knows. Not that I don't want C# on linux, I think it's a nice language in that family of languages. Like you said, it needs more success stories from running in a nix environment.
dominotw 8y ago
> with these idiotic moves. I am not sure how this is an idiotic move. They are laying off ppl working on product that company doesn't think is profitable. Happens all the time, everywhere.
pjmlp 8y ago
I do Java and .NET consulting. In what concerns UNIX like systems we don't care at all about .NET Core, because it is still playing catch up with the .NET Framework libraries we care about, lacking parity with many mature Java versions. Which has led to some projects porting a set of small .NET applications to Java, as means to deploy on Linux, because the customer wasn't willing to bet on .NET Core. Additionally, in spite of not being fully Java SE compliant, it is still more productive to write Android in Java as dealing with Xamarin integration issues. Rider IDE might be interesting when they start supporting GUI development. Finally, as any long time .NET developer will tell you, Microsoft also has its own fun moments.

wil421 8y ago

From what I’ve been told C# is really great to work with and fixes a lot of issues people had with Java. Can anyone who’s used both recently comment?

metalliqaz 8y ago
I don't use it, but I know that I see a lot more job postings in my area for C# coders than Java coders.
- kjeetgill 8y ago
  Out of curiosity, what's your area? In SV it's Java shops as far as they eye can see.
  - bunderbunder 8y ago
    From what I've seen, it varies wildly with the job market. I'd expect to see more Java shops in SV because Java's huge open source ecosystem makes it a much better platform for doing, for lack of a better term, "tech company stuff." Also, SV is heavily influenced by academia, where .NET was just a flat-out no go for a long time because it only really worked on Windows. But I see a lot more .NET for the kinds of in-house enterprise development jobs you see in regions like the Midwest. For that kind of work, there's usually not much in Java that you can't get on basically any other platform, too, and .NET/C#'s better ergonomics will let your team be more productive at the kinds of stuff they're doing. (I'd bet Clojure is even better still, but Clojure doesn't look good in khakis and a polo shirt.)
    - kjeetgill 8y ago
      You're not the first one to mention it to me, but what "better ergonomics will let your team be more productive"? Honest question since, as an outsider to C#, the library ecosystem seems anemic coming from java.
      - bunderbunder 8y ago
        So my sense is that, for utility-type stuff, the library ecosystem in Java feels bigger because its standard library is anemic. That basically forces Java to have a bigger library ecosystem just to achieve the minimum set of tooling you need just to hit the minimum bar for being a usable general-purpose language. Joda Time, Apache Commons & Guava, Jersey, Hibernate, etc. - heck, even Dropwizard - are all libraries whose .NET equivalents are just different bits of .NET itself. Similar for Java Mission Control, for that matter. Where .NET pales, IMO, is for stuff like Hadoop that, while astoundingly helpful for some problem domains, isn't so useful for most enterprise development work.
  - metalliqaz 8y ago
    Connecticut
raptaml 8y ago
I use both and you are right. As language C# fixes many things one could be unhappy with in Java. But Java has it's eco system which is definitely unmatched in quality and quantity...and that plus the ultra optimized and battle-tested JVM is what makes people stick with it.
meddlepal 8y ago
That was more true a decade ago. The feature gap has narrowed a lot in recent years. I'd also argue the JVM in general is still a better platform than the CLR.
bunderbunder 8y ago
I am a relatively recent transplant from C# to Java. I'm still getting my bearings, but my general sense is that Java has an amazing ecosystem in the large scale, and that makes it much easier to tackle the hard problems, but is the absolute pits to work with for everyday challenges. IOW, Java makes the hard problems easier and the easy problems harder. Concrete example: .NET has nothing comparable to the Hadoop ecosystem, or to International Components for Unicode. Concrete example: Compared to what's in .NET, a lot of stuff in the core Java libraries feels very half-baked. Streams, for example is missing a lot of useful features that I am used to seeing in every comparable library. There's not even a mapi in there. Bifurcating it from iterables and the rest of the collections API also creates some ergonomic annoyances that don't exist in, e.g., .NET or Scala's equivalents.
- Retric 8y ago
  From what I recall .NET has built in almost all of International Components for Unicode features. You can still use ICU from C# if you want to, but I have never personally seen anyone do so. See: GenICUWrapper A tool that generates a rudimentary C# wrapper around the C API of ICU4C. ICU Dotnet - .NET bindings for ICU http://site.icu-project.org/related http://site.icu-project.org/related or https://github.com/sillsdev/icu-dotnet https://github.com/sillsdev/icu-dotnet There are also .Net options for Hadoop so I am not sure what you mean exactly?
  - bunderbunder 8y ago
    There are options, there are always options, but they are typically 2nd class, incomplete, poorly supported, or otherwise substandard. For example, first line of the readme for icu-dotnet (emphasis mine): > icu-dotnet is the C# wrapper for a subset of ICU4C
    - Retric 8y ago
      ICU4C has quite a bit of cruft at this point, so the useful subset is perfectly reasonable. You can always add anything to these layers you want, but it's really not worth the effort.

brightball 8y ago

It would take some serious, consistent and repeated reports of .NET doing very well on Linux servers in production for that to happen. C# is a really nice language, it's just being mostly stuck in the peripheral environment that's the issue. We need highly visible success stories. As it stands right now, if your company is developing on .NET for the most part you are locking your developers out of the entire *nix ecosystem...from server licenses to command line tools to open source libraries to databases. Combine that with how difficult Microsoft makes it to get your data out of SQL Server even for things like Elastic Search and you're in for a world of licensing hurt down the road. I honestly still don't understand how anyone chooses a stack that locks you out of so many options and imposes so many constraints. I get that Microsoft is improving...but they have a big hole to climb themselves out of.

FieryTransition 8y ago
Agreed, not to mention how many of the frameworks and tools you would use in the .net world but on .net core either isn't fully implemented on linux, performs worse than on windows and generally is risky since it's not really tested software and it didn't have many iterations on the linux system to allow for improvements. So it's risky to choose it for anything that's supposed to run in production, unless you are really sure it works for the specific task you know you will use it for. Take things like SignalR for .net core, ServiceFabric, many microsoft server only products in Azure, (third party Akka.Net) don't support linux so well yet. Some of them are getting there but it's kind of risky to use due to the lack of being used in production for a while or it's lacking a feature or something is missing. It's been a while since the announcement of open source support, but it's seems like a slow process. It generally gives a vibe that they would rather have you use azure on windows, than support a completely open development ecosystem. They should put more weight behind the open source movement TBH. But it's an improvement, maybe they will get there one day. But right now I wouldn't choose it either for many things, considering the alternatives on linux. And last time I tried running code on linux and windows, the linux version was considerably slower for identical c# code. Might have been a missing compiler optimization, who knows. Not that I don't want C# on linux, I think it's a nice language in that family of languages. Like you said, it needs more success stories from running in a nix environment.

dominotw 8y ago

> with these idiotic moves. I am not sure how this is an idiotic move. They are laying off ppl working on product that company doesn't think is profitable. Happens all the time, everywhere.

pjmlp 8y ago

I do Java and .NET consulting. In what concerns UNIX like systems we don't care at all about .NET Core, because it is still playing catch up with the .NET Framework libraries we care about, lacking parity with many mature Java versions. Which has led to some projects porting a set of small .NET applications to Java, as means to deploy on Linux, because the customer wasn't willing to bet on .NET Core. Additionally, in spite of not being fully Java SE compliant, it is still more productive to write Android in Java as dealing with Xamarin integration issues. Rider IDE might be interesting when they start supporting GUI development. Finally, as any long time .NET developer will tell you, Microsoft also has its own fun moments.