• Advertisement
Sign in to follow this  

why are people using c# over java

Recommended Posts

Hi guys,

 

So as the title asks, why are people using c# over java ? 

The last dozen posts are about c#, none on java. I was recommended to try gamedev.net in regards to learning java and participating in such a community but this seems more c# c++ side than java. 

Share this post


Link to post
Share on other sites
Advertisement
The above points aside, if you have Java questions or want to talk about Java I'd go ahead and ask here. Despite the apparent bias (which I suspect you'll find in any game development community unless it's specifically focused on Java) there are still at least a number of people here who actively work with Java, and many more who have worked with it previously or are otherwise familiar enough to participate in discussions.

Share this post


Link to post
Share on other sites

I dont mind biased opinions, I just like seeing the reasons people chose this or that.

Thanks for the responses, it kind of make sense regarding unity that uses c# causing a wider popularity for it.

I mainly want to learn java to create a server for my game project which is written in gml, from what people have told me it's a bad idea to create a gml server for a massively multiplayer game which is what I'm aiming for. If I really want to make this game on my mind, I have to be realistic, so Java seems like the way to go.

 

I think I'll stick around on gamedev.net, because there's a lot ofinteresting stuff going on, but I'll be using stack exchange concurrently so that I can solve problems sooner. And also the more responses the more sense something will make.

 

Thanks again

Share this post


Link to post
Share on other sites

I think it really is a case of the platform chooses the language. Depending what engine you choose, the language choice is made for you. I haven't come across anyone who puts the language choice before the engine choice.

Share this post


Link to post
Share on other sites

I just like seeing the reasons people chose this or that.
For beginners, the actual language isn't that relevant. C# being a native at a Windows machine, together with Windows being the dominant platform, and existence of Unity, makes it a logical choice. Java is just a little further away, and thus used less.

... create a gml server for a massively multiplayer game which is what I'm aiming for
Massive multi-player game is a bad idea in general for a beginner. Multi-player game is already very hard, networking is complicated, "massive" adds good scaling to that equation, which is a few order of magnitudes more difficult. I would suggest you start with some much much simpler.

... but I'll be using stack exchange concurrently so that I can solve problems sooner.
The sites are quite complementary. At stack exchange you have the short simple factual-ish very concrete questions, while here discussions are more general, where the answer isn't always clear.

Share this post


Link to post
Share on other sites

Going on, there is also the nature of the task.

C++ is the currently chosen language for systems-level work in big games. It used to be different languages.  C++ currently offers the most options for tight control of the hardware in systems where you need it.

Java is the currently chosen language for server-side work and big data backends. The business world adopted it fully in the late 1990s and it is by far the most popular language for tools and technology on servers. It is also the native language of Android, although many game developers bind the calls to C++ and do their heavy lifting outside of Java.

C# is a powerful language that is a good fit for a lot of things game do.  It works extremely well for gameplay scripting, and as mentioned, Unity uses it on the gameplay side. It has a wide range of libraries and is easy to interoperate with other languages. The .net framework makes it almost trivial to put together simple tools and data processors.

 

If the site were focused on a more business-oriented field, or if the site were more about backend programming for games, then Java would likely be the most discussed language.  Instead when talking about systems-level work people generally assume C++, and when discussing gameplay and tools work the discussions tend to ask if the language is C++ or C#.  The networking forum of the site tends to be language agnostic, but there are many topics that specifically use Java.

Share this post


Link to post
Share on other sites

I'm going to jump in and claim that C# is overall a better technical choice of language than Java. Yes, I went there.

Shots fired!  :wink:

Frankly I agree with all that. C# has value-types, unsafe regions for pointer access and pInvoke which are all super useful for low-level work and much more flexible than java's FloatBuffer.

Having said that, "maybe" some of this could change with Java10 (Project Valhalla) introducing value types and generic specialisations that are hopefully optimised to the level of FloatBuffer. Java's also gaining ahead-of-time compilation which could mean more in-java heavy lifting for cases where people might at present have moved that code out to C++.

 

Just to stand up for present-day Java a bit: I am actually a huge fan of LigGDX as a gamedev framework. Java8 is significantly better than previous versions of Java. In fact it is just about reaching the point now where there are little nuggets of the language that I do miss when coding in C# (e.g. the diamond operator, functional interfaces are possibly a nicer idea than C# delegates, default interface methods, class-like enums, maybe a few other things).

