Hacker News Reader

Comment by pjmlp | Hacker News Reader

Actually Java had jMonkey and LibGDX before Unity became the engine it is today. Which initially was Mac only and only used Boo and Unity Script as programming languages.

Khronos does have some official OpenGL specs for Java. There are none from them for .NET.

Java runs on iOS via Codename One and Gluon AOT compilers.

Native interop in Java was made hard on purpose, as Sun was pushing for WORA. Oracle is in the process of improving the situation with Project Valhala.

I love both stacks, truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.

View on HN

About games, maybe the reason is lack of value types in Java which stresses GC and creates pauses. .NET works OK, Unity is the most obvious (cities skylines, kerbal space program, etc.), but also XNA, MonoGame, SharpDX. This creates an ecosystem with healthy amount of libraries and other resources.

About native interop, I know Java did it on purpose, but as a developer I don’t care much about the rationale. I’ve heard about upcoming Valhala years ago (announced in 2014), still not ready.

Related to both of them, .NET core 2.1 already has SIMD support. Some parts of it is experimental, but it already works more or less OK, esp. on Intel/Amd.

Java had such eco systems first with Java3D, JOGL, Khronos OpenGL bindings, 3D for J2ME, jMonkey, LWJGL

Problem was that Sun never was too serious about their Java Gamming initiative.

Unity only adopted C# after moving out of the Mac into the PC, and it was stuck for ages in 3.5 as they didn't want to pay for the new licenses. Which meant it grew to a kind of C# dialect, which is being fixed now.

ManagedDX and XNA were Quixotic projects not well seen by WinDev. Which replaced XNA with DirectXTK when given the opportunity.

Which took a couple of years effort until Microsoft acknowledged the work done by the MonoGame guys.

Things take ages in Java because there are multiple vendors and everyone has to contribute to the process.

Intel has provided SIMD auto vectorization improvements. There are a couple of talks about it.

> Unity only adopted C# after moving out of the Mac into the PC

Not quite true; Unity has always used Mono. The very first Unity 1.0 version in 2005 was already using C#/Mono.

> Which meant it grew to a kind of C# dialect

Unity never had it's own "C# dialect".

Given that Unity uses different conventions for property names and magical function names with reflection for events, that is a dialect to me, as it is not how C# is used by regular developers.

Actually there are occasional questions on C# forums caused by people learning C# via Unity and then facing issues when using pure .NET.

Then there is the new HPC# for the new ECS and Job systems, which subsets C#.

As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down. So I take your word for it.

That's just coding style, which by itself is not a new dialect. Yes a bunch of APIs in Unity use different naming conventions from the rest of .NET world, but the language is the same.

The new HPC#/Burst indeed are subsets of C#, but that's a very recent development, and completely unrelated to "Unity had to make their own C# dialect to avoid Novell/Xamarin licensing issues".

> As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down

I have worked at Unity since 2006. Yes Unity was Mac only at that point, but it still used Mono there.

My remark had to do more with being stuck in a v3.5 world, thus making Unity devs live in an universe quite different than what everyone else is using in terms of APIs and language features, on top of Unity specific behaviors like those magical methods called by the component framework.

> truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.

I agree, that's quite a nice summary of the 2 ecosystems

Reply on news.ycombinator.com