sheenobu

Location: Seattle, WA

Remote: Preferred!

Willing to relocate: No

Technologies: Python (sync and async, Django and non-django), C, Java, Typescript, some C++, past in Rails. AWS, Docker, Pulumi, Linux, a little GCP.

Résumé/CV: 10 years doing tech, past six in SRE roles (one FAANG, one startup). Lots of scalability and automation work in these roles, working with SWEs. GitHub is sheenobu.

Email: [email protected]

A continuation is a function that, when called, jumps back to a specific part of the program that was frozen (meaning current memory, the call stack, the line number). So it can't really be stored. If your game state was stored in a db, you'd still have to load it memory to perform operations on it. Those operations, if using continuations, would then stick around in memory while waiting the continuation to be resumed. If it's a multi-player game, then you'd be in real trouble as your continuation could end up with stale data.

Game state has to be propagated from the server to the client so the player knows what is happening where-as continuations as used in this article are more about avoiding this propagation (the hidden field in the example is replaced by dispatch-table tag which acts as a session id / location in the dispatch-table for finding the continuation function)

If someone builds a container that is designed like this:

  FROM debian

  RUN do-x
  RUN install python2

and then someone changes do-x, if I understand, the layers below it get invalidated and all of a sudden install python2 fails. This is very bad design but very easy to replicate.

NDISwrapper was more like wine, it implements APIs but doesn't run any sort of virtual CPU.

Thank you for the sympathy. If we are talking about the same product then it was most likely backed by 3 different storage services over its lifespan, 2013/2014 was a third party product that had some replication/fail-over baked in, 2016-2019 on my team with no failover plans due to "deprecated, dont bother putting anything important here", then 2019 onward with "fully replicated and automatic failover capable and also less cost-per-GB to replicate but less flexible for the existing use cases".

I think I know specifically what you are talking about. The actual files an engineer could upload to populate their folder was not multi-region for a long time. The servers were, because they were stateless and that was easy to multi-region, but the actual data wasn't until we replaced the storage service.

Have you switched to pipewire? I haven't pulled the trigger yet so I'm wondering if bluetooth gets any better.

With this hindsight, any predictions for the future? 30 years from now?

I thought of Nix while reading this thread and I'm wondering what makes it unique here? As a daily NixOS user I get that it is better but I don't know the specifics. the nixpkgs rpeo is superficially similar to homebrew (lots of people submitting packages, running on github, automation around commits).

What are the differences wrt to security?

1. It's language, Nix, is limited in scope?

2. No automated PR merge workflows (yet)?

3. Better community/engineering/security?

The glib answer is that these kinds of things are cyclical.

But C++ coroutines don't seem too incompatible with the level of OOP you already get in C++, no?

Running a JVM application in a container is not all that different to running a Go application in a container. But the design of the JVM runtime and its tooling is vastly different than Go. The JVM is more complex but it can do more things. Go is simpler and can get you to a working product quicker.

If someone asks me to build something and they tell me it will run in docker/kubernetes, have the standard containerized CI pipelines, and communicate with other services over some standard protocol like HTTP; doing it on the JVM is doable and probably easier than ever but I would just think about all the cool JVM features I wouldn't get to use (hot code deploy, runtime modularity tools, all the neat bytecode hacks, even spring which everyone but me seems to hate).

If I don't get to use those features then I would rather grab a language like Go, since it doesn't front load so many runtime complexities. (and if this was 10-15 years ago maybe I'd say "Go doesn't front load so many complexities AND performance penalties")

Go can do encapsulation and polymorphism. Go doesn't do inheritance, of course. Channels can also help simulate message passing and actor-style code. What's missing?

IMO, If you compare Go to an OOP language that runs in a VM there are some things that will fall short but the industry has worked around it. It's not cool to have a beefy Smalltalk or Java VM, with the dynamic runtimes that let you auto-export objects as remote endpoints... you have small binaries exporting HTTP or RPC services running in containers and interfacing with service discovery and fabric systems. The "object orientation" is now at an abstraction sitting above the running binary.