We do indeed offer free HTTPS and custom domain support (as well as the two together) on our free plan. I haven’t used GitLab Pages myself, so I couldn’t compare further off the top of my head.
Your post seems to demonstrate _exactly_ what the post you're replying to is saying: most of the speed has to do with I/O strategy (buffering and syscall usage), not the actual speed of the involved language. Maybe I'm missing a distinction you're making, but I'm not following how your previous comment leads to what you're saying here.
The rust version that does exactly what python does (buffered output) is an order of magnitude faster (even if I force the rust buffer size to be 4KiB like with python2).
To head off this comment chain, I've softened the language in my original comment to "overwhelmed by" rather than implying that non-I/O factors are wholly irrelevant. :)
You can have that kind of flat, global structure without mutability. One way to do that would be to collect all actions done in each frame (instead of mutating) and then apply them all to create a new frame in a single step (a "reduce"). Then you call the game loop function with that frame to create another frame, etc. The issue isn't just global state, it's global and mutable state. Say that your game has a debuff that reduces the damage of an enemy, and your player debuffs an enemy in the same frame that it attacks him. If you're mutating everything, it can be very difficult to figure out or specify what order things like that happen in, since anything can mutate anything else at any time (concurrency makes this much worse). If you're using mutable state, there's no way to tell all the places that could be changing the enemy's damage, because it could be anywhere in the program. If you're passing everything through as arguments, it's very easy to see exactly where state changes occur and make code modifications in isolation without worrying about affecting unrelated behavior.
What you describe above is similar to what Carmack discussed at his QuakeCon keynote several years back when toying with a game engine on Haskell. Very interesting talk, https://www.youtube.com/watch?v=1PhArSujR_A
That's an interesting concept - I'm not sure I'm fully understanding though.
In your example - in the 'reduce' step - the implication is that the attack and debuff are handled in a deterministic way, regardless of their order? I feel like then that would require the logic for reducing all game commands needs to reside in the engine loop, which doesn't seem right to me.
Background. There are two ways gamers think about games "real-time" and turn-based. The question about a bullet is most likely referring to what gamers would call a "real-time" game. The thing is, we programmers are forced to make the game happen in discreet steps. There are multiple ways to accomplish this.
The naive way is to give every object in your game an Update() then on each discreet step you iterate through the list of objects in your game and call Update(). This way lies madness because every object can interact with every other object from any Update() and you can never know where the changes are coming from.
The concept above is that you move up a layer of abstraction and you create a GameState object that contains all objects. You instead give each object a GenerateUpdates() method that returns a list of GameStateChanges. Thus to update the game, you take the GameState, iterate through each of the objects in GameState and get a list of GameStateChanges. You then pass both to either GenerateNewGameState (if game states are cheap) or ApplyChangesToGameState (if they are expensive). This reduces all of your mutations to one method and is much easier to update/debug/fix/understand.
From what I understand, it is more that by collecting events that occur in a frame and then applying them on the next. It is easier to debug since you can print out the events on every frame. Which if there is a bug, makes it easier since you'll be able to see the events and the order they came in on.
Determinism is indeed a major benefit of the structure I described. I'm curious about your objection, though - where else could the logic be other than in the game loop? In this architecture, your game loop is basically three steps - collect actions, reduce actions, render, repeat.
> One way to do that would be to collect all actions done in each frame (instead of mutating) and then apply them all to create a new frame in a single step (a "reduce")
This is actually a reliable way to construct most programs; it can aid significantly with reasoning, debugging, and performance. I try to build software this way whenever I can.
Yeah, that's a strange piece of code, particularly since it introduces mutation (object[axis] = ...) and additional processing (reduce loop and inner function construction) that the naive example doesn't. It is slightly more generalizable to additional dimensions, but that seems awfully YAGNI to me. I suppose it prevents repetition of the Math.abs call and addition, but again that seems like massive overkill. I'd write it as follows, similar to yours:
TBH, this thread is pretty nitpicky, but I do agree with your assessment.
Yes and no.
On the one hand, the much more interesting parts here are the new APIs they've been using (and also IMHO the intelligent way they're handling compatibility and polyfills). All credit to the Stripe team both for making these tools work and for sharing what they've learned in the process for the benefit of others.
On the other hand, I think there is a real cultural problem in the JS community where newer is equated with better, and those defending that position will not infrequently appeal to authority by saying that Facebook or Stripe or Google or whoever does it so it must be a best practice. Grandpa here is getting awfully bored of young whippersnappers telling him code using new ES6 tricks is better (or, just as bad, that there's something wrong with clear, working code that does things in some older way). A gentle challenge to that assumption in a discussion about how these high profile organisations are using the new technologies doesn't seem either impolite or unjustified.
Emacs features vary wildly in support from language to language - in Go, for instance, it's very easy to get both those working, while in Java it requires something more complicated such as eclim. company-mode is by far the best completion frontend, but the quality of the completions is dependent on how good the backend is, which varies a lot.
We do indeed offer free HTTPS and custom domain support (as well as the two together) on our free plan. I haven’t used GitLab Pages myself, so I couldn’t compare further off the top of my head.