To go along with that we've built and maintain a Rust framework for writing CNBs https://github.com/heroku/libcnb.rs. I maintain the Ruby CNB and so I'm pretty excited to see some of my stuff in action.

> Heroku already supports building and deploying containers

Kinda. Heroku created a container ecosystem before OCI images were a thing. Apps deployed to the current Cedar infrastructure are deployed as "slugs" basically a tgz of the application directory that's loaded onto an LXC container, and unzipped to run on a base image (also called a stack) https://devcenter.heroku.com/articles/slug-compiler.

One big benefit of moving towards a standards compliant future instead of homebrew, is that customers also have access to that ecosystem. That's what enables things like being able to run and debug application images locally. It's the standards and community. We went fast and blazed some trails, now we're aiming to "go far," together with the community.

The other article that's not been linked yet is this one https://blog.heroku.com/next-generation-heroku-platform. It's still not exactly what you're asking for "give me the application features" but it is a little less lingo heavy.

One thing kinda hidden in there:

> and AWS Graviton into the platform.

That means ARM support. Already the Heroku supported buildpacks work with both AMD (x86) and ARM (aarch64). Think mac Intel versus M(1/2/3/4) chips.

> From a customer (AKA Application Developer) perspective

I posted another comment earlier. Local debugging with CNBs is pretty neat. But I also agree, I see this still as an "investment" phase. This is the start of the work, that gets us more fun stuff later.

> How about improving your autoscaling options so the narrow response-time-based scaling is not the only option?

This is not my team, so I'm speaking not from first-hand experience. It's my understanding that Kubernetes has a pretty rich ecosystem for autoscaling. On our current platform, if someone wants to try out an autoscaler, it's a bespoke solution and difficult to try in the wild. Moving to a more standards based and community backed infrastructure means what's easy to do on Kubernetes, should also be easy for us to do on Heroku on the new platform.

I hear that you care about autoscaling options and I'll pass that along. Anything specific in that area?

That is why I point that the change of meaning in C from CLR.

And companies which strictly choose only whatever comes out of box are unlikely to use F# anyway. The concept itself is incorrect and, I argue, must not be applied beyond ASP.NET Core and EF Core. There are no "first-party" frameworks in many other languages in either case so it is an unfair and flawed argument in the context of .NET.