Live data from Hacker News

Porting 58k lines of D and C++ to Jai

yet-another-blog.com

101–110 of 264 posts

Re: Porting 58k lines of D and C++ to Jai

#101
post #21

Earlier quoted context omitted.

Over the past decade, I watched HN's and Reddit's hype waves cycle through server-side JavaScript, Golang, Haskell, and now Rust. With plenty of secondary favorites in the mix like Julia, Nim, Zig, etc. A lot of these things do find some modest niche to survive in. But none really take over the world as originally forecast by the hype wave. Ultimately, you either enjoy tinkering with programming languages for persona…

I'm starting to actually believe that Rust will eat C's lunch for systems programming.

I think there is a space for other alternative low-level languages that aren't that strict about compile-time safety though (Zig, Jai, Odin), that Rust cannot capture.

Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at runtime (generational indices/references, Address Sanitizer, and recently Zig's safety mode). We need to explore multiple directions to really solve the memory safety problem, and I don't think Rust is the only way (although it is a viable way, proven by some recent successful applications).

Re: Porting 58k lines of D and C++ to Jai

#102
post #50

This person might as well said that he is not planning to finish his game. Screwing around with tooling and languages seems to be a common pitfall to not finishing a game. Why not just use the best ecosystem like Unreal/Unity and get the game out of the door fast?

Rewrites in whatever language or tool catches your eye are a common pitfall (although you often learn a lot in the process), but moving to Unity would also be a rewrite. It might be a harder rewrite, in fact, because the author would have to adapt to a new language and a new engine. They might be able to use Unity features instead of rewriting some code but they’d still have to figure out how to use those features.

Re: Porting 58k lines of D and C++ to Jai

#103
post #4

It's worth mentioning that DMD is a reference compiler and not meant as a production tool. DMD is for fast compile time during dev cycles and testing new language features early. You've got the LLVM and GCC compilers for production. The problem with lack of debug info on Windows in D is solved by using LDC with LLDB/GDB to debug You can also ask the compiler to emit CodeView debugging info if you want to stick with M…

He was complaining about the long compile times of LDC2 even in debug mode, and said that it uses too much memory up to the point that the laptop can't handle. So I understand why he was using DMD for development.

Re: Porting 58k lines of D and C++ to Jai

#104
post #15

Earlier quoted context omitted.

> Supports x86 architecture only No native macOS then? > No virtual functions > Jai is less dogmatic okay

> No native macOS then? Or Pi, or iOS, or practically all Android hardware… Kind of a non-starter IMO. Maybe this was marginally acceptable when the language started in '14 but it becomes less so every year.

Given that he and his team are developing a language and a game in that language at the same time it makes sense to focus on the primary platforms they work on, and expect their game to currently run.

Their primary platform is Windows, and the game in its current very early state is also running on Windows.

What's the value in porting it to Raspberry Pi or Android?

From the streams it looks like a Linux port is usually mostly up to date, and MacOS understandably lags behind. But neither of these platforms have any high priority for now.

Re: Porting 58k lines of D and C++ to Jai

#105

Earlier quoted context omitted.

That’s fair, but if you look at his posts about the language, he also makes a big point about how he doesn’t want any input from people with an academic background in language & type theory. This smells like anti-intellectualism to me. I’m a bit concerned that some of the decisions that he’s making in the language are leading towards traps that have caught other language designers in the past, but because he’s reject…

I think his disdain towards academia isn't really anti-intellectualism (he's not ignorant of compiler theory knowledge, otherwise he wouldn't have been able to write a compiler from scratch in the first place! And his interest in programming languages seems to span decades, from what I remember from one of his streams). I think he's critical of the fact that the primary focus of academia and industry in computer scie…

I’d have to say that academic research into programming languages has provided immense benefits for actual programmers over the years, it just has such a long lead time that people forget that the research came out of academia in the first place. People also don’t really understand the process of how these ideas come from academia into mainstream programming languages.

It only seems like academic research has diverged because the benefits of current research haven’t materialized as real, usable features in programming languages that people use to get work done. But if you look at features that we use in day-to-day programming right now, you can trace the heritage of these features back to research programming languages (like Self or Haskell) and then farther back to more abstract research into esoteric subjects like category theory and substructural logic.

The esoteric parsers that people invented in the past were, in a sense, necessary because people were ignorant of how to design languages in such a way that they could support a rich syntax without using a complicated parser. It took a lot of academic research for us to figure out that, say, you could probably use an LALR parser for lots of existing languages, and you could stick to LL(1) for new designs.

Re: Porting 58k lines of D and C++ to Jai

#106
> there’s also the general feeling that the D creators’ vision of what a fixed C++ looks like is just vastly different from mine

I have emphasized for years that D is not C++. It can be used as a replacement for C++, in the sense that it does the same things, but it is not accurate to call it a "fixed C++". So many times I have seen C++ programmers disappointed that D is not C++. On the other hand, if you're a C programmer, you'll probably be comfortable writing D code. I think of D and C++ as incompatible forks of C.

Re: Porting 58k lines of D and C++ to Jai

#107
post #39

Earlier quoted context omitted.

It’s hard to find any material on Jai. It seems to be a “better C”. Isn’t that what D / Zig try to do? What’s the advantage?

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 h…

> 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++.

Re: Porting 58k lines of D and C++ to Jai

#108
> a big chunk of these vulnerabilities would not exist if C and C++ [...] simply didn’t have zero-terminated string, initialized values by default, had a proper pointer+length type thus replacing 90% of pointer arithmetic with easily bounds-checkable code, and had established a culture that discouraged the prevalent ad-hoc style of memory management.

This is Rust's calling-card, so I find this plea for a better lang / eco rather jarring after dismissing Rust for somehow "making the wrong tradeoffs".

Re: Porting 58k lines of D and C++ to Jai

#109

Earlier quoted context omitted.

If the game was a more typical 3D action-adventure or FPS/TPS shooter, then using one of the two engines might have been much better for development time. But this is a complex 2D sandbox simulator with procedural generation and a custom physics engine, so I'm not sure how Unity or Unreal might aid in developing this game in any way.

I’ll pick Unity to talk about here, because I have the most experience with Unity. I’ve gone in more depth discussing Unity “off the beaten path” before and I think people really overestimate how much you are constrained by the way Unity works. This applies both to seasoned Unity developers and to people who only take a quick look at Unity. I claim, - You can use your own physics engine with Unity, - You can model en…

Since you seem to have much more experience in developing games, I'll take most of your word here.

Though from my four years of experience in Unity (albeit at a non-professional level), I was always fighting with the engine when trying to build new things. Trying to build complex UI code using Unity's built-in system was a mess, the serialization system always had weird errors and didn't really work well with version control, adding custom rendering to the rendering engine was full of hacks, and the documentation was quite poor for the more obscure/hidden aspects of the engine up to the point that I was thinking "I can just write these in C++/OpenGL, why do I have to go through all of this crap?". Nowadays I do gamedev at a lesser capacity (and doing more general graphics programming in C++ instead), and since several years ago I haven't really looked too deeply into the engine. I think doing all of these in Unity isn't impossible, just that I'm expecting a lot of friction while doing it.

There always seems to be some really good indie developers who are stretching Unity to its limits though (such as Manifold Garden). I always wondered how much they were fighting with the engine to make some specific features.

Re: Porting 58k lines of D and C++ to Jai

#110
post #61

Earlier quoted context omitted.

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 h…

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.

Post reply on HN