Hacker News Reader

Comment by LAC-Tech | Hacker News Reader

D is easy to pick up, and has three really fast compilers. It feels like a very practical language.

Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway.

And I really question what these situations are where you can't have garbage collection in 2021. Hard real time systems, sure, but that's not what 99% of people are using rust for. Maybe people just like the challenge.

View on HN

>And I really question what these situations are where you can't have garbage collection in 2021.

Game development, anything with a UI (GC pauses frustrate users), anything that needs high performance (scientific applications, data analysis), you name it. Ownership semantics have a side-benefit of automatic thread safety; something that is less important than memory safety (because many programs can work in one thread but almost no programs can work without allocation) but extremely valuable when needed.

>Game development

C# Unity, Lua Love 2D,...

>anything with a UI (GC pauses frustrate users)

Millions of C#, Java, Python, Javascript UI apps

>anything that needs high performance (scientific applications, data analysis)

Numpy, Julia,...

Using non garbage collected languages for 99% of apps today is a waste of time, and i'm saying this as mostly an embedded developer.

You listed a bunch of engines written in C and C++.

How does that matter? You said "game development", not "writing a game engine". You said "data analysis", not "writing linalg algorithms", in which case we'd all have to bow to Fortran anyway.

Your argument also doesn't apply to GUI apps, anyway. C# and Java amount to a huge number of such apps, and they're self-hosted.

GC languages are vastly more productive that manual-memory languages, and for the vast majority of users, that is worth the performance hit.

If your suggestion is, "GC languages can be used to write anything so long as whatever parts can't be written in a GC language are written in a non GC language," then yes that's true. But it's also a tautology.

If you need to stay away from the GC because of some practical reason, you can always write C/C++/Rust. You implied that this is a frequent situation when it isn't. Your example of "anything with a UI" was quite a bad one.

Most projects are better off written in a GC language because the productivity benefits outweigh the performance costs.

There is a lot being said about productivity gains from GCed languages, but can you actually point me to any research showing these gains are real?

My anecdotal, unscientific experience shows that GC is a double-edged sword that maybe makes writing simple programs slightly faster, at the expense of a much worse maintainability once the code base gets big. And non-memory resource management in GCed languages without RAII is a really huge PITA that kills all productivity gains.

GC allowed memory safety until Rust happened, and that was a big gain, but now that point is moot.

In practice it is even not true, because there is a non-zero cost of interfacing between managed runtime and native non-managed code. Therefore not every piece of code that would theoretically benefit from writing in a non-managed language, could be actually rewritten.

Unreal then,

https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScrip...

Or you prefer anything written in DirectX or Metal?

Chapter 5 from The Garbage Collection Handbook.

https://gchandbook.org/contents.html

Unreal is written in C++ but, like Unity, can be scripted in other languages. Like unity it fits the "GC language for high level scripting of non-gc code" pattern. There is certainly no debate about the feasibility of implementing game logic in Lua. Reference counting in graphics drivers is not comparable to GC in Java or C# because its lack of generality permits the use of faster algorithms that don't GC pause. Swift is a workable systems language with reference counting built in, but you should bear in mind that it doesn't have "a garbage collector" per se, like you would imagine when you hear that a language is GC'd.

Reference counting pauses when cascading deletions take place, it well known domino effect.

C# allows for GC free regions with GC.TryStartNoGCRegion, manual memory management via MarshalServices, stackalloc, Span<>() and value types.

Almost forgot Unreal C++ is GC based for entities and anything Blueprint related.

Audio plugins is one case. Dplug disables the GC because of an issue on MacOS. So far there is no workaround so we have to write @nogc code.

On Windows you can use C# for audio plugins.

https://docs.microsoft.com/en-us/windows/uwp/audio-video-cam...

Reply on news.ycombinator.com