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.
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.”
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!
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.
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);
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.
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.
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.