Your impression resonates with me I think anyone serious about making a language has to understand and respect what other language designers did. But on the other hand being opinionated helps since basically everything you decide for a language is an opinion you force onto other. So forming opinions and being informed of opinions are required skills for the job.

I'm a regular on his streams for years now and somewhat disagree. If he wants to, he can be nuanced and say his opinion in a way that is very hard to fault, but most of the time, he doesn't want to. And the outcomes of that make me sad sometimes. If someone comes to the stream, asks a random question, and gets absolutely trashed for it, that's not good. He can be mean.

@@simivb Certainly, he's no Carl Sagan. But in the Witness, he featured James Burke and other decent science communicators (like astronauts) and I think it illustrates that he may want to be approachable, but just have limited capacity/patience to practice it. I'm giving him the benefit of doubt, but it's certainly a shame, given Jai has a lot a potential - at this point I expect it to be in closed beta until some entity creates a superior publicly available one.

I've listened to a lot of JBlow's stuff, and yes, he does respect Rust. In some of his earliest lectures on what he wants from a programming language (now Jai) he mentions it several times. He likes that it is trying to have a strong and unique opinion about how programming could, or should, work. A lot of modern languages are just syntactical sugar or supersets of pre-existing languages, with very few, if any, truly innovative ideas. He respects that Rust is doing something different. As for opinions, well he can definitely be mean/abrasive when he's in a bad mood lol. He often parrots a gate-keeping mentality and in my opinion, it doesn't do him any favors. I think its a bit of a shame because he is an absolutely brilliant mind, and I can highly recommend watching any of his talks if you're into game design/development.

Where can I watch/listen to these? :o This sounds really interesting!

@@gameofpj3286 here on KZfaq, I can't link directly

The invisible reply is probably someone linking them

Get Kasey and Jonathan on here at the same time!

I can't find the interview with No Boilerplate. Can you point me in the right direction?

the blender is made that way nowadays. ig even freecad too.

