> 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".
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..
If I'm reading OP right, their issue with Rust is the borrow checker - none of those features require one. They're asking for a language that's safer than C, not as safe as Rust, but simpler and easier to ram things through. I don't necessarily agree, but I think that's what they're saying.
Yeah, I think Bevy[1] is also a great example of something that fits in well with a lot of Rust's strengths while also showing that it's possible to lean in heavily to very gamedev centric approaches with how it approached ECS.
I think there's is some truth around try to avoid unsafe, that said the times I've dropped down into it I've found myself chasing heap corruption or use-after-free on more than one occasion :).
Some of Jai's AoS/SoA transforms look neat and certainly interested to see what it looks like once it starts opening up more.
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."
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 Microsoft stuff
The author's chief complaint appears to be that dmd produces incorrect debug info on Windows, something I'd expect a reference compiler to do. A reference compiler doesn't have to be fast, but it does need to be correct.
I don't think "DMD is a reference compiler and not meant as a production tool" is a great way to characterize it. There are certainly valid reasons for choosing LLVM and GCC for "production", but also valid reasons for choosing DMD.
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.
I find the "slow compile time" complaint of D interesting; overall I find ldc2 to be one of the faster compilers out there. I suppose the combination of features and metaprogramming used by the author is responsible for the 3-minute compile times in debug mode. While jai is evidently expected to be substantially faster (author estimates 5 sec for this codebase???), other choices like Rust would be far, far slower than D.
This expectation comes from jai compile times for the game Jonathan Blow is developing: https://www.twitch.tv/j_blow It takes about 2.5 seconds to compile and link over 168k lines of code in debug mode.
I'm not sure that if passing from a widely used language to a marginal language wasn't a success why going from a marginal language to a totally obscure one will be
An obscure language custom built for the purpose of writing computer games and by a developer with razor sharp focus on making it better who is very responsive about bugs submitted by the people with access to the beta.
I don't understand why they are not working in the open, this is a tool, not a game, input for a large community is extremely valuable.
But as brilliant as Jon Blow is, he is at least equally as stubborn.
Fast compilation and nice, easy to read syntax with good default is exactly what I am looking for.
I can understand the hype about metaprogramming, and its potential usefulness, but I also think this is a pandora box.
Pretty much like C macros and C++ templates, overuse can lead to a very messy codebase, hard to read, hard to debug, with a lot of unexpected side effects.
I don't see why a language can't be one guy's passion project. Even if he releases it and it turns out he's the only person that likes it, so what? It's not like he's had millions in VC or government investment dumped into it or something. He's got some ideas and he's implementing them. I'm interested to see how it turns out.
Golang has had success and was primarily made in private by 3 guys and hasn't strayed too far from the original founding principles they came up with.
> input for a large community is extremely valuable
In the early stages, everyone has a thousand opinions and it’s not clear even to those working in jai daily what exactly the language wants to become and which patterns should be supported. From what I understand, Blow intends to gradually open things up as the project matures, which I think is 100% the right approach for something fairly experimental and with a lot of new ideas.
> input for a large community is extremely valuable
it’s also an extreme time suck. Having everyone opine on their pet feature would just take away from the focused work the people at Thekla are doing.
Honestly, I don’t even see why Jon should make things open source (apart from it being a major incentive for people to adopt it). The performance improvements they are offering compared to other languages 100% warrant charging for it.
I wrote an extremely hard and complex program in which I had to use c++ metaprogramming throughout. Not my decision. I do not understand why you could possibly need more metaprogramming than C++ provides. This is a problematic feature to begin with. Not worthless but not worth much. The debugging was difficult. Many problems show up buried in literally thousands of compiler error messages.
That's the issue with C++ metaprogramming. It's so unwieldy and complex that the benefits are difficult to see and the occasions to be worthwhile limited. When the language has better (i.e. simpler) facilities for meta-programming like D, it will open big venues where it makes sense to use it.
It is like programming object oriented in C, it is possible to do but so unwieldy and requiring discipline and verbose boiler plate that there's rarely an occasion where it would be interesting to use. While it is much easier to do in C++ or D or Java (etc.) as they provide the abstractions that makes it useable. C++'s meta-programming facilities are not good enough.
The problem with C++ metaprogramming is not what you can do with it, it's how you do it; which, IME, is always the most convoluted, unsafe way possible.
The “siamese brothers”-ization of templating & metaprogramming is especially painful.
“In the beginning I hinted at expecting the porting process to go somewhat smoothly (which I’m sure I won’t regret later). The reason for this is that I have two systems in my game that will hopefully be immensely helpful in this endeavor:
- The game records the inputs (HID, loaded files, network, …) of a play-session into a file and replay them later. When replaying, feeding recorded input into the deterministic game loop leads to the exact same state, down to the bit.
- The game hashes game state at various points during execution and saves these hashes to a different file. When replaying, the contents of this file can be used to check that the execution of the replayed session exactly matches the original execution.”
Can't wait to see how this progresses. So far the only source of knowledge have been Blow's streams, but he's the author, and he knows his language inside and out. It will be immensely interesting to see other people's experiences.
> 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.
> So many times I have seen C++ programmers disappointed that D is not C++.
More generally, every time I learn a new language, it is always frustrating, because I cannot write the same thing in the new language that I was used to writing in the old. It takes time until one starts thinking in terms of the new language, and only then will the frustration fade.
Yes, we can agree that D is not like C++ - not at all.
The reason C++ programmers are usually disappointed, is because D gets marketed as such (it's the bait you need to get them to look at D afterall).
In fact, even on the basic class type, C++ and D are really miles apart. Make no mistake about this - they are miles apart, even on this one construct (the same contruct for there being a C++ in the first place).
It is clear when you use D, that it wasn't designed to be like C++.
D does have a subset that is C like, and that's primarly because it is, in essence, C.
So D is D.
D is not at all like C++.
A subset of D is like C (cause it is - more or less - C).
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.
> The largest elephant in the room to address is probably Rust. ...
Breaking this down, I can only find two practical problems the author has with Rust:
- long compile times
- the ownership model ("the borrow checker")
The rest of this paragraph appears to be much more general in nature.
Given that the project is only 58,000 lines of D/C++, it's hard to believe that compile time alone is so bad as to drive a decision toward an experimental language like Jai.
So it appears that the main problem the author has is the ownership model ("the borrow checker"). It would be interesting to know more, but the author does not elaborate.
AFAICT, the Rust compiler can be viewed as enforcing the good practices that C++ developers already recognize. So how can this be an issue at all, especially given the ability break out of the ownership model into unsafe Rust (or use other tricks) if the situation calls for it?
"That said, D definitely has some advantages over C++, like more powerful metaprogramming, no need for headers, no uninitialized values and more. But unfortunately, these upsides are outweighed by the downsides."
Yes, after working with D for far too long, I have decided to delete it off my computer and I'm going back to C++, where a class is still a first-class 'type', and a 'value' type at that (at least by default).
In D, a class is a reference type only and worse, the D language has no means of declaring, let alone enforcing at compile time, a perimeter around such a type, within the so called 'D module'. The entire D module is within the perimeter of your class type, at all times!
> 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.
Very interesting! Apparently a lot of information on the Internet about the Jai language is outdated which makes me curious about the follow up post!
I don't know if OP is the blog owner. If yes, I'd love to have an option to subscribe to an email list. I've installed an RSS feed but email is still my preference. Thanks!
> All information for building a program is contained within the source code of the program. Thus there is no need for a make command or project files to build a Jai program.
I heard about this "promising" language as a youngster and never heard of it again, it doesn't seem to have taken off after all these years, and probably it's too later for it ever take off.
All I keep finding are youtube videos and twitch streams, which are the worst way for me to learn about a programming language. I guess it’s still not generally available?
[+] [-] ibiza|3 years ago|reply
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".
[+] [-] WalterBright|3 years ago|reply
https://www.digitalmars.com/articles/C-biggest-mistake.html
When I look at buglists for C programs out in the field (homework for any language designer!), array overflows are the #1 problem.
[+] [-] throw827474737|3 years ago|reply
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..
[+] [-] wk_end|3 years ago|reply
[+] [-] vvanders|3 years ago|reply
I think there's is some truth around try to avoid unsafe, that said the times I've dropped down into it I've found myself chasing heap corruption or use-after-free on more than one occasion :).
Some of Jai's AoS/SoA transforms look neat and certainly interested to see what it looks like once it starts opening up more.
[1] https://bevyengine.org/
[+] [-] winter_blue|3 years ago|reply
Doesn't the Linux kernel zero out memory pages that are accessed by a process, before they've been written to?
I guess it doesn't matter, since the larger concern is that the process could accidentally read its own freed blocks....
[+] [-] BenFrantzDale|3 years ago|reply
[+] [-] aeturnum|3 years ago|reply
[+] [-] gavinray|3 years ago|reply
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 Microsoft stuff
[+] [-] Xorlev|3 years ago|reply
[+] [-] mattarm|3 years ago|reply
[+] [-] svnpenn|3 years ago|reply
LDC for Windows is an awkward experience:
https://github.com/ldc-developers/ldc/issues/4047
[+] [-] cyber_kinetist|3 years ago|reply
[+] [-] chromatin|3 years ago|reply
[+] [-] dmitriid|3 years ago|reply
This expectation comes from jai compile times for the game Jonathan Blow is developing: https://www.twitch.tv/j_blow It takes about 2.5 seconds to compile and link over 168k lines of code in debug mode.
See e.g. https://www.twitch.tv/videos/1659970118 at around 30 seconds in
[+] [-] p0nce|3 years ago|reply
[+] [-] poulpy123|3 years ago|reply
[+] [-] mariusor|3 years ago|reply
[+] [-] unwind|3 years ago|reply
I guess "yes", it seems so pointless otherwise.
Would be very interesting to see e.g. "here is how this (gnarly) C++ turned into beatiful jai", zoomed-in to actual code level.
[+] [-] sbarre|3 years ago|reply
[+] [-] vinyl7|3 years ago|reply
[+] [-] stephc_int13|3 years ago|reply
I don't understand why they are not working in the open, this is a tool, not a game, input for a large community is extremely valuable.
But as brilliant as Jon Blow is, he is at least equally as stubborn.
Fast compilation and nice, easy to read syntax with good default is exactly what I am looking for.
I can understand the hype about metaprogramming, and its potential usefulness, but I also think this is a pandora box.
Pretty much like C macros and C++ templates, overuse can lead to a very messy codebase, hard to read, hard to debug, with a lot of unexpected side effects.
[+] [-] hbn|3 years ago|reply
Golang has had success and was primarily made in private by 3 guys and hasn't strayed too far from the original founding principles they came up with.
[+] [-] seabass|3 years ago|reply
In the early stages, everyone has a thousand opinions and it’s not clear even to those working in jai daily what exactly the language wants to become and which patterns should be supported. From what I understand, Blow intends to gradually open things up as the project matures, which I think is 100% the right approach for something fairly experimental and with a lot of new ideas.
[+] [-] _trackno5|3 years ago|reply
it’s also an extreme time suck. Having everyone opine on their pet feature would just take away from the focused work the people at Thekla are doing.
Honestly, I don’t even see why Jon should make things open source (apart from it being a major incentive for people to adopt it). The performance improvements they are offering compared to other languages 100% warrant charging for it.
[+] [-] henry_viii|3 years ago|reply
https://github.com/aardappel/lobster
The language seems to be exactly what he was looking for - a high-performance high-level language specifically designed for video games.
[+] [-] 3a2d29|3 years ago|reply
It seems to be a “better C”.
Isn’t that what D / Zig try to do? What’s the advantage?
[+] [-] bsder|3 years ago|reply
Ayup. Talking about JAI is simply a waste of time until they put it in the open under a genuine open-source license.
Otherwise, you wind up with situations like "Our Machinery".
[+] [-] uvtc|3 years ago|reply
> Fast compilation and nice, easy to read syntax with good default is exactly what I am looking for.
> [re metaprogramming] ... but I also think this is a pandora box.
Sounds like you might also like [Hare](https://harelang.org/). (has some work-in-progress [SDL2 bindings](https://git.sr.ht/~sircmpwn/hare-sdl2))
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] cleandreams|3 years ago|reply
[+] [-] gallier2|3 years ago|reply
[+] [-] shakow|3 years ago|reply
The “siamese brothers”-ization of templating & metaprogramming is especially painful.
[+] [-] P5fRxh5kUvp2th|3 years ago|reply
Then it was shown to be turing complete so people started using it as such.
The over time it started getting more and more things constexpr such that it's easier to execute during compile time (because it's turing complete).
Jai just made the decision that everything is constexpr by default.
And the answer to your question is that it's easier to do in Jai (in theory) than C++.
[+] [-] andai|3 years ago|reply
- The game records the inputs (HID, loaded files, network, …) of a play-session into a file and replay them later. When replaying, feeding recorded input into the deterministic game loop leads to the exact same state, down to the bit.
- The game hashes game state at various points during execution and saves these hashes to a different file. When replaying, the contents of this file can be used to check that the execution of the replayed session exactly matches the original execution.”
[+] [-] dmitriid|3 years ago|reply
[+] [-] bachmeier|3 years ago|reply
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.
[+] [-] WalterBright|3 years ago|reply
More generally, every time I learn a new language, it is always frustrating, because I cannot write the same thing in the new language that I was used to writing in the old. It takes time until one starts thinking in terms of the new language, and only then will the frustration fade.
[+] [-] SilentLambda|3 years ago|reply
The reason C++ programmers are usually disappointed, is because D gets marketed as such (it's the bait you need to get them to look at D afterall).
In fact, even on the basic class type, C++ and D are really miles apart. Make no mistake about this - they are miles apart, even on this one construct (the same contruct for there being a C++ in the first place).
It is clear when you use D, that it wasn't designed to be like C++.
D does have a subset that is C like, and that's primarly because it is, in essence, C.
So D is D.
D is not at all like C++.
A subset of D is like C (cause it is - more or less - C).
[+] [-] conaclos|3 years ago|reply
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
[+] [-] johnisgood|3 years ago|reply
[+] [-] SevenNation|3 years ago|reply
Breaking this down, I can only find two practical problems the author has with Rust:
- long compile times
- the ownership model ("the borrow checker")
The rest of this paragraph appears to be much more general in nature.
Given that the project is only 58,000 lines of D/C++, it's hard to believe that compile time alone is so bad as to drive a decision toward an experimental language like Jai.
So it appears that the main problem the author has is the ownership model ("the borrow checker"). It would be interesting to know more, but the author does not elaborate.
AFAICT, the Rust compiler can be viewed as enforcing the good practices that C++ developers already recognize. So how can this be an issue at all, especially given the ability break out of the ownership model into unsafe Rust (or use other tricks) if the situation calls for it?
[+] [-] SilentLambda|3 years ago|reply
Yes, after working with D for far too long, I have decided to delete it off my computer and I'm going back to C++, where a class is still a first-class 'type', and a 'value' type at that (at least by default).
In D, a class is a reference type only and worse, the D language has no means of declaring, let alone enforcing at compile time, a perimeter around such a type, within the so called 'D module'. The entire D module is within the perimeter of your class type, at all times!
[+] [-] zengid|3 years ago|reply
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.
[+] [-] Corendos|3 years ago|reply
[+] [-] pietmichal|3 years ago|reply
I don't know if OP is the blog owner. If yes, I'd love to have an option to subscribe to an email list. I've installed an RSS feed but email is still my preference. Thanks!
[+] [-] haolez|3 years ago|reply
Ok, now I'm curious. Will have to check it out.
[+] [-] flykespice|3 years ago|reply
[+] [-] shp0ngle|3 years ago|reply
All I keep finding are youtube videos and twitch streams, which are the worst way for me to learn about a programming language. I guess it’s still not generally available?