Hacker News Reader

Comment by internetter | Hacker News Reader

I'd rather write rust than java, personally

If I have all the time in the world, sure. When I'm racing against a deadline, I don't want to wrestle with the borrow checker too. Sure, it's objections help with the long term quality of the code and reduce bugs but that's hard to justify to a manager/process driven by Agile and Sprints. Quite possible that an experienced Rust dev can be very productive but there aren't tons of those going around.

Java has the stigma of ClassFactoryGeneratorFactory sticking to it like a nasty smell but that's not how the language makes you write things. I write Java professionally and it is as readable as any other language. You can write clean, straightforward and easy to reason code without much friction. It's a great general purpose language.

Java is incredibly productive - it's fast and has the best tooling out there IMO.

Unfortunately it's not a good gaming language. GC pauses aren't really acceptable (which C# also suffers from) and GPU support is limited.

Miguel de Icaza probably has more experience than anyone building game engines on GC platforms and is very vocally moving toward reference counted languages [1]

[1] https://www.youtube.com/watch?v=tzt36EGKEZo

He would vouch as great as he might be, he has a bias, and Mono GC was never a great implementation.

Also here is how great his new Swift love performs in reality against modern tracing GCs,

https://github.com/ixy-languages/ixy-languages

Interesting link, but that's a nearly 7 year old version of Swift (4.2) running on Linux.

I wonder how the performance would be with Swift 6.1 which has improved support for Linux.

Probably much better, given the improvements on the Swift optimizer, but just goes to show "tracing GC" bad, "reference counting GC" good isn't as straighforward as people make it to be, even if they are renowned developers.

It's a cherry picked, out-of-date counter-example. Swift isn't designed for building drivers.

In reality, a lot of Swift apps are delegating to C code. My own app (in development) does a lot of processing, almost none of which happens in Swift, despite the fact I spend the vast majority of my time writing Swift.

Swift an excellent C glue language, which Java isn't. This is why Swift will probably become an excellent game language eventually.

> It's a cherry picked, out-of-date counter-example. Swift isn't designed for building drivers

Do you have a counter benchmark? The burden is on you here to disprove the data presented. What that benchmark shows is that you spend A TON of time counting references, much more than tracing GC, unless you enter Swifts C++ networking code. I would think games don’t spend most of their time calling into networking code.

> In reality, a lot of Swift apps are delegating to C code. My own app (in development) does a lot of processing, almost none of which happens in Swift, despite the fact I spend the vast majority of my time writing Swift.

So what you’re saying is that any language will be good for gaming since they all can delegate to C?

> Swift an excellent C glue language, which Java isn't. This is why Swift will probably become an excellent game language eventually.

What makes swift better at calling C than Java? AFAIK Java has a perfectly good and brand new foreign function interface.

> This is why Swift will probably become an excellent game language eventually.

I would take this bet that it won’t. Purely on the sheer fact that gaming occurs on Windows and Swift is barely capable there.

> I would think games don’t spend most of their time calling into networking code.

Exactly. That is why the out-of-date networking example being touted as evidence is irrelevant here.

What it boils down to is that Java and C have fundamentally incompatible memory models. Direct access to C memory is impossible because of the managed heap and GC.

> I would take this bet that it won’t. Purely on the sheer fact that gaming occurs on Windows and Swift is barely capable there.

This is a very odd comment - gaming occurs in a lot of places. Quite a lot happens on mobile these days. Turns out a lot of mobile devices run Swift, on which it appears to be reasonably capable.

And 70% of the mobile world runs Android, which is powered by Java, so it is equally capable.

Android does not run Java and you know that.

https://omeraydin.dev/blog/does-android-run-java

It surely is, according to Apple's own documentation.

> Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics.

-- https://developer.apple.com/swift/

If developers have such a big problem glueing C libraries into Java JNI, or Panama, then maybe game industry is not where they are supposed to be, when even Assembly comes to play.

> GC pauses aren't really acceptable

Java has made great progress with low-pause (~1 ms) garbage collectors like ZGC and Shenandoah since ~5 years ago.

People have 240hz monitors these days, you have a bit over 4ms to render a frame. If that 1ms can be eliminated or amortised over a few frames it's still a big deal, and that's assuming 1ms is the worst case scenario and not the best.

I don’t think you need to work in absolutes here. There are plenty of games that do not need to render at 240hz and are capable of handling pauses up to 1ms. There’s tons of games that are currently written in languages that have larger GC pauses than that.

What about the C# garbage collector? Is it much better? Because Unity is in C#, right?

Unity uses aginging Mono runtime, because of politics with Xamarin, before its acquisition by Microsoft, migration to .NET Core is still in process.

Additionally they have HPC#, which is a C# subset for high performance code, used by the DOTS subsystem.

Many people mistake their C# experience in Unity, with what the state of the art in .NET world is.

Read the great deep dive blog posts from Stephen Toub on Microsoft DevBlogs on each .NET Core release since version 5.0.

Yes and it's impressive.

For the competitive Minecraft player, I suspect starting their VM with XX:+UnlockExperimentalVMOptions is normal.

A casual gamer is however not going to enjoy that.

Are you sure that enabling ZGC or Shenandoah requires UnlockExperimentalVMOptions ?

Let's get back to the point. Is Java a good gaming language?

I have found that the ClassFactoryGeneratorFactories sneak up on you. Even if you don't want to the ecosystem slowly but surely nudges you that way.

That has not been my experience. Sure, you don't have any control over the third-party stuff but I haven't seen this issue being widespread in the mainstream third-party libraries I've used e.g. logback, jackson, junit, jedis, pgJDBC etc which are very well known/widely used. The only place I've actually seen proliferation of this was by a contractor, who I suspect, was trying to ensure job security behind impenetrability.

It is ironic how Java got that stigma and other systems that are just as bad, or worse, like Objective-C, have not.

Well I have never used Objective-C so I can't comment on it.

On Objective-C, due to the way the language works, besides ClassFactoryGeneratorFactories, you would need to add all parameter names to the identifier.

Here, enjoy https://github.com/Quotation/LongestCocoa

There is even a style guide on it,

https://developer.apple.com/library/archive/documentation/Co...

I'd have said the same thing 10 years ago (or, I would have if I were comparing 10-year-old Java with modern Rust), but Java these days is actually pretty ergonomic. Rust's borrow checker balances out the ML-style niceties to bring it down to about Java's level for me, depending on the application.

I’d rather write Java than Rust, personally

Same here, and if I get bored with Java, there is also Scala, Kotlin and Clojure to chose from.

However, I would still prefer C# or F#.

Hence why I enjoy both stacks, lots of goodies to chose from, with great tooling.

I would do C#, but I don’t want to be in async/await hell.

Also it’s subjective but PascalCase really irks me.

PascalCase has been my favourite since MS-DOS days, I have been through most Borland products, and Microsoft ones, alongside many Pascal influenced languages, thus it feels like home. :)

But yeah it is subjective, also don't have much qualms with other alternatives.

Wow, way to be un-hip.

Note that I mentioned JVM languages. There is Scala, Kotlin and others. Kotlin is the default for Android, and it is really nice.

Kotlin is nice indeed. Most of the issues I had with it were in interop with Java code (those pesky platform types, that behave like non-nullable but are nullable: and you are back in the NPE swamp!)

Reply on news.ycombinator.com