Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

I think that Jai / Zig / Odin all started around the same time.

D is closer to C++ than C, in my opinion.

I suspect that Jai was an inspiration for Zig and Odin.

Many developers in gamedev circles are still using C or orthodox C++ (C++ without most of the bullshit) but are frustrated by many features and gaps.

Short compilation time is one of the big goals, as it is crucial for fast iteration.

The goal is simply to have a powerful low-level/system language that is enjoyable to use. Or at least more enjoyable than C++. (the de-facto standard)

View on HN

If you can find very old Jai videos on YouTube, you can find the creator of Odin was one of the early people excited about the project.

I suppose if the development of Jai was made more in the open/public, Odin would probably not have existed.

That said, I'm glad Odin exists.

You can find the creator of Zig in those videos as well

I think that even if Jai didn't directly inspire Odin and Zig, seeing Jon's enthusiasm for his new language influenced GingerBill and Andrew Kelley in their work. This is only the conjecture of someone on the side, but the timeline fits pretty well in my opinion.

Right that makes sense.

I’m curious if the gaming industry will switch languages, it feels like with the current game engines that it’s heavily entrenched in C and C++. Feels like something like Carbon has the best chance to break in.

Only time will tell.

But I think there is an opportunity at this point in time.

A chunk has already switched to C# with Unity. Most other engines (proprietary, Unreal, etc) have decades of C++ that would require too much effort to migrate to anything new.

Unity is still written in C++. It's fairly common to write the core engine in C++ and use a language like Lua, or as is more common in AAA, some proprietary scripting language for gameplay code.

Interesting. I heard the Civilization games were Lua, didn’t know that was more common.

Quite common: https://en.m.wikipedia.org/wiki/Category:Lua_(programming_la...

I work on CorsixTH as a hobby which is also c++ and lua.

This kind of thing in general is very common and goes back decades, it's just that the languages used to be custom (QuakeC, UnrealScript etc) before the industry largely standardized around Lua. Some older games also experimented with Python for this, and I recall even seeing Tcl once.

Unity core, written by Unity employees, customers use C#, that is a big difference.

Also since Burst got mature, many C++ modules are slowly being rewritten in C#/Burst subset.

There are a number of Rust projects happening, but not overtaking c++ any time soon.

> D is closer to C++ than C, in my opinion.

In terms of what the language allows you to do, yes. However, if you're a C programmer, you can pretty much just keep writing the same code you've always written (minus the preprocessor, thankfully). You can even compile C code with the D compiler and call those functions from your D code without doing anything further. That's definitely not the case with C++.

Oh, come on now. I'm no C++ apologist, but you can do both of those things in C++ as well as in D.

I meant you can't do things like compile C++ code directly into your D project.

D is not at all like C++.

D is D.

You only need to compare how C++ and D treat a class type, and you know straight away they are miles apart (I prefer C++ in this regard).

D has a subset, and that subset is more like C - pretty much cause that subset is C. That can be interesting to use, since it's like C with modules.

But don't be fooled. D is not like C++.

I wish people would stop saying as such, cause it's not at all true.

You're right, in many areas it is more powerfull than C++23 is.

As for classes, just pretend you are using structs in C++, and use structs in D.

> D is closer to C++ than C

I'd put C++ as being between C and D, as D leaves a lot of things behind like the preprocessor.

.. you forgot to mention also, that (in the context of a D module) D stops treating a user-defined class-type as real type. Additionally, a D class is a reference type. Whereas in C++, a class type is a real type (treated as any built-in type), and is a value type (by default).

Nor does D have a concept of C++ friend.

So even when it comes to classes, C++ and D are miles apart.

D structs are value types, D classes are reference types. This was done to avoid mistakes like having a type that is sometimes used as a value type and sometimes as a reference type.

Would have been much better in my opinion, if D had maintained a C like struct (not a C++ like struct), and a C++ like class. That would have solved the problem you identified, while still allowing for the class to be what it was designed to be. The mistake C++ made was the mistake you identified. But the solution you provided in D is its own mistake.

The C++ class would require the user to constantly remember it has to be passed by reference, not by value. D making the class a reference type means the user cannot mix them up.

It has worked well from the beginning, it is not a mistake.

..and in the context of a module.. not even used as a type at all.

Honest question: as a GC’d language, D seems to occupy the same niches as Go, JVM-based, and CLR-based languages rather than that of C++. Wouldn’t it be more accurate to compare to them than C/C++? Am I misunderstanding something?

D isn't a GC based language. The GC can be used, or not used, as the user chooses. D supports many different programming paradigms.

Ah! Okay, that’s what I was missing. I found the blog posts on using malloc and free from D. I knew the GC could be disabled, but I wasn’t aware of how practical it was to manually manage memory. Thanks!

It's not necessary to disable it, just don't use it.

Reply on news.ycombinator.com