mdaniel

> the biggest corporate users of both Java

I bet AWS would give them a good run for their money on that metric. I got the impression that Google was predominately a C++ shop, whereas the rumor mills tell me that most of the AWS control plane is in Java (I am pretty sure I've actually gotten a stack trace from an AWS API once or twice, but foolishly I didn't save it)

Another bullet dodged, since saying Ellison 3 times in a row would cause a gaggle of lawyers to appear in the room

For fear of having dang show up and scold me, I'll just add the factual statement that I will never ever believe any open source claim in any Launch HN ever. I can now save myself the trouble of checking, because I can be certain it's untrue

I already knew to avoid "please share your thoughts," although I guess I am kind of violating that one by even commenting

The very idea of those 3 things being disjoint is a supremely Microsoftian thing to do and makes discussions horrific

> easy to tell or predict what terraform will do

predict is the operative word there, because Terraform is so disconnected from the underlying provider's mental model that it is the expression "no plan survives first contact with the enemy" made manifest

Now, I am one million percent open to the pushback that "well, that's a provider's problem" but I also can't easily tell if they are operating within the bounds of TF's mental model, or is it literally that every provider ever is just that lazy?

Spoken like someone who hasn't tried one or perhaps both of those projects

Kiro is collaborative, but SpecKit is a bunch of templates and then wishes you good luck in your journey. It honestly reminds me of those unified process templates, which I guess all of those are great if one needs some structure to organize ones thoughts

As an alternative, SpecKit is also 0.x release so maybe in 9 months it'll be useful - or overcome by whatever 'ooh, shiny!' follows it

I wasn't trying to relate anything to the bigger conversation, I just meant to draw attention to the fact that GitHub is not golang's package manager

That said, I would guess the 'bigger conversation' is that it is much harder to tpyo <<import "github.com/DataaDog/datadog-api-client-go/v2/api/datadogV2">> than $(npm i dataadog) or similar in a "flat" package namespace (same for its $(uv pip install dataadog) friend)

None of those cited ones fix the dependency lineage issue, proving that release 1.1 was authored by the same chain of custody as release 1.0 of any given package. One can opt in to gpg verified dependencies in Maven, but it is opt-in. The .jar artifacts can also be cryptographically signed, but the risk that's trying to drive down is tamperproofing and not lineage, AFAIK

This must be satire