DDSDev

DOTS stands for “Data-Oriented Technology Stack”, which is a collection of Unity technology to include their Entity Component System framework, the Burst Compiler, and their Job system.

Each of these technologies have their own descriptions, but a very quick (and perhaps over simplified) explanation:

ECS is a framework where you have entities that themselves have one or more components, acted on by systems. The way these components are laid out in memory and acted upon by systems is typically more cache friendly then traditional game engine design with heap allocated GameObjects that are themselves a mess of pointers (Structs of Arrays vs Arrays of Structs)

Burst allows you to annotate functions, jobs and systems written in a subset of unmanaged C# that compiles to highly optimized instructions for better performance.

The job system allows you to schedule jobs with dependencies in a useful way that can help enable parallelism without manually having to deal with thread primitives. The jobs can also be burst’s themselves and used in a non-parallel manner if you don’t have something easily parallelizable.

To my knowledge, China is a signatory to UNCLOS, but has disputes around it's "islands" in the South China Sea and their relation to the EEZ. I acknowledge that China's relationship to UNCLOS, as a minimum, is complicated and rapidly evolving, but I dispute that they do not have a right to transit passage. Or to be more specific, I would put forward that they would have a plausible argument to claim transit passage.

The United States has not ratified UNCLOS, and regularly claims the right of Transit Passage. In fact, this fact is one of the reasons why Iran claims that the United States cannot enter into Iranian TTW while making a Strait of Hormuz transit - because the US has not ratified UNCLOS, their claim is that the US cannot claim transit passage. For the United States (or any Western Nation) to make the claim that China cannot claim Transit Passage would lend weight to Iran's argument, which you can imagine, they would not want to do.

I do not want to make any assumptions around your specific views on this matter - you may hold the opinion that China could not claim transit passage, however I wanted to interject some perspective that:

1. That may not be universally agreed upon 2. Specifically, the United States and it's allies may not make that argument because it would put them in a negative position for other international disputes.

While what you are saying is technically true, Chinese ships would be allowed to exercise their right of Transit Passage under UNCLOS through the Strait of Gibraltar.

I am the main author behind the JS/TS integration for emacs-ng. I still think it is one of the cooler things I have done that people have taken note of.

I am a game programmer by trade, and I had experiencing embedding JS into projects from a previous engine I worked on where JS was the primary gaming scripting layer.

I love emacs and I love lisp in general - I added JS to emacs mainly to find out if I could do it. I also had a hope that adding JS could expand emacs usage to people that don't know elisp, and have JS be a "gateway" into elisp.

I think that the JS integration is a huge testament to the flexibility and quality of emacs and elisp.

As I have gotten older, I've had less and less time for open source, but I don't consider this project abandoned. I still want to upgrade us to the latest deno. My previous upgrade attempt (which you can see in draft PR at the time of this comment) was a little too ambitious - I tried to move us to a more multithreaded approach, but I think I need to work on this more incrementally.

As a game dev, factorio has always been a title that I would absolutely love to see the original source code for.

Also, for anyone who’s first question was “how is this legal”:

“When asked about the legality of this whole endeavour, they showed great understanding and allowed the project to be released, provided it won’t be used for commercial purposes.”

For anyone curious, Smedley Butler died in 1940[1]

[1] https://en.wikipedia.org/wiki/Smedley_Butler

It was an emacs fork that used TypeScript/Javascript alongside elisp. I am currently in the process of upgrading to deno 1.30.3 right now.

I apricate the time that the deno team has spent having a separation between deno/deno_core/deno_runtime. The deno codebase is well organized and overall high quality.

One issue I've run into as someone who has embedded these libraries into another other project is that there are a lot of really nice features are only available in deno proper (everything under their cli/ directory https://github.com/denoland/deno/tree/main/cli) vice deno_runtime and deno_core. Specifically, typescript is implemented in cli/

A user of runtime or core could just reimplement those features piece meal, however I ended up just forking deno and adding a lib.rs that just exposes the code in cli/ as a library, and it has worked out pretty well for my needs.

Edit: Elsewhere in the thread the author of this blogpost linked another blog post where they describe getting TS without having to use cli - something I will look into!

This is a really cool project!

One thought that I have: would there be an issue sending this file in an unsecure context where MITM is a possibility? Alice sends Bob her HTML file over an unsecured medium, and Jane intercepts this traffic, and gives Bob a modified HTML file that will report the password back to Jane. Jane can set it up so that the browser still displays the local file as it's source, but has an HTTP request in the background phone home back to Jane's server.

My scenario only works if Bob doesn't inspect the page source before entering their password, or if the modifications are sufficiently obfuscated.

