Porting 58k lines of D and C++ to Jai • Hacker News Board

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

#261

Post by winter_blue » Mon, Nov 28, 2022, 4:35 PM UTC

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…

> initialized values by default

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

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

#262

Post by nomel » Wed, Nov 30, 2022, 1:03 AM UTC

jessermeyer wrote: post #254

nomel wrote: post #177

Earlier quoted context omitted.

> They are very difficult to use if the game play semantics are complicated and require lots of interaction with world state or world geometry. Could you give an example? I’m trying to understand what the limits look like. It appears to be trivial to you, but for someone outside of game design, I can’t imagine what those might be.

We almost never hit technical limits in the renderer, streaming systems, etc. Instead, we found that pushing gameplay systems beyond the prototype stage would require more and more effort, as we'd encounter deep engine bugs, or the tooling simply did not cater to our use case. We ended up implementing more and more tooling outside the engine, and there comes a point where UE4 became a IO/Rendering system. We'd've bee…

Sorry, I think we're stuck in a loop.

> we found that pushing gameplay systems beyond the prototype stage would require more and more effort

I understand that you're saying that some systems exist that can't work. I'm trying to understand what those systems would look like, and how the user would see it as being different. Do you have an example of the system/mechanic that can't work?

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

#263

Post by jessermeyer » Thu, Dec 01, 2022, 1:13 AM UTC

nomel wrote: post #262

jessermeyer wrote: post #254

Earlier quoted context omitted.

We almost never hit technical limits in the renderer, streaming systems, etc. Instead, we found that pushing gameplay systems beyond the prototype stage would require more and more effort, as we'd encounter deep engine bugs, or the tooling simply did not cater to our use case. We ended up implementing more and more tooling outside the engine, and there comes a point where UE4 became a IO/Rendering system. We'd've bee…

Sorry, I think we're stuck in a loop. > we found that pushing gameplay systems beyond the prototype stage would require more and more effort I understand that you're saying that some systems exist that can't work. I'm trying to understand what those systems would look like, and how the user would see it as being different. Do you have an example of the system/mechanic that can't work?

Not at a high level that is easy to express in a HN post, sorry. It's one of those "the devil is in the details and there are a lot of details".

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

#264

Post by curtainsforus » Thu, Dec 01, 2022, 11:12 PM UTC

ok123456 wrote: post #93

hbn wrote: post #24

Earlier quoted context omitted.

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

Unless it's being designed from committee from the start, most languages start off as a 'passion project.' But, there is a point where they have to bring in more people to handle the work and mitigate the single point of failure.

I think he bought in more people at one point, then sent them away again when he realized he wasn't able to keep the project on track with that many chefs making the soup. The problem with more people is that the project can very easily degenerate into design by committee.