Can confirm. There was a thing I wanted to write in C, let's pretend it's a Sudoku generator (it's not too far from being concretely true). I had various strategies that partially worked, some of the time, but frequently enough I would generate a puzzle my solver couldn't solve. I used python to prototype various ideas. Failure-and-retry probabilities served as a good enough predictor of performance. Once I got an algorithm I was okay with, I implemented it in C and it worked as expected. Note that the output as a function of input is probably the same in C vs. python, but the performance is not. So be careful about extrapolating; Think about when the prototype is and isn't a good predictor of the characteristics of the production implementation. When is a python prototype the right approach? Intuition says: the longer the exploratory process is, and the more faster you can try ideas out in the prototype language compared to production, and the less time it takes to rewrite. Let's math it out. Say the time cost of implementing x features in language 1 is a_1*x + b_1 and in language 2 it's a_2*x + b_2, the cost of rewriting the final version is r and you need to implement at least t features before your prototype is done and you can begin rewriting. Then the cost of writing in language 1 is a_1*t + b_1; the cost of prototyping first is a_2*t + (b_2 + r). For prototyping to win, you want a_2*t + b_2 + r < a_1*t + b_1, which is equivalent to b_2 + r - b_1 < (a_1 - a_2)*t. This agrees with intuition: the numbers which favor prototyping are greater t (more exploratory process), greater a_1 - a_2 (development time: python beats Scala beats C++), lower rewriting and differential fixed costs. Of course, you can never observe the numbers and so you never know. You can do both, interleaved, and "only" spend twice as much time as the fastest approach. Or you can make a judgement call based on experience.

If you're doing something small or just starting out a project, sure, but if you want to prototype/explore something inside a 1 million line C++ codebase you can't really whip out the python.

@@alexvitkov I generally agree-although one should consider defining some interface around the place where you want to introduce new behavior, which only takes plain data in and gives plain data out. Then you can prototype a python thing which does the right input/output mapping of the data, then rewrite it in your production language once you have the right implementation strategy. This becomes harder if you want to prototype something which reads and/or updates the system state. It's doable: send over all the data you could ever want to read; return a list of descriptions of things to update. Probably requires a lot of elbow grease and the amount of transferred data may be too large to be practical. But sometimes this can work, and hey this technique might be one that works.

Python allowed me to understand and learn more complex concepts a lot faster and easier. I then find out what the equivalent of those are in c++ and understand them a lot better.

Another way of saying the same thing: when a Java developer talks about an object, they're not talking about a thing whose (narrowest) type is `java.lang.Object`, but rather... any instance of any class. Entity is similarly general, although along a slightly different axis: it's any obj... uh... _thing_ which exists in the game world. A player, a monster, a tree, a wall, a vehicle, whatever.

Entities is another word for an object, but like an object in the real world like a cup or something. Its a thing that can Normally be interacted with someway in the game world. Its really really annoying that programmers steal random words for random shit. Wish we could just use the word object, but that means a bunch of very different things now.

the scope of the generality is misunderstood by people - the monster is an entity, the tile the monster is in is also an entity, one is in a queue, the other in an array .. an entity is much more general that "object"@@jonaskoelker

I think it's the difference between ``` -- init Object with data object = {position=V3(1,2,3), health=42, maxHealth=50, active=true} allObjects[#allObjects+1] = object -- later for _, o in allObjects do if o.active then o.Health = o.maxHealth end end ``` and ``` -- init entity data n = entityCount positions[n] = V3(1,2,3) healths[n] = 42 maxHealths[n] = 50 activeEntities[#activeEntities+1] = n entityCount += 1 -- later for _, eid in activeEntities do healths[eid] = maxHealths[eid] end ``` this allows a direct index to get or set specific-property data by id (number) rather than (object.property) consider the difference: given N objects with M properties each, there will be N * M + N different data-containing-structures. whereas given N entities with M properties, there will be M different data-containing structures. In my experience (significant amount) this is meaningful to bottom-line (what can happen in a frame) when doing simple operations on ~million things 60 times a second. It becomes more important when there are interactions between entities that can be compressed down to operations on data.

tldr; object and entity are different concepts: objects have more wrapping paper, entities have large wrapping papers that each cover a lot at once

I guess you didn't watch the full video

I would blow Blow

​@@shinjite06🫡

unfortunately...

Ama simpler man, I see BlowJo - I watch.

gaaaaaeeeee

Joe Blow blowing Joe's bros

simplest man; i just watch.

Right???

@@rytif 1. I don't care how long it takes to compile. I've shipped projects with a thousand dependencies and it compiled in about 40-50 seconds.The compile times are slow but not so slow that you can't work. I care about the runtime. 2. Iteration is terrible, if you don't know the language well or you are a bad programmer.

Oh, it's that 2020 interview. Meh :/

oh nice, do you have it open sourced? also maybe some blog post?

I'll probably open source it when I have the basic features completed. No blog post yet, but take a look at the series that I mentioned above. Main difference is that I want a more static approach, instead of archetypes that are defined at runtime they are fixed. This prevents implicit copying things around if components are added/removed (you would have to do that manually by defining all variants or choosing another representation), which I think fits better with Zigs explicit nature. Especially many short-lived components for e.g. for debuffs can otherwise quickly lead to performance problems. Other than that you could take a look at Flecs (C, there is a binding for Zig called zflecs) or the ECS from Bevy (Rust).

That part is actually similar to Java properties, except in jai it's done at compile time instead of runtime

@@notuxnobux "It's done at compile time instead of runtime" Which makes it quite a bit less interesting. I mean you could do the same thing even with C macros

Technically I belive it is. I may be wrong but you can compile without doing borrow checking.

Bad idea. You'll likely end up with a pile of garbage rather than a beautifully refactored chunk of code. It's definitely not fun to suddenly get a hundred errors from a compiler and spend an hour or two fixing those. Even if you end up with something decent, the tedious and non-creative process of this kind of refactoring would eventually wear you out, you'll ditch the borrow checker and just stop caring about correctness that much. Not to mention the disappointment when your beautiful experimental code simply cannot be refactored to satisfy the borrow checker, because of some subtle but fundamental flaw in the algorithm. Optional correctness never works. Just look at C and C++. You can absolutely write perfectly safe code in these, just gotta follow all the million rules in the standards. They've got valgrind, various sanitizers, static analyzers and whatnot... it all doesn't matter much, 95% of that code is still crap, because all these tools are optional.

We need more BlowJobs indeed.

You know what I need more? Blow J

Odin rocks

I will believe it when i can actually use it

@@rytif Or... maybe let people choose if they need it or not. What's the issue with people wanting to use ECS getting suggestions that bothers you so much?

Thanks for the reading suggestion

If anyone agrees to you, why even speak, right?

if i punch everyone i see... i too must be right.

he's certainly right about some stuff. but i doubt thats why anyone has issue with the things he says.

Precisely. In fact, you can do exactly what John Blow describes with an arena allocator crate (and I have seen it down in compilers for pass-local structures). All data allocated into the arena would get references with the lifetime bound to the arena, and if "the noob intern" ended up shoving one of them into a long-lived data structure, you'd get an instant type error. There are, however, a few more complexities that make this a bit tricky in practice (and why entity indices may be the superior approach). One is, for example, it may require some tricky management of the mutability access on these pointers: say allocating in the Arena gives you back a &mut T, then there is no easy way to go down into a &T and then back up to a &mut T safely. With an index, the problem is "punted" down to the access on the container, not on the pointer itself (as pointer = container[index]) Finally, the obvious way for doing this requires the "game" to be written in a way that controls the main loop. If you are making your game in something like "standard bevy", you don't have control over that loop, hence no control over the per-frame scoping. So, I think, ultimately, entity indices are the way to go. Insisting on entity pointers makes sense once you are in something like C++ (though I disagree on this as well...). This is fine, but it leads to the non-surprising conclusion that "I wouldn't use Rust for this C++-style solution"

haven't touched c# in 12 years

You can make ECS as simple as you want: a World struct with a bunch of Vecs for each entity type and you're *nearly* there.

He didn’t make that clip. It was clear mockery.

Was the part where he's against a window in a dark room like a CIA informant saying how they misunderstood his art filmed without his knowledge lol?

That wasn't made by him. It was an indie games documentary

this is why i am really loving ocaml

Smartpointers are for languages without a garbage collector. If you're a web dev, you most likely always use GC. The most used ones allow the code to hold multiple references to the same piece of data while not leaking memory (or doing the memory management manually). Others make sure that there's only a single reference. Some might do other stuff like closing a network connection when a piece of data isn't used any more.

If you use Box or Arc, you're already using smart pointers. They're not that fancy.

What chip has those specs? The weakest mcu I've used is the cortex m0

OK man hear me out, Clojure is fine... But have you tried CL?

@@freesoftwareextremist8119 Yes. Great Language, but JVM has a great ecosystem for modern applications, so the ability to leverage that while maintaining some measure of lispiness is quite nice.

XSV?

no... because comptime produces types and types can be used.

Calling functions at comptime is the same as const fn, yes. The cool thing is that all* function are `const fn`s! (*: with some exceptions like doing networking/file IO and such)

Sort of... My understanding of Zig's *comptime* is that it's largely akin to both *const fn* and *const { }* blocks (not available on stable Rust yet). The scope of *comptime* is a bit broader, though, as it also includes type-level expressions, which would probably fall under const-generic expressions inside *where* clauses in Rust (also not available on stable yet). I'd say that *comptime* is probably closer to C++'s *constexpr* and templates, in most respects, as its compile-time "well-formedness" and correctness guarantees are much looser than Rust's equivalent (so *comptime* errors can be pretty gross, compared to Rust errors, when things go wrong), but the feature is somewhat more flexible as a result. Disclaimer: I'm primarily a Rust developer with a passing interest in Zig on the side, so feel free to correct me if I'm wrong, folks.