What are your feelings on the direction of game engines across the industry right now?

What is an innovation you hope you see wider adoption of in the space?

Thank you for your efforts!

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility.

I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabilities.

In general I think this is an interesting idea, but I feel like this has a lot of overlap with asm.js and WebAssembly.

With this standard we would have standard dynamic JavaScript as the world knows it today, a restricted subset ('constraint spec') that is still designed for human readability/writability, and then asm.js/WebAssembly, which would not be written directly but instead would be an output of code written in other languages. Programmers will want interoperability between all of these paths, and that is a lot of complexity for these engines to manage.

The article is centered around a quote from Matz, Ruby's creator:

> "Ruby 3 will be three times faster compared to Ruby 2."

The context is that he was rereferring to release day Ruby 2.0 vs Ruby 3, not current Ruby 2.4 vs Ruby 3.

I think the lesson is that managing user's expectations is critical to major releases like this. Even if you are well intentioned, it's very easy for a promise to be misunderstood, and once it's out there, its out there. It's very difficult to put the genie back in the bottle without giving the impression the project is having issues.

> "How did things get this bad?" What are you talking about? It's a great time to be a C++ programmer!

I think like most things C++, the modern solutions are great, but a large number of programmers are still stuck with legacy systems that they cannot or will not change for a variety of reasons.

I don't think there is a magic bullet for people experiencing these problems in legacy codebases - it's either update to a more modern build system and use libraries within that ecosystem, or learn how to work around the potential issues outlined in the original article.

> DRY is about avoiding a specific problem, not an end goal unto itself.

To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense. The former leads to elegant abstraction, while the latter just leads to functions with signatures like my_function(data, BITFIELD, opt1=false, opt2=true, opt3=false, BITFIELD);

I think this is a good counter point, which is why I made a version of emacs fully scriptable from javascript and typescript [0]

[0] https://github.com/emacs-ng/emacs-ng Disclosure I've posted about this on HN in the past, but I felt it was very relevant to the parent comment.

Learning the concepts and ideas behind lisp really expanded my horizons as a programmer. For me, that all started with emacs. Though elisp isn't very fast and has some pain points, emacs as a whole gave me an extremely established customizable code base that I could play around and learn in.

Though it's cliché and often listed as a negative, emacs really gives the user more than just a program to edit text.

I think that elisp is one of the many a strengths of Emacs, along with it's strong extensibility, customization, and general user freedom. I think language choice is a smaller part of the pie compared to Microsoft's backing, networking effects within companies, and visual appeal and design.

However, I do agree with you that Emacs onboarding process can be difficult if you don't know lisp, in that you have to now learn a new language and the API for interacting with the editor. That is why some friends and I recently decided to embed JavaScript/TypeScript into Emacs as a means of controlling the editor [1]. We will see if we can prove you right.

[1] https://github.com/emacs-ng/emacs-ng

Author here - The background of 'emacs-ng' is to add new features to emacs utilizing different tools and techniques, including Rust. This update integrates the Deno runtime, allowing us to run javascript and leverage async I/O within emacs.

While I love elisp, I understand it's not for everyone, so I thought this would allow people to customize the editor with a language they are a little more familiar with. Future plans include integrating Typescript.

While not ideal, one tool for this situation is "cargo expand". It will expand your macros so that you can examine what code is being generated, and hunt down what might be happening.

This page[1] gives a explanation of flexible array members. They were introduced in C99.

[1] https://en.wikipedia.org/wiki/Flexible_array_member

I have run into issues with bitfields, and flexible array members.

In response to the general critiques of "Why rewrite emacs at all!?", I believe there are hidden benefits to an incremental rewrite to Rust executed this way.

First is that remacs has been able to reduce the amount of non-Elisp code in the editor needed to implement a number of different features. It was able to do this by replacing hand rolled C functionality with high quality crates from cargo, or code in the standard library. I'd attribute this to how easy the cargo system makes implementing libraries into your project.

Second is I believe that this project overall is increasing knowledge share of not just Rust, but also mainline emacs. I personally was intimidated by looking into contributing to mainline emacs. The remacs community was so friendly and welcoming I felt very encouraged to jump in and start working on things, and now I not only have better knowledge of Rust, but a pretty decent knowledge of the C layer in emacs and how it lays out and implements it's data structures etc.

Third is that the majority of the emacs codebase is written in emacs Lisp. Remacs aims to be fully Elisp compatible, and any differences are considered bugs and should be reported. This means that the project is still able to keep up feature and bug parity with the mainline, while incrementally rewriting the core of the editor.

Disclosure: I am a contributor to this project