231–240 of 249 posts
How does a payment service wind up with over a 1000 engineers? I understand that "engineers" may not mean "developers", it could DevOps, site reliability and all the bits and pieces that make up a large service provider, but over a 1000? Can someone please enlighten me?
Earlier quoted context omitted.
> Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. No different to having thousands of smaller repos instead. I personally dislike monorepos, for very niche, in-the-weeds operational reasons (as an infra person), but their ergonomics for DX cannot be understated.
The 'ergonomics for DX' benefit is that you can share code across projects without having to go down the path of creating a package / library pushed to some internal registry and pulled by each project right? Or are there any other aspects to the monorepo architecture that make it beneficial for large companies like that? Just curious, I've never worked in such an environment myself.
Earlier quoted context omitted.
did the word rot change meaning recently? pin is what causes rot, not what solves it.
Different kind of rot. With nix and flakes, I can come back to a project 5 years later and as long as external dependencies (i.e. package sources) still available it will bring me back straight to that environment like it was yesterday. If you have a Dockerfile from 5 years ago...well good luck building it today.
Earlier quoted context omitted.
> I'd go as far as to suggest both monorepos and dev-boxes are complex toolchains that many organizations should consider avoiding. I'm not sure "monorepo" means the same thing to you as it does to me? To me, it just means "keep all the code in one repo, instead of trying to split things up into different repos." To me, it's the thing that is the simple solution, it just means "a repo" -- the reason it gets a name is…
> To me, it just means "keep all the code in one repo, instead of trying to split things up into different repos." To me, and perhaps more from a Devops-like perspective, mono repo means "one repo many diverse deployment environments and artifacts often across multiple programming languages". Im advocating against the Google/Stripe situation of a singular massive repo with complex build tools to make it function - li…
Earlier quoted context omitted.
Maybe I'm missing something here but couldn't you just track the whole VM setup (dependencies, dev tools, telemetry and everything) in your monorepo? That is, the VM config would get pulled from master just like everything else, and then the developer would use something like nixos-shell[0] to quickly fire up a VM based on that config that they pulled. [0]: https://github.com/Mic92/nixos-shell (not to be confused wit…
Yes, but this still "freezes" the VM when the user creates it, and I've got no tools to force the software running in it to be updated. It's important that boxes can be updated, not just reliably created. As just one reason why, many developers need to set up complex test data. We have tools to help with that, but they take time to run and each team has their own needs, so some of them still have manual steps when cr…
Earlier quoted context omitted.
Yes, but this still "freezes" the VM when the user creates it, and I've got no tools to force the software running in it to be updated. It's important that boxes can be updated, not just reliably created. As just one reason why, many developers need to set up complex test data. We have tools to help with that, but they take time to run and each team has their own needs, so some of them still have manual steps when cr…
Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though? (So not really different from updating any other project dependencies?) Moreover, shouldn't something like nixos-shell take care of this automatically if it detects the VM configuration (Nix config) has changed?
Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much as possible. And as per my earlier comment, setting up a fresh VM can be quite expensive in terms of developer time if test data needs to be configured.
Earlier quoted context omitted.
> For overwhelming majority of programming projects out there they fit on a programmer's laptop just fine. What? No. You live in a very sheltered world, my friend.
Talking form a perspective of someone who worked at Google and one other similar company that shell remain nameless... as well as simply looking at places like Github where people tend to post projects they are working on: I don't know of any Github project that would be even in the size range to cause any discomfort for a laptop user. Even when it comes to the larger projects: I have multiple checkouts of GCC and Li…
Not something I would ever own myself, though, so don't generalize.
P.S. The issue is compiling and running all this stuff. Just doing a 'git clone' and nothing else isn't developing.
Earlier quoted context omitted.
That's, like, just your opinion, man. Scheme and/or Lisp is literally the worst language choice for this problem domain.
Why is Lisp the worst for this problem domain? I will admit I find guix to be much more verbose than Nix.
Earlier quoted context omitted.
Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though? (So not really different from updating any other project dependencies?) Moreover, shouldn't something like nixos-shell take care of this automatically if it detects the VM configuration (Nix config) has changed?
> Isn't this a matter of not reusing old VMs after a `git pull/checkout`, though? Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much a…
Earlier quoted context omitted.
No but I'd be happy to (I maintained the docker-compose stack, our CLI, and did the transition to Nix).
Hi Jason! Like many others here I'm looking forward to that blog post! :-) For now, could you elaborate on what exactly you mean by transitioning from docker-compose to Nix? Did you start using systemd to orchestrate services? Were you still using Docker containers? If so, did you build the images with Nix? Etc.
Short version of the Nix transition: the CLI tool would instead start services using nix-shell invocations behind pm2. So devs still had a way to start services from anywhere, get logs or process status with a command… but every app was running 100% natively.
At the time I was there, containers weren’t used in production (they were doing “App” deploys still) so there was no Docker target that was necessary/useful outside of the development environment.
Besides the performance benefit, microservices owning their development environment in-repo (instead of in another repo where the compose configs were defined) was a huge win.