Jan 31, 2022Understanding Repl Resource Utilization
Every computer on earth needs these three essential resources in some form: Processor Memory Storage The computers we provide for Replit users, or Repls, have access to a virtual CPU, an allocation of RAM, and a virtualized filesystem. It’s important to understand resource utilization within the context of the software that you’re writing. To this end, we have started rolling out a new component in the file tree to make this more transparent and visible to all of our users.
Jan 21, 2022Going Where the Next Billion Creators Are
Mobile is the future of computing. But building good software creation tools for mobile devices is hard. Luckily, at Replit, we like to run toward the hard things. This week, we launched a completely rearchitected mobile IDE for web. If you’ve used it before, the new version won’t look much different, but it will likely feel different. Why We Care Mobile devices are the world’s most ubiquitous computers. At Replit, we have kids coding their next big idea on their phone on the way to school, instead of scrolling through social media. We have local communities in developing countries learning & teaching code together on their phones, in order to get hired for jobs. We have colleagues coding prototypes in multiplayer and demoing their work on their phones, while they are on the go. We even noticed users sharing Replit coding tutorials on TikTok: @coding4python3 Antwoorden aan @wewillcum #replit #code #coding #coding4python3 #python ♬ origineel geluid - coding4python3
Jan 11, 2022Migrating our Web App from Heroku to GCP
After many years of running on Heroku, Replit has fully migrated to Google Cloud Platform. Why leave Heroku in the first place? Heroku served us well, but ultimately we recognized that our mission to bring the next billion software creators online would require an entirely new approach to our infrastructure. Our infrastructure needs to be flexible, and we need to have control across the entire stack - both data and hosting - to make moves to support our mission. So, what did it take to migrate Replit? Step 1: Demo a Prototype We put together a quick demo of the website running in Google Cloud using a test database (with a fake dataset) to prove the concept would work. In this stage, we also gathered feedback and started to push the boundaries to understand where the problems might lurk later in the project. We took some time to investigate alternate hosting systems and even clouds. Ultimately, because the rest of Replit's infrastructure is in Google Cloud, it made the most sense to stay with what we know.
Dec 22, 2021Implementing RUI, Replit's Design System
At Replit, we have a small engineering and design team supporting millions of users. Our secret is investing in good tools that make us more productive. In this blog post we'll give you an insider look into how we implemented one such tool - the Replit design system (or RUI for short). The project started as a collection of growth pains: Designers were stretched thin on multiple projects and they couldn't be involved in small tactical decisions UI was inconsistent across the product Reusing UI code was hard, so engineers built new ones (for example, we had 7 different Avatar components) So, we set to build a design system that would help us scale. The high level goals:
Dec 14, 2021Repl Space and Templates
When we want to support a new technology, we're faced with the question: "Do we (the Replit team) build this capability into the Replit directly, or can our users add it themselves?". Usually, we want the answer to be the latter. Repls are like personal computers for your projects. And the more these personal computers can be customized, the more they'll be used in creative, unexpected ways. Internally, we refer to the extent to which a Repl can be configured as "Repl Space". So when we talk about building new features, we always ask "can it be done in Repl Space?", which is basically asking if we can build it on Replit. Over the past year, Repl Space has become significantly more powerful, and soon, Replit will be one of the most flexible computing platforms on the planet without compromising its simplicity. Now that we have the technical foundations in place, we're excited to bring more of that power into the product in the form of Templates and some new configuration options. Templates Where can I find templates?
Dec 13, 2021Ace, CodeMirror, and Monaco: A Comparison of the Code Editors You Use in the Browser
We compare and contrast the top code editors that you use in your browser.
Nov 29, 2021Will Nix Overtake Docker?
In many discussions about Nix, the comparison of Nix and Docker comes up frequently. This question could be dismissed by saying that Nix and Docker are different tools that solve different problems. One is a toolkit for building and deploying containers and the other is a package and configuration manager. However, these tools do have some overlap: they can both be used to create reproducible environments. A reproducible environment is one that can be recreated from scratch in an identical way (ideally bit-for-bit). Practically, this means having the same tools, versions, and configuration between the environments. Reproducible environments are useful to ensure all developers on a project have the exact same set of tools. Additionally, you can develop in an environment that is similar to the production environment -- leading to less surprises when deploying. Both tools can solve the age-old problem of "it works on my machine". While both tools aim to solve this problem, they take different approaches.
Nov 21, 2021How to Set Up Your Own Mastodon Instance with Replit
With many development tools and even whole development environments moving to the cloud, Replit is at the forefront of this change. Replit is one of the leading cloud, in-browser IDEs with support for fifty-plus programming languages with syntax highlighting and intelligent autocompletion. However, Replit is more than just an IDE in a cloud. With additional features like real-time collaboration, GitHub integration, and detailed edit history, Replit is a full-blown workspace for teams, educators, and interviewers. This guide will show you how to install Mastodon in the Replit environment, showing its versatility and potential.You can follow along with this Repl. What Is Mastodon? Before we start, let me introduce you to Mastodon: an open-source social networking software.
Nov 11, 2021Announcing File Persistence in Hosted Apps for Hackers
We mostly think of repls as being full computers in the cloud, and one of the goals of the platform team at Replit is to enable people to build almost anything in replspace. In the past, when a file was stored in a repl, it would only be saved when the editor was opened. This went against our goal and made it impossible to write certain servers that changed files at runtime. This was especially hard for newcomers, because that's the easiest way to persist information. Starting today, Hacker and Teams subscribers will be able to write services that accept file uploads or store data in a local database (think SQLite) or text file, regardless of how the repl was started. A demo of what it looks like for a server to be able to save its files: https://sqlite.luisreplit.repl.co What is replspace? replspace is a term we coined up. In operating systems, memory is divided into kernel space and user space. Kernel space is where the kernel executes and provides its services. The kernel can access all of the memory, but the user cannot access the kernel's memory directly. By contrast, user space is all the memory that a user can access without modifying the kernel sources (or creating a kernel module). The term user space has also been used to refer to the programs that are run by users. This memory separation is important because the kernel manages all hardware resources, providing access control and coordination, and provides abstractions that let programs that run in user space make requests to interact with those resources. The kernel has several interfaces so that the user space programs can communicate with the kernel, the most important one being the system call interface. These use the abstractions laid out by the kernel to ensure that users and programs don't interfere with each other and also iron out differences in the underlying hardware and provide a uniform "view" of the resources available to the machine.
- Oct 24, 2021
Betting on Nix: donating $25K to the NixOS Foundation
As building software grows more like snapping Legos together, how people find and use those Legos becomes more important. That's why we are donating $25,000 to the NixOS Foundation and betting on Nix as the future of software distribution. In software, the Lego pieces are called packages. A package may be some code your program needs to call (a library) or another program your code needs to run. Historically, people have used package managers to find and install packages into their projects. Each language ecosystem has its own package manager. Replit built and open-sourced the Universal Package Manager to unify this fragmented landscape. Package managers are a holdover from the old model of programming, when development environments lived on personal computers. Now that development environments (ahem, repls) can run entirely in the cloud, fetching packages from a central server, unzipping them, and installing them into a filesystem seems shockingly archaic. The future is instant. When you press the run button in a repl, your code should run immediately, not pause to fetch packages. The Nix project unlocks instant repl runs. Nix uses content-addressable storage for its packages. If you know which package you want to use, you can compute its location on the filesystem without having to search a central repository. Which means we can put every single package on a fast disk in the cloud and skip the fetch-unzip-install cycle. When you press run, your program can instantly access all the packages it needs on a drive already mounted into the repl. The future is reproducible. What does that mean? If your repl works today, it should also work the next time you go to run it.
Oct 13, 2021Solidity on Replit: Diving into Web3
Today, we're announcing our official Solidity development template. Solidity is the language used to create smart contracts, which are programs that run on the Ethereum blockchain. This is important for the Web3 commmunity because there's finally an accessible and collaborative way to learn Solidity, which will unlock thousands of new developers in the decentralized web. You can try it out by creating a new Repl and typing solidity in the search bar. Or, go directly to the template page to fork it or leave feedback. :) Why this matters Lowering barriers to entry is core to Replit. Everything we do is intended to make software creation easier, faster, and more fun. So when new infrastructure and communities (like Ethereum) gain momentum, it's our responsibility to help people create for that new technological universe. So, why not try to build the best blockchain development experience in the world? Replit has a unique advantage here. Among other "web-based IDEs", Replit is a true general purpose computing environment. Every Repl you create is actually a Linux container, meaning everything we build sits on top of a fully functioning operating system. This gives us the flexibility to build basically anything we want. Almost any program or environment you can create locally, we can transform into a URL.
Sep 20, 2021A New Code Editor for Mobile - CodeMirror 6
Today, we are thrilled to announce CodeMirror as the new code editor on Replit for mobile devices. CodeMirror is a versatile code editor that has been specifically designed with mobile in mind, providing an excellent touchscreen experience. This change is the beginning of a focused effort on mobile development here at Replit; the editor is just the first step! The editor supports all the features you expect from a code editor, and we're working on making it even more powerful. We hope this update will be helpful for those of you who do not have access to a computer but still want to learn and create cool things. We are also working on bringing CodeMirror to the desktop to provide a consistent experience no matter what device you or your multiplayer partners are on. We will see many of the features that we currently have only on the desktop ported to mobile in the process. Keep an eye out for threads, debugger, and more on mobile. Watch this blog for a follow-up technical post on our experience with the editors of the web: Monaco, Ace, and CodeMirror. We've got a lot planned for mobile, we are so excited, and we hope you are too!
Feb 1, 2021The Internet of Fun
Yesterday, I accidentally built a chat app. Surprisingly, it wasn't the first time it happened. Before I tell you how Hackernews turned (this blog's) HTTP logs into chat, let me tell you about how a 12-year old user hacked the first chat app and community space on Replit right into a Python REPL. In 2018 we didn't know we had such a strong community of tinkerers. We knew people make games with Replit and share it with other people. But we didn't realize we'd already been a Schelling point for young hackers. One day, @pyelias created a post on our support forum saying he built a Chatroom and linked to a repl. I thought it would be a simple chatbot or something similar because I hadn't seen internet-based apps on the platform until that point. We had just opened up internet access to everyone, but we didn't support web hosting or any advanced features Replit has today. It was a very constrained environment.
Dec 2, 2020We've Been Pwned
As long as I can remember Replit has been receiving a large number of vulnerability reports. We're very grateful for these and take them extremely seriously. However, 99% of them stem from a misunderstanding of what we do. Our main product is RCE (remote code execution) and naturally this leads to a whole lot of RCE vulnerability reports. Fed up with low effort and time consuming vulnerability reports I set up this repl earlier this year. The bounty is simple: read my secret or edit my file and receive a $1000 cash prize. Either would be a critical vulnerability in our infrastructure. Having a clear goal and a prize was a good motivator, and indeed there was a lot of initial interest with many valiant attempts. All was quiet until PDanielY was messing with our developer API (currently in closed alpha). Here is how he tells the story: I was trying to make a repl.run clone and then when I tried to use it run a public repo on my alt, I saw that my main account actually connected to the repl and I could edit files and stuff. This was ultimately due to an oversight in the token minting code used by our developer API. It used a long since deprecated method of generating tokens when accessing repls owned by someone else. Instead of producing a temporary transparent fork you'd get full access to the underlying repl. Yikes! Once PDanielY alerted us we verified it looked suspicious and immediately revoked all developer tokens. Next we looked at the logs to see if anyone other than PDanielY have exploited the bug and luckily, we found none (the alpha developer program has only a few developers).
Jun 4, 2018Don't Let Your Development Environment Rot
Most systems -- both natural and artificial -- decay, rot, and eventually die. Software is no different. A lot has been written about fighting "software rot" but there's another type of rot related to software that's not talked about much -- the development environment rot. When starting a new project, you make decisions like what language to use, and which platform/runtime to run on, all of which dictates what your development environment will look like. Then you'll also make explicit choices for the development environment, like how will it run on in development mode, will it run in a Virtual Machine? Maybe on containers? How will the environment be bootstrapped? Also, what does the developer work-flow look like? What test framework and runner to use? How do you package your software? etc., etc. As you develop your software and the months and years go by, slowly but surely, you'll add more components to your system, you'll have a lot more code to test, and the overall complexity of the system increases. Now, we know that if you want to fight code complexity, you refactor your code, but how do you detect and what do you do about development environment complexity? What makes this a tricky question to answer is that the pain is not so apparent to existing developers. Like in the boiling frog fable, the frog doesn't notice the temperature increase until it's too late. Similarly, developers don't see the complexity creep until it's far too complicated that it requires you to stop making progress on your product to stop and fix the development environment rot. So how do we keep the development environment rot in check? A few ways: Keep an eye on the developer on-boarding experience