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)

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

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?

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

That said, I would guess the 'bigger conversation' is that it is much harder to tpyo <> 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

    $ cat Foo.java
    interface Foo {
        private String jimbo() {
            return "yup";
        }
    }

    $ javap -c -private Foo
    Compiled from "Foo.java"
    interface Foo {
      private java.lang.String jimbo();
        Code:
           0: ldc           #1                  // String yup
           2: areturn
    }

    interface Bar {
      default boolean isAwesome() {
        return true;
      }
    }

But, I am fully talking out of school because I don't know what the actual, no kidding, accessibility hurdles one faces when trying to do work in such a setup, nor what concessions VS Code has made to fix those problems

But I do know that YouTrack has a dedicated categorization for accessibility reports and I am sure they would welcome hearing about how they could win back those audiences https://youtrack.jetbrains.com/issues?q=%23%7BUI.%20Accessib...

And sure, it's not everyone's cup of tea, and/or plenty of people will chime in with "yes, but"s to defend golang or every other platform that isn't the JVM. I'm not yucking your yum! I'm just saying for me, the JVM is the bees knees

However, above and beyond free, it is also a collection of ECMA standards https://learn.microsoft.com/en-us/dotnet/fundamentals/standa...

Now, don't get me wrong: I have grave suspicions there is currently only one actual implementation of them (I don't count hobby, or abandonware, ones) but IMHO "actual standard" combined with "for real reference implementation" is way better than just reference implementation

---

since I'm still within the edit window, the MAUI referenced by the sibling comment is MIT licensed https://github.com/dotnet/maui

https://github.com/dotnet/blazor (Apache 2) is marked an archived, and points to https://github.com/dotnet/aspnetcore (MIT) but command-f blazor on its readme is nothing so :shrug: