Just wanted to say thanks for building it, and keep up the great work!

And then some more general questions - Can I hook a CI into the deploy loop? (Maybe that doesn't quite make sense given the model is something like Jupyter notebook meets Glitch.) Also, is there a repo being managed behind the scenes like GitHub does in Gist, and if so, any plans to open access to those?

A bit of context: for every language/environment we have a Dockerfile (naturally) and a JSON configuration that describe how it runs, how it install packages, how it runs unit tests, how it formats code, etc. When we build the container we insert a program that we call pid1, it's the container's interface to the rest of the world.

The container manager creates pools of these containers with some rudimentary predictive logic to make sure we have enough containers to deliver on our promise of "loads in 2 seconds". When we take a container out of the pool, if we're reviving a container, we mount a GCS-backed fuse filesystem with the user code (it needs to be backed by GCS to handle persistence, say you're writing to a log file, it should be there next time you load your project). We then send the relevant setup command to pid1 (either init, or wakeup) which sets up the repl to start the user app, the repl, or what have you.

> What actually happens behind the scenes to make a deploy go live

We poll the container for published ports and the moment we see an open port we add a record to an etcd which stores the routing state. We then send a command to the client that we published a port, which will react by opening an iframe. Then the iframe or any request to the published url will hit our outer reverse proxy which will query etcd to find the container and if the container is alive we will send the traffic to the relevant container manager which has another reverse proxy which sends the traffic to the container.

If the container however is dead (from idling or because of an error) we revive via picking a container out of one the pools and going through the initialization phase described above.

Finally, we also host our own docker image registery so that we can push new images, whether new languages, new versions or what have you.

There is a lot more to talk about here so I or someone on the team will write a post soon.

    0. No docs. There's plenty of odd and unexplained behavior that needs documenting - at least until stuff is less broken.
    1. Can't eval single forms from editor. Whole files only.
    2. Can't eval anything from files other than main.
    3. Lots of delays and hangs. Very slow. Every eval takes multiple seconds. Some repl starts take 30 seconds.
    4. Weird inconsistent behavior. Sometimes it will render function return values from editor eval to the repl, sometimes not.
    5. Once you drop a new file, stuff breaks in strange ways. E.g. main.clj no longer seems connected to the user namespace.
    6. Can't load other files, (load "other.clj") doesn't find it.

To address your points but please feel free to add this to our feedback board too.

>0. No docs. There's plenty of odd and unexplained behavior that needs documenting - at least until stuff is less broken.

This is definitely an area we need to fix but to your other comment there shouldn't be any unexplained behavior. If there is it's a bug. Please report it here: https://repl.it/bugs

>1. Can't eval single forms from editor. Whole files only.

Meaning you want to highlight code and eval it? That's something we've seen requested before and would love to implement.

> 2. Can't eval anything from files other than main.

Yes so if you start adding files we switch to executing code via `lein exec main.clj`. We should probably drop the REPL in the same namespace as well. Do you know if there is an easy way to connect the REPL to a running program?

> 3. Lots of delays and hangs. Very slow. Every eval takes multiple seconds. Some repl starts take 30 seconds.

should be fixed now.

>4. Weird inconsistent behavior. Sometimes it will render function return values from editor eval to the repl, sometimes not.

This should be consistent. It's the first time we hear about this, can you please report it with some repro steps?

> 5. Once you drop a new file, stuff breaks in strange ways. E.g. main.clj no longer seems connected to the user namespace.

Related to point #2

> 6. Can't load other files, (load "other.clj") doesn't find it.

It works, you shouldn't add the extension in `load`. See working example: https://repl.it/@amasad/Load-example

Is this an avenue you're at all perusing / interested in -- or else, do you have any sense of how other business could rely on your product?

I noticed two small issues. First, if you enable gzip on static assets, it will help images load faster. Second, Mason's picture is 2MB, bigger than everything else combined!

In particular, it would be great update a function or class select it and press a button to run the updated version in the REPL so that you wouldn't have to copy and paste it there manually.

Additionally, and perhaps counter-intuitively the server-side solution was better for folks in areas with bad internet and computers. Downloading 10mb of JavaScript is a lot for some people and sometimes their computers would run out of memory parsing the JS.

Is a Typescript option in the pipeline? It's my favorite :)

This would make Repl.it a fantastic product for API example code testing.