ORMs are so incredibly finicky. I still remember using old Linq-to-SQL (not Entity Framework) and I had to write the linq query in the reverse order of what I expected or it created 3 nested subqueries instead of just joining the tables together. That was when I learned to instantly double check every ORM query I wrote.
> Linq-to-SQL (not Entity Framework) and I had to write the linq query in the reverse order
I remember those times! Had to write the LINQ, see what it compiled to, redo, until the query was efficient. Abuse LINQ subtleties in how it generated JOIN predicates since it only supported equality. Something about finding an equivalent way of expressing a query with sub-selects that is also computationally equivalent. All so I can get my efficient SQL without writing SQL. So silly.
Sadly the era of government that split up studios and theaters is long gone. Hollywood is built on a different time between things like this and its flavor of unions that cover the biggest players in the industry.
Closest thing we have to a Hollywood today is games, but game makers can also make consoles and industry wide unions would never happen. Is there some unionization in games? Yeah, but I haven't heard of any single one that cover a significant number of different studios
I'd say check out Crafting Interpreters [1]. It has 2 parts, the first in Java for doing a treewalk Interpreter in Java before going farther with a version written in C.
Not GP, but after doing Crafting Interpreters I was kinda left with a gap in my knowledge regarding the conversion of an AST into native code. Also kinda missing was optimization passes over an AST. I somewhat understand the idea, but it would definitely be nice to have a more guided book/article for this.
Crafting Interpreters is definitely a recommended read, but it stops at Interpreters (fair enough, the book is thick enough). Crafting Compilers would need at least 4-5 extra chapters IMO.
Most of the work involved in emitting code deals with somewhat arbitrary hardware details. Pretty much the only way is to get familiar with your target hardware features, instructions, and platform ABIs. ISA manuals all have sections describing these, they're pretty much always very dry and "linguistically rigorous" so it's not easy to read but everything you need is there. Actually emitting instructions is pretty boring and mechanical outside of some considerations and subtleties with hardware-specific optimization, OS calling conventions, register selection, etc.
Not really. Lore is for gamedev at companies and so not a distributed VCS. Using it for an open source project if you allow outside PRs makes no sense.
Stripe did such a good job with this book (and the others I bought that they published). Each one feels like an artifact I can show off on top of having interesting information inside.
So you're assuming game devs write every line of code in their server infrastructure. First, could be using a third party library you have license to use on a limited number of machines that make up your backend servers. Second you could be paying for third party API access to something like snowflake.
You either have to rip out the code (which may or may not break the server, but still requires developer time to do) or write replacement code which likely takes even more dev time to do or you would have done it instead of paying for the library/access to the service.
Of the 7 AAA games I’ve been part of making, not a single one used HTTP (well, not as a primary driver of anything), HTML, CSS or anything that could be construed as a “web technology” so, what are you talking about please?
What I'm saying is you have programs running on user machines, and programs running on your machines. There's an interface between those two over a network. There's a problem that consumers face today where they pay to play games that are not functional without data flowing over that interface.
There's a claim that implementing the backend side of that interface is so complex and impossible or too difficult/time consuming/etc to design in a way without 3rd party dependencies.
I'm asking: what are those 3rd party libraries doing? And why can't you design server APIs and client code in a way to provide a different backend if consumers need to do it themselves when you stop supporting the game?
I'm not interested in hypotheticals. In AAA games that you have worked on, concretely what 3rd party code did your servers rely on that would prevent you from distributing either the server itself or sufficient description of the servers' behavior to allow a reimplementation?
And even if we're talking hypotheticals: stupid example. I haven't worked on a backend where the actual server infrastructure wasn't open source, trivial to open source because it was first party, or irrelevant because the only thing that matters would be the API and protocols, which again, trivial to make open.
I'm actively trying to remove my own ignorance of the domain which is why I posed the question! You're not breaking confidentiality by saying "I need X to solve Y problem which is offered by Z and we can't expose even the application layer interfaces." Right now it sounds like you don't have an answer, or even understand the question.
Getting all defensive and not answering it doesn't really help your industry's case here.
Web servers, message brokers, physics engines, anti cheat, fraud detection, flood mitigation, ranking systems, chat moderation, match making systems. There are thousands of possible components which may have been licensed in any given game server system. In some cases the entire game engine runs on the server.
I guess what surprises me here is how much of this is 3p code that couldn't possibly be distributed. Like why would you not be using an open source web server, or widely available message broker? Things like chat moderation/match making/anti cheat/etc seem like add on services that would be implemented per game (well, maybe not match making) and aren't relevant to the problem that the "stop killing games" people are trying to solve.
Frankly it's none of your business why, and it's completely irrelevant. The fact is that this 3p code exists and this law needs to account for it or it's unworkable.
This is kind of needless aggression that doesn't help non domain experts understand.
I've worked on a lot of complicated and deeply optimized networked applications. They're almost all closed source. I know exactly how I would design a system to support these kinds of initiatives. What I'm curious about is why that's impossible for game developers, because either I'm missing something, or game developers are just bad at software design.
The "server" being the computer program not running on a user device. The intent of the initiative is to allow people to substitute or replace that program to allow the game to continue to function even if the original publisher/developer disables access to it.
It's pretty obvious to me as a gamer and engineer what the intent and design constraints are here, so I'm just wondering what makes this seem impossible?
Elevator pitch for the language itself or a library/library ecosystem that lets you do things better than in other languages. Ruby originally blew up because Rails was a way people enjoyed writing backend code, despite the speed issues. But the problem is other languages got good enough at writing back ends Ruby was no longer special there and didn't have anything else to back it up the way Python has such strong control of the ML library ecosystem.
It is interesting seeing more and more GCed ecosystems become aggressive about allowing code to stack allocate more. Watching dotnet go through it since I think Core 2.1, or whenever they introduced Span<T>, Memory<T>, etc to get significant performance gains has been nice to track.
GCed languages do not have to be slow if you keep the garbage to only where it is necessary (or where you can allocate once and never collect).
This was pretty common in the 1980's-90's, for some strange reason, maybe due to Java and scripting languages, there is this mentality that having a GC means no stack allocations.
Lisp Machines dialects (Genera, TI, Xerox) had primitives for stack allocation.
Them we had Cedar, CLU, Oberon and all its descendants, Modula-2+, Modula-3, Eiffel, Sather, and probably others during the last century.
Ironically the final design for Valhala in Java seems to be quite close to Eiffel already had in 1986.
The version I've always heard is just well designed but less popular languages, but the ones I can think of were all functional (Haskell/F#/OCaml/Clojure/Elm/Erlang)
MSIL was designed to support plenty of languages, including C and C++, which WebAssembly advocates tend to never mention.
As such there are plenty of MSIL and CLR capabilities not yet fully exposed in C#.
One of the improvements in C# during the last decade, has been exposing low level coding abilities into C#, which is nothing more than taking advantage of those primitives originally designed for C and C++ support.
Likewise, .NET also had support back in 2001 for FP languages, thus TCO.
