> The planning is happening openly, including a voluntary separation window. That creates real uncertainty for our team over the next few weeks, but we believe the outcome will be better for it.

No good way to execute lay-offs, my preference would be to do it like a band-aid. What use is it to do it in open unless they plan on having gladiatorial matches to keep your job. Otherwise it's just like a painful game of Duck Duck Goose.

1. It supports basically any file transfer protocol.

2. It is a library that is designed for long running processes.

3. Because it's designed for long running processes, it makes use of every trick it can to pipeline and re-use connections and resources.

4. It has an asynchronous API so it can be integrated into any existing event loop.

Is a web browser or database more complicated? Most certainly, they solve really massive problems. But curl is certainly more complicated than probably most application code that uses it.

Comments URL: https://news.ycombinator.com/item?id=47751800

Points: 3

# Comments: 0

1. I subjectively just like it better. Things like dtrace, jails, the init system, just click for me.

2. I think it's good to not support a Linux mono-culture. Yes, there is Windows and macOS, but in terms of open source OS's, I think it's good to have more than one choice and so for any rough edges in FreeBSD, I'm willing to deal with them to support that goal.

3. I don't think you'll find any actual, hard, technical reason to want to prefer FreeBSD over Linux on a desktop. Anything you can do in FreeBSD you can do in Linux. Heck, FreeBSD is probably even running the Linux version (for example video drivers).

But really, which Linux do you mean? Nix? Gentoo? Red Hat?

1. AI is meant to make us go faster, reviews are slow, the AI is smart, let it go.

2. There are plenty of AI maximizers who only think we should be writing design docs and letting the AI go to town on it.

Maybe, this might be a great time to start a company. Maximize the benefits of AI while you can without someone who has never written a line of code telling you that your job is going to disappear in 12 months.

All the incentives are against someone who wants to use AI in a reasonable way, right now.

I have been using Argus in anger for a few days, it needs some updates, but being "run on your own desktop" software means it can be a lot simpler than a full product, which is nice. Next feature I am pushing to get implemented: I want Reviewboard-like intra-push diffs. I have a force-push heavy workflow and GH PR view doesn't let you see the diff of what was pushed vs what I last reviewed, and that is a feature that all the data is there and I want it.

1. I want to deploy to a testing environment where I may want to use different users, different sized services, or even mock services so I don't have to pay for them? 2. I want to develop in an isolated environment (maybe without internet or simply I'm trying to develop a narrow feature that doesn't require the rest of the infrastructure)? 3. How does it handle security elements like VPCs, IAM roles, all these things that are the context my application runs in that I don't necessarily want to couple to my application code?

As comparison, if a programming language forced you to split your software into multiple executables when you got to a certain number of functions, I think, almost universally, we would say that it's not a production language. That is a stupid limitation and forcing development work on users because of stupid limitations is disqualifying.

But for TF, even if we are refactoring it because the tool is doing it, we tell ourselves that it's a good idea anyways because of good software practices. But splitting infrastructure over multiple root modules is, in my analogy, the same as being forced to do it over multiple executables. It comes with a lot of unnecessary limitations.

With Stategraph, you can choose to split your infrastructure over multiple root modules, if that is what you want to do, not because you don't have a choice.

V1 of Stategraph is a drop-in TF/Tofu replacement, but once it's there, you can see a path to something more like k8s operators, without having to do any migration of infrastructure.

I know that isn't everyone's view, but I do hope posts like this, even if not technicaly deep, at least let people know that there are lots of options out there.

That depends. There are many organizations (we talk to them) which have plans and applies that take 5 - 10s of minutes, some even close to an hour. That's a problem. We talked to one customer that a dev can make a change in the morning and depending on the week might have to wait until the next day to get their plan, and then another day to apply it, assuming there are no issues.

If you're in that position you have two options:

1. Just accept it and wait. 2. Refactor your root module to independent root modules.

(2) is what a lot of people do, but it's not cheap, that's a whole project. It's also a workflow change.

Stategraph is trying to offer a third option: if your changes don't overlap, each dev can run independently with no contention.

Even if one doesn't think contention over state is a big deal, I hope that one can agree that a solution that just removes that contention at very little cost is worth considering.

This blog post shows the elements of OCaml that motivate us to use it. Is it complete? No. Maybe it should be more explicit that we like using OCaml, and these technical aspects aren't unique but certainly benefits we see.

As you said, the common practice is to use locks on state to guarantee that operations don't step on each other. This works, however the cost is that if it takes 5 minutes to perform an operation, only one person can be doing an operation at a time, so if 5 devs are modifying infrastructure, the last one has to wait 25 minutes just to get back the plan, even if those 5 people are not changing overlapping resources in the state.

The way that most people deal with this is they take their infrastructure and break it up across multiple root modules, and then when those root modules, break it up again, etc.

Stategraph is solving the problem of getting all of the performance benefits of breaking up your root modules without breaking up your root modules. It dynamically determines which resources each of those 5 devs are operation on and, if the resources do not overlap, can run them in parallel.

That means Stategraph is manipulating state in a bit more sophisticated way than standard Terraform/Tofu, and we need to be careful we don't get it wrong.