Merge pull request #115412 from ggailey777/cleanup

Remove experimental languages

Author: ttorble

articles/azure-functions/functions-custom-handlers.md

@@ -15,9 +15,9 @@ Custom handlers are lightweight web servers that receive events from the Functio
 
 Custom handlers are best suited for situations where you want to:
 
-- Implement a Functions app in a language beyond the officially supported languages
-- Implement a Functions app in a language version or runtime not supported by default
-- Have granular control over the app execution environment
+- Implement a function app in a language that's not officially supported.
+- Implement a function app in a language version or runtime not supported by default.
+- Provide more granular control over the function app execution environment.
 
 With custom handlers, all [triggers and input and output bindings](./functions-triggers-bindings.md) are supported via [extension bundles](./functions-bindings-register.md).
 

articles/azure-functions/functions-reference-node.md

@@ -569,9 +569,6 @@ A generated `.funcignore` file is used to indicate which files are excluded when
 
 TypeScript files (.ts) are transpiled into JavaScript files (.js) in the `dist` output directory. TypeScript templates use the [`scriptFile` parameter](#using-scriptfile) in `function.json` to indicate the location of the corresponding .js file in the `dist` folder. The output location is set by the template by using `outDir` parameter in the `tsconfig.json` file. If you change this setting or the name of the folder, the runtime is not able to find the code to run.
 
-> [!NOTE]
-> Experimental support for TypeScript exists version 1.x of the Functions runtime. The experimental version transpiles TypeScript files into JavaScript files when the function is invoked. In version 2.x, this experimental support has been superseded by the tool-driven method that does transpilation before the host is initialized and during the deployment process.
-
 The way that you locally develop and deploy from a TypeScript project depends on your development tool.
 
 ### Visual Studio Code

articles/azure-functions/functions-versions.md

@@ -7,25 +7,17 @@ ms.date: 12/09/2019
 ---
 # Azure Functions runtime versions overview
 
-The major versions of the Azure Functions runtime are related to the version of .NET on which the runtime is based. The following table indicates the current version of the runtime, the release level, and the related .NET version. 
+Azure Functions currently supports three versions of the runtime host: 1.x, 2.x, and 3.x. All three versions are supported for production scenarios.  
 
-| Runtime version | Release level<sup>1</sup> | .NET version | 
-| --------------- | ------------- | ------------ |
-| 3.x | GA | .NET Core 3.1 | 
-| 2.x | GA | .NET Core 2.2 |
-| 1.x | GA<sup>2</sup> | .NET Framework 4.7.2<sup>3</sup> |
-
-<sup>1</sup> GA releases are supported for production scenarios.   
-<sup>2</sup> Version 1.x is in maintenance mode. Enhancements are provided only in later versions.   
-<sup>3</sup> Only supports development in the Azure portal or locally on Windows computers.
+> [!IMPORTANT]
+> Version 1.x is in maintenance mode and only supports development in the Azure portal or locally on Windows computers. Enhancements are provided only in later versions. 
 
 This article details some of the differences between the various versions, how you can create each version, and how to change versions.
 
 ## Languages
 
 Starting with version 2.x, the runtime uses a language extensibility model, and all functions in a function app must share the same language. The language of functions in a function app is chosen when creating the app and is maintained in the [FUNCTIONS\_WORKER\_RUNTIME](functions-app-settings.md#functions_worker_runtime) setting. 
 
-Azure Functions 1.x experimental languages can't use the new model, so they aren't supported in 2.x. 
 The following table indicates which programming languages are currently supported in each runtime version.
 
 [!INCLUDE [functions-supported-languages](../../includes/functions-supported-languages.md)]

articles/azure-functions/supported-languages.md

@@ -1,38 +1,33 @@
 ---
 title: Supported languages in Azure Functions
-description: Learn which languages are supported (GA) and which are experimental or in preview.
+description: Learn which languages are supported (GA) and which are in preview, and ways to extend Functions development to other languages.
 ms.topic: conceptual
 ms.date: 11/27/2019
 
 ---
 
 # Supported languages in Azure Functions
 
-This article explains the levels of support offered for languages that you can use with Azure Functions.
+This article explains the levels of support offered for languages that you can use with Azure Functions. It also describes strategies for creating functions using languages not natively supported.
 
 ## Levels of support
 
-There are three levels of support:
+There are two levels of support:
 
 * **Generally available (GA)** - Fully supported and approved for production use.
 * **Preview** - Not yet supported but is expected to reach GA status in the future.
-* **Experimental** - Not supported and might be abandoned in the future; no guarantee of eventual preview or GA status.
 
 ## Languages by runtime version 
 
 [Three versions of the Azure Functions runtime](functions-versions.md) are available. The following table shows which languages are supported in each runtime version.
 
 [!INCLUDE [functions-supported-languages](../../includes/functions-supported-languages.md)]
 
-### Experimental languages
+## Custom handlers (preview) 
 
-The experimental languages in version 1.x don't scale well and don't support all bindings.
+Custom handlers are lightweight web servers that receive events from the Azure Functions host. Any language that supports HTTP primitives can implement a custom handler. This means that custom handlers can be use to create functions in languages that aren't officially supported. To learn more, see [Azure Functions custom handlers (preview)](functions-custom-handlers.md).
 
-Don't use experimental features for anything that you rely on, as there is no official support for them. Support cases should not be opened for problems with experimental languages. 
-
-Later runtime versions do not support experimental languages. Support for new languages is added only when the language can be supported in production. 
-
-### Language extensibility
+## Language extensibility
 
 Starting with version 2.x, the runtime is designed to offer [language extensibility](https://github.com/Azure/azure-webjobs-sdk-script/wiki/Language-Extensibility). The JavaScript and Java languages in the 2.x runtime are built with this extensibility.