sausagefeet (u/sausagefeet)

sausagefeet commented on Show HN: Fast, Static GitHub Pull Requests github.com/stategraph/arg... · Posted by u/lawnchair

sausagefeet · 19 days ago

I work with @lawnchair, so we both have been complaining to each other about how slow GitHub PRs are for awhile. It's wild that THE feature of GH is so bad!

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.

sausagefeet commented on IBM to acquire Confluent confluent.io/blog/ibm-to-... · Posted by u/abd12

cr125rider · 2 months ago

I hope Hashicorp survives. A few higher ups I’ve talked to there made it seem like IBM wants to learn from them, not force their old ways onto Hashicorp. We’ll see. That one is still pretty new.

sausagefeet · 2 months ago

HCP wasn't any prize when they got bought, though, right? HashiCorp Cloud was more like a fog in terms of growth. A bunch of products got lost a long the way (Boundary? Waypoint?) HCP lost 50% of its IPO value by the time it was bought. Yes, I know IPO's are high and always go down, but it went from around a $14bn valuation to being bought for something like $6.5bn.

sausagefeet commented on Show HN: Encore – Type-safe back end framework that generates infra from code github.com/encoredev/enco... · Posted by u/andout_

sausagefeet · 3 months ago

How does Encore handle the following scenarios?

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?

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

pjd7 · 3 months ago

I'm not sure I would want this even if I could have it TBH. Engingeering org size is about ~200 with infra/sre/ops around ~25.

Different teams want to move at difference cadences. At a certain scale splitting up things feels a little more natural (maybe I am stockholmed by prior limitations with TF though or just used to this way of operating now).

But even then, we're moving to k8s operators to orchestrate a bunch of things and moving off terraform apart from the stuff that doesn't change much (which will eventually get retired as well). Something like https://www.youtube.com/watch?v=q_-wnp9wRX0

Terraform variable management is our larger problem (now/nearterm) when we have to deploy numerous cells of infra that use the same project/TF files with different variables. Given the number of projects/layers of TF getting cell specific variables injected is meh.

Those variables are instance size, volume size, addresses, IAM policy, keys etc.

This is in the b2b saas world with over a million MAU. We've got islands of infra for data soverignty, some global cells where each cell can communicate back / host some shared services (internal data analytics, orchestration tooling, internal management tooling and the like).

sausagefeet · 3 months ago

The way I look at it is that TF has a limitation on state size. And when you hit that limit, you have to either slow down a ton or do a (big) refactoring.

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.

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

markstos · 3 months ago

My concern for a team language choice is "How hard is going to be be hire people to write in this language effectively and how much will /they/ enjoy it?"

It's one thing to pick a language that I like and am productive in, it's another to choose a language for a larger team.

If you've found an full team of motivated and capable OCaml coders, great.

sausagefeet · 3 months ago

It has not been a challenging finding candidates for OCaml. For the most part, people who like OCaml are chomping at the bit to find a job writing it. And for those that don't know OCaml, a lot of really good devs are excited to try something different.

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

pjmlp · 3 months ago

Great choice by way, I feel too many reach out for Rust, because they lack the perspective ML type systems are not something introduced by Rust, rather a long linage of languages since ML/Standard ML.

sausagefeet · 3 months ago

The sense I get from some comments is that if you need a type system and to compile to an executable, Rust is the only option, otherwise you can use pretty much anything. But, as you say, MLs have been compiling to binaries for decades. One of the first online books on OCaml is for systems programming.

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.

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

leoqa · 3 months ago

Yeah I get the sense that terraform change application is solved by just serializing all changes? The concurrent applies isn’t that big of a deal?

sausagefeet · 3 months ago

> The concurrent applies isn’t that big of a deal?

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.

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

IshKebab · 3 months ago

OCaml has a much stronger type system than Typescript.

The real question is "why not Rust?". I've used both a fair bit and OCaml's only major advantage IMO is compile time. That doesn't seem compelling enough to put up with the downsides to me.

sausagefeet · 3 months ago

I'm the CTO of Terrateam. For "why not rust", I have found the downsides of Rust not compelling enough to use it. We don't need close-to-metal performance. We don't really need the borrow checker, a GC is fine. We are immutable by default so the borrow checker doesn't help much there.

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

laszlojamf · 3 months ago

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes?

EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

sausagefeet · 3 months ago

Certainly there are specifics between the type systems that differentiate. TypeScript generally chooses to enforce types in an ergonomic way whereas OCaml chooses to enforce types in a sound way. Whether or not that is a meaningful differentiator for someone is up to them.

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.

sausagefeet commented on We chose OCaml to write Stategraph stategraph.dev/blog/why-w... · Posted by u/lawnchair

criddell · 3 months ago

The first comments here are people reading this as if the authors are saying only OCaml can do this. They aren't.

sausagefeet · 3 months ago

Exactly! OCaml is the language I like to solve problems in, and I'm excited to solve problems in, so that's why Terrateam uses OCaml (I'm the CTO). You can do a lot (but not all) of this in Go, or TypeScript, but I don't get excited about those languages. Certainly I'll use them if I have to (our UI is written in Svelte) but building your own company is a grind, and using OCaml makes the grind just a bit more exciting, and that's an edge.