Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yet-another-blog.com

Post reply on HN
Print view View original

231–240 of 264 posts

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

#231

Post by pjmlp »

SilentLambda wrote: post #201
bachmeier wrote: post #107

Earlier quoted context omitted.

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

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…

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.

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

#232

Post by SilentLambda »

WalterBright wrote: post #203
SilentLambda wrote: post #199

Earlier quoted context omitted.

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

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

#233

Post by bartwe »

flohofwoe wrote: post #220
frozenport wrote: post #219

Earlier quoted context omitted.

Its an "input only" type, aka don't return it, but use it as an argument

That's just by convention though, right? C++ doesn't prevent me from storing the std::span somewhere so that it outlives the scope of the called function? IMHO it's disappointing that C++ adds new memory management footguns without first fixing the basics (like at least some rudimentary lifetime tracking to help with such situations).

c# got this right, enforcing the lifetime of Span

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

#234

Post by bartwe »

3a2d29 wrote: post #61
stephc_int13 wrote: post #47

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.

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

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

#235

Post by lifthrasiir »

naikrovek wrote: post #207
klodolph wrote: post #80

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…

it isn't anti-intellectualism at all, it's that he gets asked questions by people in college as well as college grads continuously and the questions they ask are indicating that the things being taught in higher education are absolutely not the kinds of things that he sees in his day to day work. to be fair to Jon, he works in a subset of software development that most do not: video games. the kinds of problems that…

I had been a game developer for last 7 years and I disagree. Most game developers do not have that much expertise to start with, because it has been a long time that low-level optimization makes or breaks your game. They tend to lean to proven techniques to the point that they have consistent aches like your aging grandparents but still keep using them because complaints alone don't break their games. The ratio of game developers capable of optimizing things at that level is roughly same to (or possibly even lower than) the ratio of comparable non-game developers.

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

#236

Post by klodolph »

naikrovek wrote: post #207
klodolph wrote: post #80

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…

it isn't anti-intellectualism at all, it's that he gets asked questions by people in college as well as college grads continuously and the questions they ask are indicating that the things being taught in higher education are absolutely not the kinds of things that he sees in his day to day work. to be fair to Jon, he works in a subset of software development that most do not: video games. the kinds of problems that…

I think I’ve never heard someone romanticize a profession as hard as what you’ve done here. This comment paints a truly distorted and unrealistic picture of game developers.

Game developers are not radically different from other developers. You see game developers leave the game industry and become programmers somewhere else, or you see programmers in another industry become programmers in the game industry. It is not a big deal.

While you could find some game developers who care about saving a couple bytes to fit something in a single network packet, you can equally find developers elsewhere who care about the same thing. Shave some time off your latency numbers and people stay on your website or app, they buy things or watch ads, your company gets money, you put it in your performance review. That’s just the most boring example I could think of. There are more interesting examples. Most programmers are simply not interested in saving a few bytes or a few cycles because they have features to work on. That includes game developers.

We fetishize low-level programming too much. Low-level programming is, in a sense, easy, because you are working with components that are simpler and have better documentation.

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

#237

Post by germandiago »

raverbashing wrote: post #216
tialaramex wrote: post #184

Earlier quoted context omitted.

But remember all C++ defaults are wrong, and so of course std::span isn't bounds checked While your Rust slice will yell at you (at runtime if it can't figure it out at compile time) when you try to index into the fifteenth item in a ten item slice, C++ has Undefined Behaviour in this case.

> But remember all C++ defaults are wrong Honest truth right here.

Some are not. Many are.

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

#238

Post by germandiago »

flohofwoe wrote: post #220
frozenport wrote: post #219

Earlier quoted context omitted.

Its an "input only" type, aka don't return it, but use it as an argument

That's just by convention though, right? C++ doesn't prevent me from storing the std::span somewhere so that it outlives the scope of the called function? IMHO it's disappointing that C++ adds new memory management footguns without first fixing the basics (like at least some rudimentary lifetime tracking to help with such situations).

Yes, in C++ you can also do this:

``` int & a = *new int; ```

And it would be as stupid as juggling with spans around liberally.

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

#239

Post by germandiago »

cyber_kinetist wrote: post #113
googlryas wrote: post #78

Earlier quoted context omitted.

If there's enough actual interest, some group of people will just clone the language in an open manner since enough is known about it. But that doesn't seem to be happening at the moment.

I thought Odin was one of the clone languages at the start (although later it diverged from Jai in many aspects, and is far ahead Jai in the aspect that it's open-source and is actually being used in production). But really I would like Jai to take some time to mature over the years, instead of rushing out for an immediate public release. It has some very ambitious ideas that would absolutely be killer features, but…

which killer features?

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

#240

Post by cyber_kinetist »

throw827474737 wrote: post #224
ibiza wrote: 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…

Absolutely agree, it’s one thing to get terrified at the complexity of the borrow checker, and another thing to get terrified by the complexity of Unsafe Rust (“the-thing-that-must-not-be-mentioned” in the Rust community).

I think the solution for memory safety (which the fundamental problem stems from us having to deal with a linear address space) can only be fully tacked with a combination of compile-time and runtime features, but in my opinion Rust goes too overboard on the former and sacrifice too much actual language usability.

Really like to see new experiments like generational references (https://verdagon.dev/blog/generational-references) being researched as an alternative to Rust’s ‘type-systems-approach’ towards memory safety.

Or maybe someday we might finally have thorough tagged pointer support in hardware (like what CHERI is doing) and system-level programmers will rejoice in joy.

Post reply on HN