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

91–100 of 264 posts

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

#91

Post by throwaway894345 »

StevePerkins wrote: post #20
dymk wrote: post #8

I don’t understand how this language is planning on ever seeing adoption when it’s been restricted from open use since it’s inception. Seems like vaporware.

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 don’t think Go was ever especially over-hyped, and it has been pretty wildly successful in its “niche” (server side programming, CLI tools, daemons, etc). There was some controversy because someone said it was for “systems programming” by which the author seems to have meant “distributed/networked systems” rather than “operating systems” or whatever most people mean when they use the (very imprecise) term “systems programming”.

And to that extent, Go has been very successful (virtually the entire container ecosystem and a good chunk of the broader cloud ecosystem). It is doing a lot of stuff that would have previously been in Java or C# or Python or Node or Ruby (contrary to your “hardly anyone is actually using anything else…” remark).

Of course, older languages are naturally going to have more jobs because there’s an enormous volume of legacy code that can’t be cheaply translated to a new language, but so you have to look at the distribution of languages among new projects to be able to even begin making reasonable comparisons between languages, and even then a historically Java shop is probably going to give a ton of preference to Java, so here too we see a lot of weight given to older languages irrespective of their merit.

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

#92

Post by [deleted] »

jessermeyer wrote: post #76
nomel wrote: post #62

Earlier quoted context omitted.

Could you give an examples of a game that used a custom game engines that couldn’t achieve what they wanted in Unreal or Unity? Edit: The only style I would think would be infinite/strange geometry, like Manifold garden (great game!). But, it’s Unity.

I've worked on several. You haven't heard of them because none of them shipped due to issues with commercial engines (in particular Unreal Engine 4). They are very difficult to use if the game play semantics are complicated and require lots of interaction with world state or world geometry. If you're making a common FPS, they are great.

[deleted]

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

#93

Post by ok123456 »

hbn wrote: post #24
stephc_int13 wrote: post #17

I'd love to see more about Jai. 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…

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.

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

#94

Post by throwaway894345 »

thedracle wrote: post #71
StevePerkins wrote: post #20

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 always look for practical application. I think cutting through the hype-train is something every engineer learns with time, but some times there are diamonds to be picked out. At least for my own anecdotal experience, Rust has lived up to a lot of the hype for the time-critical low-level projects I was formerly performing with C/C++.

Agreed, though I’m sad it isn’t more often used. It’s certainly picking up steam, but it seems to have a ways to go before it’s going to be a serious contender for new projects in the embedded, video game, etc spaces where C/C++ still reign (by which I mean something like “before the majority of new projects are implemented in Rust”).

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

#95

Post by klodolph »

cyber_kinetist wrote: post #84
klodolph wrote: post #66

Earlier quoted context omitted.

> laughable. absolutely laughable. It’s really not laughable. I’ve made games with off-the-shelf engines and I’ve made games using just code and libraries. Sometimes not even libraries. The main concern here is that you have a limited amount of time to work on your game. Some people try to sidestep this concern by saying that they’ll “spend as much time as it takes” or something like that, but since these projects of…

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 entities however you want with Unity, even not modeling them as GameObject instances containing MonoBehaviour components,

- It is completely reasonable to develop an actual, real game this way, under realistic staff / expertise / schedule / budget constraints. (In fact, it is known that certain successful commercial games do this.)

Just to focus on a more specific example—let’s say you need your own physics engine. What’s an easy way to do that? Create your physics engine, and have it control the positions of Unity GameObject instances. This way you can easily set up test scenes in the Unity editor and see the results by hitting “play”.

Unity gives you this fantastic GUI for setting up these test scenes and a renderer you can use to visualize your physics engine behavior.

This is really not “abusing” the Unity engine in any way. The engine provides physics simulation, but it does not force you to use it.

Likewise—I’ve written games in Unity that do a lot of procedural generation, and I’ve written games without an off-the-shelf engine that do procedural generation. There are a lot of things that make it easier in Unity, and I’m not spending as much time fussing about with builds, or dealing with input, or figuring out how to port my game to other systems. Unity provides an API for me to create a mesh at run-time. During procedural generation, I generate the meshes for generated chunks of terrain, and the data structures look very similar to the way I would have written the data structures in my own engine.

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

#96

Post by shakow »

cleandreams wrote: post #52

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.

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.

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

#97

Post by dmitriid »

throwaway17_17 wrote: post #77
dmitriid wrote: post #2

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.

Tsoding, coding on Twitch and with archives on YouTube has a few streams from after he got into the beta. They give a decent overview of using the language in its current state, and I find Tsoding petty entertaining as well.

Thanks! I'll check them out!

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

#98

Post by henry_viii »

stephc_int13 wrote: post #17

I'd love to see more about Jai. 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…

I'm surprised the author didn't mention the Lobster programming language when evaluating a successor language:

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.

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

#99

Post by schemescape »

Xorlev wrote: post #18
gavinray wrote: 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…

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.

It wasn’t clear to me: is the debug info wrong or is it just missing because stuff is getting optimized out? Both?

I know in the past I had some difficulty in C++ on x64 because variables were getting optimized out (so depending on where you were in the function the variable literally didn’t exist anymore).

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

#100

Post by seabass »

stephc_int13 wrote: post #17

I'd love to see more about Jai. 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…

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

Post reply on HN