Share this post


Link to post
Share on other sites

I'll add something to this.

HotSpot, which is OpenJDK's JVM, is friggin nice. It lacks a bunch of stuff the CLR does well, like more fine grained control over GC and reified generics, *much* nicer native interop, value types, and so on, but it does quite a bunch more than what the CLR (or CoreCLR, or Mono) does.

For instance, check this blog article: http://www.nimaara.com/2016/03/06/beware-of-the-idictionary-tkey-tvalue/

If you run that on VS (or LINQPad which is pretty cool I recommend it), it behaves much like the blogger posted. Takes a good while (1 second on a Haswell i5 IIRC last time I tried) on that empty foreach, and takes even more and generates garbage if you use IDictionary because of the mentioned reasons (IEnumerator vs Enumerator, struct vs class, yadda yadda).

If you try to do a benchmark like that in Java (more specifically, with HotSpot), the equivalent code should be something like this:

public static void main ( String[] args )
{
        // Look ma! No value types! No reified generics!
	HashMap<Integer, Integer> dic = new HashMap<>();
        // Stopwatch in C# is also much nicer to use than this.
	long start = System.nanoTime();
	for ( int i = 0; i < 100000000; i++ )
	{
                // Also C#'s KeyValuePair is a struct, much more efficient than HashMap's Entry objects.
		for ( Entry<Integer, Integer> item : dic.entrySet() )
		{
			;
		}
	}
	long diff = System.nanoTime() - start;

	StringBuilder result = new StringBuilder();
        // To milliseconds.
	result.append( diff / 1000000.0d );
	result.append( System.lineSeparator() );

	for ( GarbageCollectorMXBean gc : ManagementFactory.getGarbageCollectorMXBeans() )
	{
                // Never cared for printf so I wont use it :3
		result.append( gc.getCollectionCount() ).append( System.lineSeparator() );
	}

	System.out.println( result.toString() );
}

If you run that on Java/HotSpot it takes a whooping amount of 90ms on my Sandy Bridge i5, with zero collections. If you replace that "HashMap<Integer,Integer>" with it's interface counterpart Map<Integer,Integer>, like the blogger did, it takes a whooping 90ms again, with zero collections again. You might think the bytecode compiler is optimizing something but it isn't, it has those interator.next() calls and so on.

CLR is a literal JIT. It compiles methods as you call them, and doesn't bothers to think (too much) about what your method is actually doing, nor how it is used. It JITs all the methods the first time you use the, stores them in a cache and goes its merry way. This actually makes it a very fast JIT to use, startup times are pretty good in .NET.

HotSpot on the other hand inspects what your code is doing, and in this case, it knows it is actually doing nothing, so it optimizes it away. EDIT: On further testing, it doesn't optimizes away the loop, but it does do the following: It doesn't cares if you define your local variable as HashMap or Map or whatever, it knows that you're actually using a HashMap instance, so it can do nifty things like inlining the HashMap Iterator implementation, or better yet, do escape analysis on the Iterator instance since it knows it wont live outside the method's scope, it wont even be allocated in the heap.

EDIT: More specifically, it inlines HashMap's methods, EntrySet methods and EntrySet's Iterator methods, and performs escape analysis on the iterator itself so it's stack allocated. The only thing not inlined is HashMap's constructor since it is called only once.

For HotSpot, it doesn't matters if you're using interfaces, concrete classes or abstract classes, if your inheritance tree is 2 level deep or 10, it only cares for what you actually use, so if you're only using one actual concrete implementation of a method in a particular call site (ie, most of the cases), it is perfectly capable of de-virtualize it, inline it and re-optimize it.

This is why a benchmarking framework like JHM exists for Java, because it is actually pretty hard to measure things in HotSpot. If you're making naive benchmarks like you see in C# which have short methods, long but empty loops, or don't do anything with the instanced objects they're measuring, and so on, it will most certainly optimize it all out and inline the fuck out of all there is left, skewing your benchmarks a lot.

 

Have in mind CoreCLR might be in the path of re-creating all these tricks in it, given I've seen discussions in GitHub about implementing tiered compilation like HotSpot's for instance, that's a long way to go though.

Edited by TheChubu

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement