Live data from Hacker News

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

yet-another-blog.com

221–230 of 264 posts

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

#222
post #142

> In my eyes, the most important ones are faster compilation and allowing metaprogramming via unrestricted compile time execution. I'm fascinated by languages that are adding more compile-time programming features, in the context of a low-level performance-oriented use case. Would love to know more about the history and state of the art of this area.

That actually makes a lot of sense to improve performance on specific parts. Think about generating lookup tables at compile time for example. Instead of having a separate script generating them, you can keep the generation close to the place you use it, written in the same language and always up to date.

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

#223
post #147

Earlier quoted context omitted.

I'm curious - what you think of as a good example? I think of C++ templates & macros, which I would not describe as arising from restrictions?

Template metaprogramming in the absence of constexpr/concepts would be my guess.

That would be the relevant example.

Compile-time code restriction seems dumb. Programers can write any program they wish, stopping them for some ideological reason isnt effective. As with all the half-baked metaprogramming people restort to anyway.

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

#224
post #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…

Yes and no.

No because Rusts bigger calling card is the borrow checker, which adds a lot of complexity besides other things in Rust, and even leads to justifying unsafe (because some optimized correct data structures are just not possible with it).

Second no, because if Rust calling card is that, you can have this alone even in the most hated unsafe C++ if you limit yourself and admit to doing it right. If you quote that sentence you must also quote his calling card, which is about culture and complexity of language:

> In addition to this, I think the most important reason we have so many vulnerabilities (and bugs in general) is completely disregarded in the hunt for “safe” code: culturally tolerated and even encouraged complexity14. In conclusion, putting up with Rusts compile times and submitting to the borrow checker seems like an extreme solution that doesn’t address the most important problem, which is a cultural one. Jai on the other hand is extremely concerned with complexity and tries to get the cultural part right.

And in that regard I agree with him, definitely better there than C/C++, BUT NOT MUCH!

That's why I fully agree, Rust may be not it, and something like Zig, Jai, Carbon or even Herb Sutters safec++2 thing may shine one day more..

Rust is overfocusing on the memory safety part, which adds too much complexity while not even being able to get fully rid of unsafe..

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

#225
post #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…

This is also C++20’s calling card. It has `std::span`.

Nope, unless you're compiling in debug mode, or force enable bounds checking in release.

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

#226
post #6

I'm really interested to see Jai in the wild, but I have to say I find the Jai v.s. Rust comparison here...unconvincing to say to least. It's particularly funny to be excited about "being able to do anything during compilation" using Jai and then complain to that the #1 problem in programming is "culturally tolerated and even encouraged complexity."

I'm also frustrated at a language in closed beta being perpetually compared to a language that is open source and in production. It's a complete apples to oranges comparison. By being in closed beta, there is no way of verifying anything said about Jai. Instead you have to take the word of people in the Jai community, which is a very biased source to say the least.

People aren't used to seeing languages (, products) developed in a "visible but closed" beta. It is, initially, quite confusing.

It makes more sense to see it like game development, which I think it's blow's pov. He's not an open source developer, he's a game developer. And he's making a product he wants to be complete and correct before release.

I think there's quite a lot of good-will towards Blow, and I imagine he has some clout in the game dev. community. My sense is that when he releases his game written in this, and gives it its final syntax-and-semantics pass -- he will get buy-in from some places (esp. indies).

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

#227

Earlier quoted context omitted.

This is also C++20’s calling card. It has `std::span`.

Spans/slices are getting incredibly common in as a fundamental building block in modern (or modernized PLs). C# also has Span , Go and Rust both have slices etc. We are at the point where they should be standardized on ABI level, IMO, before things get too messy compatibility-wise.

Enter COM and WinRT, if only the tooling wasn't so stuck in the stone age of early 2000's.

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

#228
Fast compilation seems very appealing. It is one of the main reason why I am interested into Go and Zig.

I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. The compilation and IDE experience is frustrating. Compilation is slow. I am afraid that this is rooted to the inherent complexity of Rust.

[1] https://github.com/rome/tools

[2] https://github.com/denoland/deno_lint

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

#229
post #127

Earlier quoted context omitted.

I'm not seeing a major problem here, you just need to install MSVC++ alongside it.

Its an extra requirement, thats not imposed by many other languages.

Rust and Go (for cgo) require it as well.

As do Python, Ruby, Tcl, node and Java if you want to write native extensions.

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

#230
post #133

Earlier quoted context omitted.

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.

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.

Post reply on HN