Hacker News new | past | comments | ask | show | jobs | submit login

Hey HN, author and Repl.it cofounder here. It's been a long journey to get to what we're calling 1.0 and HN have been there on every step of the way. We started working on what became Repl.it back in school where we were tired of setting up the development environment on every machine we wanted to code on. It was at a time where everything was moving to the cloud and we thought that, naturally, coding would follow suit. We initially approached this problem naively and started hand-writing interpreters in JavaScript so we can run them in the browser but soon enough we've figured that it would take us years of work to get to something usable.

At the time, Emscripten -- the predecessor to ASM.js that compiles native code to JavaScript -- was coming on the scene so we tried using it to compile Python, Ruby, and Lua and more to JavaScript. Much to our surprise it actually worked and we became the first production app to use Emscripten. We launched on HN in 2011 (https://news.ycombinator.com/item?id=3056490) and the reception was nothing short of amazing. Programmers used Repl.it as a portable repl and a bunch of learn-to-code and MOOC companies used our open-source stuff to build interactive coding experiences in the browser.

Unfortunately soon after that, we got busy with work and life and the project lingered for almost 5 years. I went to work at Codecademy as the #1 employee (which at the time was using open-source parts of Repl.it) and then left for Facebook where I worked on JavaScript Infrastructure and React Native. Around 2016 Haya (cofounder and wife) and I were looking for a new side-project but then decided that since no-one really built our vision for what Repl.it could become we decided to give it another shot. As soon as we started improving it we started seeing growth, within a few months it got to a point where we were spending a considerable sum just keeping the service up. We didn't want to start a company but we were faced with the choice of either shutting down something that users obviously love or we quit our jobs and start a startup. We chose the latter.

One thing that's interesting about our small team is that we've built expertise in both the frontend (IDE) and the infrastructure (container management and remote development environment protocols). For the IDE, we recently shipped a big rewrite that allowed us to do server-side rendering (important since we're committed to speed) and a plugin architecture based on the ideas behind Redux with a very small core (https://repl.it/blog/ide). Everything in the IDE is a plugin, which is simply a reducer, a receiver, and a React component. The reducer builds up the state required for the plugin to work, the receiver dispatches actions in response to other actions flowing through the system, and the component renders. Even something as core to the IDE as the file tree is built as a plugin with no privileged hooks into the core. For the backend, we've designed a set of protocols and hooks for remote development. The protocol can expand capabilities as you require them. For example, every program starts out using the simple (loop (print (eval (read)))) protocol and then if you decide to use files/modules then it will switch to something that knows how to handle file manipulation and change events. The IDE can also react to what you require, for example, if you open a port then it will open a webview would pop open so you can see the result.

Last but not least, Repl.it has a growing community of aspiring programmers. Some of our hardcore fans are teenage programmers and so we've built a place for them to share, vote on, and discuss their projects (https://repl.it/ibuiltthis?sort=top). One interesting thing that we've noticed about kids on our platform is that they continue to build 90's-style website. I've commented on a recent HN thread with links to some of their creations (https://news.ycombinator.com/item?id=16506825).

Happy to answer any questions.

I've been using repl.it for a couple of (or more, I suppose) years now, and it's been very helpful to have a simple, reliable REPL to jump into, test things out, and to share code. I've turned students and colleagues to it, too. I'm excited to see where you're taking it. I hope it continues to load and run quickly.

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

Yes we aim for 2 seconds loadtime irrespective of the environment (we maybe a bit of the mark in some cases but not too far off) and part of the post was about reassuring folks like you that although it will increase in power it doesn't mean that it will be slower or more complex.

That's great to hear! :)

Amjad & Haya, it's been fascinating to watch the journey you're on. Congratulations on reaching this milestone.

The Repl.it team has been working so hard, thank you for your support.

Could you add an option to copy/clone/use a github public repo? I would love to "mount" the github repo for tflearn and run the examples. Ideally, I would love a curated list of public repos per language that lets me explore and learn.

On the roadmap. Specifically the "explore" section is coming very soon.

repl.it looks awesome. It'd be interesting to hear more about how you're doing provisioning and orchestration. Are you running a Kubernetes or DC/OS cluster by chance? Are you spinning down idle instances after some time? What actually happens behind the scenes to make a deploy go live? etc

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?

Great questions and we intend to write about this more in the future. We had to build our own container orchestration mostly for speed and customizability.

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.

Thanks! This is great. Definitely looking forward to a post.

This has so much potential but I'm finding it near unusable right now. I use the Clojure REPL, so some of these issues might be unique to it.

    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.
I could go on, but it's currently a mess from my perspective. I swear it used to work pretty well and now it's super broken. Any way I can log these issues and get them worked on?

Weird, must be a regression. Read some other comments here yesterday about the clojure repls working well. Looking into it now. For feature requests here https://repl.it/feedback

So because of all the traffic we're getting (on here, Product Hunt, and Tech Crunch) there is a lot of container pool misses and because of the JVM Clojure takes a while to load. We just upped the Clojure pool so it should work now.

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

Thanks, really helpful! I have submitted a bug report.

I hope at least for now the speed/delay issues are fixed.

Hello -- I tried to email you once to inquire about setting up a business relationship with the company I work for (one of the largest training organizations in the world).

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?

Sorry must've missed your email. I'm at amjad@repl.it

Love the clean, minimal look of your website. Definitely going to keep the Raleway font in mind for future projects.

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!

Gzipping a jpeg isn't going to save you any bytes.

Thank you. Oof, will look into that. Thanks for the tip.

Have you considered adding an advanced run option that doesn't obliterate the code in the REPL?

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.

Ah interesting I could see how this could be useful. Thank you, I'll think about how it could be implemented.

Did you move away from Emscripten? I was trying to use repl.it offline recently, and it didn't seem to work. Using Emscripten was one of the coolest parts of the original, and it would be sad if you had to drop that.

Yes, had to move even before started building the more advanced features like hosting. There were some bugs with the JS number type causing weird issues with emscripten. It's been a while so I don't remember the details.

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.

I'm teaching a couple of kids coding (they taught themselves a bit before I got involved so it's pretty fun!). We're totally going to use this. Thanks!

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

Yes, it is!

One of the main things preventing me from doing a really cool integration would be an API to programmatically create some REPLs and fill them with code.

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

We have a query param that ?code that can prefill the editor text. I'm interesting in what sort of things are you trying to build. Email me? amjad@repl.it

What kind of integration do you want to build?

I have been teaching a few kids programming but were using Racket (I personally think this is the best first language for someone to really dive into) Any chance of Racket support?

Any chance of Swift 4 support?

Yes doing a round of new langauge versions soon!

looks great, especially classroom feature.. congrats :)

I'm a university professor, and there's no way i can afford personally 1$/month per student. And definitely the school won't allow me the budget. "Use the lab computers", they'll say.. So I don't know how realistically someone can use repl.it for teaching, at least in public/higher education.

Repl.it allows each teacher account to have up to 200 students for free! Is this enough to cover all your students? If not, reach out to me at tim@repl.it and we can work something out.

Any plans to support Scala?

yes, there is. in the matter of fact, Scala is one of the top languages requested on Repl.it. We have an open issue for languages requests on our feedback channel here is a link for it https://replit.canny.io/languages-requests

Just wanted to say I love repl.it and use it all the time!

Thank you for your nice words. We always love to hear feedback from people using Repl.it, it helps us to improve and create a better experience for you and everyone else.

I'd like to echo this. It's been improving so rapidly it's hard to keep up!

We love what we do, and it makes us happy to empower you with the tools you need to build what you want using Repl.it

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact