I think JSON allows both of your use cases, you'll just have to define your own deserialization.

We've used { "__type": "DOG" } as metadata flags in GraphQL and JSON API's for a long time.

I rarely see an API return anything other than an ISO8601 UTC datetime string anymore other than Xero's horrific .NET(?) string " /Date(1326480130277+1300)/"

We already use comments in JSON without JSONC in lots of projects. Adding a { "//": "My Comment" } line works and most API's ignore excess fields.

A good json schema validator will usually reject excess fields.

Actually, currently, this is not the case. The specification explicitly allows for additional fields for the purposes of extensions. We are considering changing that, and only allowing pre-defined fields, or having a way to mark specific fields as limited extensions.

Huh, you're right. There is additionalProperties, but I mistakenly thought `"additionalProperties": false` was the default.

It is not =]

Additionally, the value is a "schema" as opposed to a boolean, meaning you can apply a subschema to any additional fields. Useful if you for instance want to make sure any additional fields start with a specific prefix.

Booleans are valid schemas. It's subschemas all the way down! I wrote an article around this topic: https://json-schema.org/blog/posts/applicability-json-schema...

That's pretty much what coc.nvim is

I moved our massive lerna monorepo to yarn v2 with PnP workspaces and cut 20 minutes off our CI time, deploy/build time (typescript) cut dramatically and reduced even our frontend bundle sizes thanks to the new and improved dedupe. It took all of maybe 10hrs but I've already made that back easily.

Also checking out branches and syncing takes all of 3s versus the massive link process we used to have to do.

Love yarnv2

This has less to do with vim than with Terraforms poor LSP support.

Vim/Neovim has had LSP support for some time with plugins and now built in natively.

I use COC vim as it's the fastest to get started and I rarely have to do much config as it's based on VSCode and comes with sane bindings for go-to-def, refactoring and more. https://github.com/neoclide/coc.nvim https://github.com/prabirshrestha/vim-lsp https://github.com/neovim/nvim-lspconfig

You can try to use either of these implementations: https://github.com/juliosueiras/terraform-lsp https://github.com/hashicorp/terraform-ls

These are both fairly limited but you can see every editor (except intellij) uses this under the hood.

I've used them at companies with 300+ terraform repos and have never had much of an issue navigating/understanding TF through Vim.

By no means am I placing the blame at vim's feet. I know it is a terraform problem.

Do those projects allow me to follow a user defined variable to its definition?

Love the article and the perspective.

Don't think the general notion that serverless is either a return to the past or a negative development is true.

Long feedback loops seem to be more of an issue with a lack of engineering discipline where I've worked. Implementing a comprehensive, fast test suite is up to the team to build, not AWS. Serverless is a tool like any other that needs to be used in a responsible manner.

If you're using cloud features that geniunely cannot be tested locally or quickly I would reconsider using more stable technologies that are perhaps enhanced by your cloud provider instead of totally replaced by them. _You_ are responsible for creating a short feedback loop regardless of your deployment environment.

I've been using serverless in both GCP and AWS for many years now and have helped migrate mid sized startups onto those platforms for event processing and API build. In that time I've seen bills go from thousands of dollars to a few dollars a month.

Mid sized startups are now able to compete in data heavy fields precisely because of technologies like serverless that have enabled small teams to build scalable systems. When you work in transaction processing or analytics I think you'll understand that scalability directly limits how many customers your platform can support.

Not everyone just makes simple json http endpoints.

Thank you for providing a more nuanced answer.

I definitely agree that feedback loops, local dev, and testing are the things I hear about people struggling with.

For the most part that is a one time cost that your team can breeze through if you invest some time in initial setup.

If anyone out there is looking for a painless transition take a look at netlify and vercel. If you outgrow them later there is minimal lock in.

I also use pulumi for infrastructure mgmt, and it works extremely well as a lambda dev pipeline that manages complex stacks with ease.