It's really exciting to see the Nix ecosystem start to gain traction here and there. I expect and look forward to greater adoption over the next half decade or so
Let's say you're building Python. You write a rule to build Python, which is something like "Get a tarball from python.org/... with hash abcd1234; depend on glibc and zlib and OpenSSL; ./configure && make install." The libraries each of which have their own rules like that, say "Get a tarball from gnu.org/glibc/... with hash dbca4321; ./configure && make install."
You can hash these build descriptions themselves, and that hash is available to you before you start building. So the hash of that glibc description is 98765432 - which includes the hash of the tarball. So you install glibc into /nix/store/98765432-glibc-2.30. (The name and version there are just for human convenience.) Then, when you install Python, you point it at the glibc in that directory and build it into e.g. /nix/store/aaaabbbb-python-3.9.
If anything changes - tarball hashes, build steps, dependencies - the Nix hashes of everything affected also change. So the two versions, with and without the change, can be installed side by side.
There are separate mechanisms in Nix to do things like get the hash of the "current" version of Python and put it on your PATH.
(The downside is that Nix does not make use of the ordinary dynamic-library behavior where you can upgrade OpenSSL without recompiling Python. It does use dynamic linking, but it always points at exact paths and the thing being pointed to never changes versions. But there are good reasons to prefer this anyway, and the only downside is compilation time, and computers have gotten a lot faster since Linux distros and dynamic linking itself were originally designed.)
I'm not sure exactly where your focus is, so I'll just give you a mix of thoughts and see if I accidentally help :)
- Building takes space, but the build takes place in a temporary directory that is discarded afterwards, and only the output artifacts are kept.
- ~Normal software is usually served pre-built from a cache, which short-circuits the above as long as the package is available from the cache.
- One of the nicer things about the process Nix uses here is that it's also tracking what's ~in-use (via "GC roots"), and you can trivially garbage-collect everything in /nix/store that isn't.
- On macOS I use Nix for just about everything that isn't a desktop app. My /nix mount had 9.7G used when you asked this question, and 3.6G after I garbage-collected, and 7.1G after I re-built the dev environment for a server project.
- The ~3.4G I mentioned above is a really big fraction of my total, but as a reference point, Nix is natively replacing, in ~3.4G, the Vagrant/virtualbox VM I used to need for this development.
- In my experience, the only time I'd describe the storage load as "a lot" is when I've been iterating on something that is fairly large. This can add up as the store accumulates slightly-different copies, but these can be readily GCed.
- Multiple versions of something (say, multiple different pythons or rubies or llvms) will consume more space, but the ~Nix way also makes it possible to avoid vendoring. At system scale I would _guess_ these are a wash?
- At least when you're using Nixpkgs, "multiple versions" generally just means a few major/minor version variants of common dependencies (i.e., at a single commit, most things in Nixpkgs that use Python 3.7 reference the same build).
Each package does use the same amount of space as with other packaging methods, but when you upgrade things, Nix won't garbage collect it you can run it manually, from schedule, there's also an option to have nix run it on every invocation (kind of like git does).
Anyway I wanted to also to make comment to GPs explanation. What is written, is how Nix is currently addressing each package (it's a hash computed based on source code, dependencies, system, compile options etc).
In many cases different options or change in source files can still produce the same exact package, but under a new hash. Nix has an optimise-store command that scans its store and if two packages have exact same result it uses hard links. That similarly can be run via schedule. This ensures that duplicates do not occupy extra space.
Though in context of nix, what is referred as content addressed is the new way Nix planning to address the package. Instead of computing hash from package and its dependencies it computes hash based on the package's contents. That solves many problems with the old way, but of course question is how is it done, because it kind of is impossible to get hash of something that you did not produce yet. Of course like everything of this kind, it's possible to do if you cheat a bit. Package is first compiled with a dummy paths, then hashed, then references to those paths are substituted.
Here's more about [1].
Having said that, in the blog article when they use "content addressable" it looks like they still meant the current way of doing it (it looks like proper term is input-addressable), not the new way, but if you search "nix content addressable" you are likely find articles about the new way and things might get confusing.
Each package in /nix/store is in a directory $hash-$pkg-$vers (technically $vers isn't even required since the $hash can already distinguish them). Therefore each can have its own independent dependency tree. For a more detailed explanation see https://shopify.engineering/what-is-nix#:~:text=Language-,th....
Just don't expect a response from their support, even if you're a paying customer. I've reached out multiple times for different issues via email and haven't heard back. Trying to find their support email was hard enough since it seems to only be randomly posted in their community support forums:
Funny enough this company should come up since earlier today I tried to reach out to them over Twitter. Just crickets so far.
I get being a startup and all is hard, but if you're taking customers money and the only way to get help is community forums, that's pretty inexcusable.
EDIT: They've responded to me via Twitter now. I really like the Replit product and I think it's pretty innovative. I've commented about it on HN before in a positive light. It's unfortunate they haven't given as much attention to their customer support and that I had to post something negative here to get attention. I do hope they make a change. It would be a net benefit for their customers and their brand overall.
Hi James -- we do pride ourselves on our customer support and as you've seen on Twitter I do a lot of support personally too, and have my email publicly to help people.
In this case, it was a technical issue -- we're still trying to understand what and why it happened but GMail automatically trashed your email and so Front didn't assign it to our support staff.
I mean, here's one instance where gmail's uber sophisticated AI seems to have classified a seemingly legit email spam?
For a company that prides itself in customer service, I don't see any other way but to run their own email exchange (ala Amazon) because their private systems can then discern between email-ids of paying customers and spam, if nothing else.
I don't get that. Normal downtime is about the hardest way to fuck up email. I believe the last time my small office mail server didn't deliver legitimate mail was when I was 18 and haven't quite figured out yet what the hell was running on all these computers, and it literally ran a week with disk full.
I mean there are things about Gmail that might make one think - I shouldn't use this as the email of my business if it is important to me - lots of them exposed and upvoted on this forum.
For a small startup, I like GrooveHQ. It’s like the Zendesk experience but less janky, much simpler, and well suited to a small team. Just have your support emails forward to Groove. Will still be email support from your user’s perspective. You can keep your current workflow going but turn on forwarding to try it out.
In my experience, any ticketing system will be a huge improvement over using a shared gmail inbox for support.
I've run my own for 15 years with no problems. So I recommend learning how to set up postfix. If you prefer not to do that, people here seem to praise fastmail pretty uniformly.
Appreciate you reaching out to us and being patient. Our average response time is under a day, but it looks like your emails were being archived before reaching our shared inbox. Either way this is on us and we are looking into why it was the emails never got to us as well as the issue you reported. I have also responded on the email, so will continue the conversation there.
If you (or anyone else) does not hear back from us after reaching out feel free to add urgent to the subject line or cc me obaida@replit.com to the email and I will make sure we get to it.
The actual REPL is the least impressive thing about replit!
If you use an HTTP server it will automatically route whatever port you opened to 443 on its own replit.co subdomain. If you use a program with an X11 context, replit will automatically detect that and render it in its own in-page visual context; plus they allow VNC connections to that environment via NoVNC. They have an HTTP API that allows repl-instance-specific persistent storage.
I'm not a paying customer or an employee or anything but I gotta say they're pretty innovative. (I will agree with others that the documentation IS definitely their weakest point, but that in part because they have so many features.)
I've been using Replit to make demos for some lunch & learn events at work. It's easier when we don't all have the same development stack, various combinations of languages + IDEs + OSes. I've done most of the demonstrations with Java. However, there were some demos in other languages I was wanting to do that weren't feasible within Replit that now will be (at least theoretically). I'm looking forward to trying this out later this week.
I like the idea of nix; and I love having the confidence of being able to easily install the same versions of software I like using on whatever machine I'll be using.
Typically, though, the number of times I'm setting up a computer so that I can work on it is best measured in "x times per year". For that case, it's harder to argue that Nix is worth spending the time compared to just slowly setting up each computer manually.
I think in this case, each user being able to use an ephemeral environment and quickly set up a familiar environment is where use of Nix seems much nicer than alternatives.
> For that case, it's harder to argue that Nix is worth spending the time compared to just slowly setting up each computer manually.
Actually that’s an even better justification for using NIx instead of slowly setting up each computer manually.
If you’re setting up a new computer every week, or even every month, you tend to remember all the packages, configs, and tweaks you need just from frequently doing it.
But if you need to set up a computer once a year, you forgot all that stuff, making it even more valuable to have it all scripted in a deterministic build.
This blog post “Erase Your Darlings” discusses this issue, along with a really interesting solution to it:
So much this. I’ve been setting up a new computer recently, first time in a while, and in the process I’ve been moving a bunch of stuff into Nix that was previously ad-hoc, specifically so I don’t have to remember about this again (and especially since I know I’ll be setting up another computer again in the near future). I even finally adopted nix-darwin and home manager in order to move more things under the Nix umbrella.
Additionally consider that you may consider ephemeral environments impractical for daily/frequent use because it would constantly lose your configurations and take forever to bring back up.
I just tried out the i3 repo linked at the bottom of the blog post, and uh wow. Here we have what looks like an X Window session, accessible via (presumably) VNC embedded into the browser, running a custom tiling window manager (i3), with xterm, neovim, and firefox available. All on a site that’s supposed to be for writing code and hosting apps.
X and xterm are accessible because they also let you run graphical apps, for example you can program using pygame. I'm not sure why they would add neovim and Firefox.
Hi, one of the authors here.
The Nix environment on Replit is under development right now, we hid the configuration files to clean up the filetree as most users shouldn't need to know about the config files unless they are customizing the repl environment.
However, we are reverting that change for now since we don't offer a good way to access those files yet. I'll reply here once they are visible again.
This looks pretty cool. I've been working on a bunch of monorepo tooling with Nix, and something like this (especially with LSP integration via Nix) would be amazing.
A bit difficult to experiment with though, as it is one of the "GitHub-only" tools :/
Seems like it would be cool if it (by default?) left you in the nix-shell environment? This would let people who don't grok nix just run `zig`, for instance.
I used to easily add a sidecar container to my k8s workload, with the tools I need, without having to maintain a dockerfile and setup an automation to build the container.
I came to know replit after a coding interview. It was coding editor on the page and I picked Java. I was used to leetcode coding environment. I use tab. My biggest mistake. Every time write something and hit tab, the editor goes out of focus. It was so frustrating that I could barely focus on the coding part. Not only that, it wasn't full screen coding editor. I was coding in small window and had to scroll up and down. I didn't clear the interview, but the memories for replit stuck with me.
This is impossible. There was never a time where the Replit editor didn't capture the tab key (that would be dumb). It must've been something else. Maybe it was a homemade "REPL" the company you were interviewing with made?
I was surprised too! I was sent a link and then it opened the replit site. The window was split vertically and one half it was coder editor. It looked like a "free" version where you can type some code and run it. And every time I hit tab the editor went out of focus.
Neat. If this works as advertised (and it seems to), this rockets it past the capabilities of Glitch when it comes to language support.
I had to do a fair bit of work to get anything but node running on Glitch, and since then it seems like the performance limits and startup time have gotten a lot worse, making it more and more painful to use. I have an Elm framework for slideshows I use there, and was constantly frustrated by my editor timing out every time I alt-tabbed and taking ages to reload.
I hate to be that guy but he did say every programming language. So I work with three on my current project. I was pretty certain one that wouldn't be on the list, but never suspected that all three wouldn't be there. For the record they're Vue, Nuxt and CFML (Lucee), all open source.
I think it would be cool if projects/repos had a .envconf or .envsetup that described how to setup the environment in order to compile,run, and develop the software. So that different IDE's could use this information to automatically setup the workspace/environment.
Yup, you can setup Haskell with Nix. I'm not too familiar with Haskell, but it looks like Nix even has a collection of Haskell packages (including lens). This looks like it is a good resource for getting started with Nix + Haskell https://notes.srid.ca/haskell-nix, you should be able to follow along in a Nix repl. I recommend forking on of the example repls from the blog post.
OK, experimenting with this example, I attempted to import a simple Racket web app (https://github.com/jarcane/RantStack). I've provided links to the REPLs too for both attempts.
attempt 1) I was able to import a Racket app from Github, added a similar nix config to it as described in the docs, but it would not run as it says nix-shell is not present. Apparently a repl needs to be blessed some how as a Nix instance to work, but there's no option to select that when importing or creating a repl.
URL: https://replit.com/@jarcane/RantStack
attempt 2) Next I tried just forking your template, and literally just copy-pasting the code from my app (it's a single file anyway) into the main.rkt. This runs the app ... but I can't actually access it, because apparently the ports aren't being forwarded. Going to the URL as described in the repl.it docs just gives me an eternal "Repl waking up" screen that loads forever, but never resolves.
URL: https://replit.com/@jarcane/racket
Sorry, building nix environments from scratch is still rough around the edges and we are working to improve that at the moment.
When hosting a web server, your app must listen on 0.0.0.0, adding that to your repl seems to make that work. I will make sure that is in our docs for web hosting.
Ahh! That was the missing piece of the puzzle, thank you.
Also played a bit with the Glitch import on an Elm import but found it broke npm in weird ways (something about a file being moved but not found?), but then the Github import of the same project wouldn't work either because of Node version incompatibilities that don't seem to be repl.it's fault exactly other than just "it runs node 12 and some stuff is broke on node 12".
Does look promising otherwise though, with the Nix support I can see soooo many things being possible that simply weren't on other similar options like this.
Yeah, we are really excited about the future Nix will bring for us at Replit. Soon, language version incompatibility will be a thing of the past on Replit.
Yeah. Somewhat notably, GNU Ada/gnat has been broken in Nix forever, and generally the difficulties of making things work correctly under Nix is great enough that some stuff is pretty hard to keep up to date or available at all. Of course it works well for almost everything, but there are limitations; it definitely is a complex thing.
edit: It looks like my information might be out of date as it appears gnat is back in Nixpkgs. That's great news, although I think the point regarding complexity still stands, since I believe it was broken for quite a while at some point, and broke a few times since too.
No, you don't. Fortran is still an important language in scientific computing, and you don't support it. The gfortran compiler is part of gcc, so I think you should be able to. I also don't see Cobol, Ada, and Pascal. If you don't think these languages are worth supporting, so be it, but asserting that they don't exist may irk people using those languages.
We will be expanding our collection of templates over time, but Nix allows us to make language setup be a user-space concern instead of us internally maintaining a collection of languages configurations and docker images.
Thanks, it works for me. Gfortran is a traditional compiler, but LFortran is "is a modern open-source (BSD licensed) interactive Fortran compiler built on top of LLVM. It can execute user’s code interactively to allow exploratory work (much like Python, MATLAB or Julia) as well as compile to binaries with the goal to run user’s code on modern architectures such as multi-core CPUs and GPUs."
When LFortran is ready, it would be nice if you supported it too, since it is a Fortran REPL.
