tholm

Interesting looking at the data, the questions always seemed to peek in March. Anyone have insight into that?

Because sounding skeptical and "clever" is more important to some people than providing meaningful and relevant insight into the topic at hand.

Using an LLM for this seems excessive when there are well established algorithms for detecting high entropy strings.

Great list! For me it kind of highlights how saturated this space is.

That's awesome to hear! I'm really excited to see the framework ecosystem grow.

Having worked heavily with gRPC before I like how syntactically similar WIT is to proto. Looks like its time to start experimenting more with web assembly component interop :).

Frameworks recent dig at "upgradeable" storage in the new m4 mac mini made me chuckle, upcycling an old macbook shell is even better.

Very fun to play with, Nice UI as well. Well done!

Worth noting that most of the terraform documentation for classic pulumi providers (providers build on top of TF providers) is still relevant to Pulumi.

Thanks for that, there is no pricing as it's a FOSS framework not a platform. But I get where this is coming from. Nitric currently makes money working with enterprises on cloud solutions using the framework. We do accept sponsors on github maybe that's something we could include as a pricing page?

The framework is backend focused and there is OIDC configuration you can include for authenticating requests to the backend https://nitric.io/docs/apis?lang=python#api-security but nothing at the moment for frontend auth (but always looking for new feature ideas).

I think your point on testimonials is good, the goal is trying to build trust in what we've built using feedback from our community, is there an alternative that you've seen or like better?

Avoiding vendor lock-in was the initial goal of the framework. But we've found that most of our existing user base are actually focused on a single cloud only but find developing with infrastructure from code makes their development experience much smoother, but they still get the benefit of portability from using the framework.

Given the scope of it's potential I'd even say the current state is embryonic.

Many of the problems stated might also be opportunities for innovation and disruption.

General advice though for any startup without getting into the specifics of any industry is to build an audience first if you can. You'll have a major head start on traction if you do, this can take a few forms but presenting yourself as a thought leader in the space you're looking to create a startup in is the best way, this could be via a newsletter, blog, podcast or general social media presence.

You can then use that platform to interact with your audience to find problems and ideas that resonate with them, and look at forming a startup and product ideas around that.

Thanks for that, will look at posting a Show HN for this.

Looking for some fresh eyes to take a look at this guide, its the first part of a series for building an AI Podcast using a framework that I author.

The more I've used Golang over the past few years the more I've come to appreciate the simplicity of its design and its lack of syntactic sugar.

It's made me realise that much of the sugar I was writing in other languages didn't make me more productive or my code more readable, in many cases it was actually the opposite and the usage of that sugar was more about writing more "succinct" code that was in the long run harder to understand and maintain.

Can you elaborate? I think that would be helpful for others seeing this and I can get the article updated based on your feedback.

Thanks so much for taking the time to write such detailed feedback. This is really useful and exactly the perspective I was hoping someone would look at it from :)

Recently relaunched the landing page for an OSS project that I work on, and am looking for feedback and first impressions.

Trying to fix issues we've had where the purpose of the project is misinterpreted, and trying to see if there are any gaps that can be addressed etc.

Thanks in advance for any feedback/comments :)

The article isn't discussing replacing Terraform or suggesting Terraform isn't for developers. It's stating that Nitric brings the ability to create executable documentation for Applications, the same way that Terraform does for Infrastructure provisioning.

Interesting take, what would be the benefit here? If the application code writes to a resource and you change the permissions externally without updating the code you've essentially broken the application.

It's very similar to encore, with the exception that the deployment engines are fully open source and extensible.

https://github.com/nitrictech/nitric

Not quite, actually more like Pulumi's old cloud framework https://www.pulumi.com/docs/clouds/aws/cloudfx/

Resources are documented using abstract cloud concepts in code, and then provisioned by a deployment engine. The nitric deployment engines are actually build on IaC such as Pulumi/CDKTF.

Just wanted to take the time to appreciate this comment. It is a rare thing when someone takes the time to read beyond the headline, and decide to dig deeper to understand something. Thank you.

Looked around for content on this subject and couldn't find much, and the CDKTF documentation doesn't touch on this either. So wrote a blog as a very basic guide to doing this. Hoping someone finds it useful.

As someone who prefers schema-first design this looks awesome. Having to hand cut OpenAPI specs is gross and quickly becomes unwieldy.

Disagree on the contradiction but want your take on where you see it.

I don't know what your experience is but "never" having seen any issues could also be bad thing, seeing the "don't" is just as valuable as the "do" when it comes to building experience.

Some concrete examples to demonstrate where coupling is trivially solvable would be good if you have some that you can share, where it wouldn't be trivially solvable what are the common mistakes that would be made in those cases?

If you have time to share your experience I'd really appreciate it.

100% agree with your point on application code shaping infra, that's the standard pattern that tech like this is trying to achieve, by providing a standard by which those infrastructure requirements can be automatically understood.

Fair point on the second, can I ask what you specifically mean by concrete drawings? I'd really like to understand your perspective on separation of concerns between IaC and application code better.

Thanks for content takeaway as well I really appreciate the feedback. The closest thing we have right now is a published customer use-case: https://nitric.io/case-studies/dropbio but I don't think this hits the mark for what you're after.

Thanks for the insight, your last point on reducing context windows for AI is exactly what Nitric is trying to achieve for humans as well reduced cognitive complexity for 80% of the work (from your second point).

I can see a path forward for Nitric as platform engineering solution where standardization of architecture is achieved (with the aid of AI as well), through building Nitric custom providers: https://nitric.io/docs/reference/providers/custom/building-c...

Hopefully this helps give a better idea of how it works under the hood: https://nitric.io/docs/reference/providers/custom/building-c...

Not just a feature of Pulumi, its just used as the IaC of choice for the out of the box deployment providers. This can be replaced with anything.

At its core Nitric is really a tool to collect infrastructure requirements from an application and those requirements are delivered to a server that is built using the Nitric deployment APIs.

Nitric doesn't wrap the state management for Pulumi, we actually encourage integrating directly with Pulumi's own cloud offerings to manage your infrastructure state. https://nitric.io/docs/reference/pulumi

Note this only applies to our OOTB providers which use Pulumi as our deployment engine of choice.

When you take away our providers Nitric becomes a communication layer between your application and any deployment engine that implements the Nitric deployment API: https://nitric.io/docs/reference/providers/custom/building-c...

This allows collecting a Bill of Materials of cloud concepts (e.g. APIs, topics, buckets, queues, policies etc.) and providing them however you like with code. This could be templating IaC, directly executing IaC, rolling your own solution or anything in between.

As for how we make money, currently we're doing consulting and dog-fooding our own tooling while working with existing teams struggling with more traditional deployment setups to make them more productive, their feedback is used to make own product even better :).