我们总是有更适合在特定场景中使用的语言。对于快速原型开发，VB6 是一个显而易见的选择。在具有简单桌面用户界面和标准且不复杂的数据库交互要求的项目中选择了 VB6。如果您想使用低级例程开发设备驱动程序，您可能依赖于 C 或 Visual C++。ASP 是开发 Web 界面的标准选择。粗略地说，每种语言都有特定的“领域”或“专业化”。
使用 .NET 框架，所有语言都可以互操作并且可能是一致的。您可以拥有一个项目，其中包含来自不同语言的模块，但最终都被相当相似地对待（都被编译为 IL）。
这是否意味着我们之前的区别不再存在？这种差异不一定是坏事，而是设计上存在的，而不是由于任何限制。随着 .NET 框架及其对各种语言的处理，这显然有所减少。
区别仍然存在。例如，VB.NET 目前以比 C#（不包括 C# 4.0）更好的方式支持 IDispatch 后期绑定，并且 VB.NET 具有与代码内联的 XML 文字，与其他 .NET 语言相比，这使其成为操作 XML 的便捷工具。C++ 往往不太适合 .NET，即使使用 C++/CLI 变体也是如此，但它非常适合本机编程（一如既往）以及在托管和非托管代码之间提供互操作层。
每种语言的语法都有细微差别，可以更容易地表达某些概念。即使它们都归结为 IL，但它们都归结为组装时与以前没有什么不同。无论编译到何种平台，您都可以选择语法最能支持您尝试执行的任务的语言。
语言差异仍然存在。将语言编译为汇编代码还是 MSIL 并没有真正的区别，只是 MSIL 的抽象级别可能高于汇编的抽象级别。
不过，.Net 的一大优势（这可能引发了这个问题）是，您可以在以语言 2 编写的库中使用语言 1 的目标代码，该库由以语言 3 编写的应用程序链接。
很久以前，在电力和汽车出现之前，你不能简单地在 Pascal 或 Delphi 应用程序中使用 C 生成的 .obj 文件（反之亦然）而不将它们显式包装在 DLL 中（并注意调用方法和参数序列和参数兼容性），或调用另一个可执行文件。
不，它没有框架的功能与语言功能不同。说 .Net 消除了语言之间的区别就像说汇编代码消除了语言之间的区别。
语言仍然有不同的特点，一些语言的语法更擅长解决一些问题，否则整个 .Net 框架会在单一语言上同质化。
如果有的话，我认为它可能加深了语言之间的区别，正是因为它们具有如此互操作性。现在的重点是语言。
相同的基础服务和基类可用这一事实意味着您可以根据语言提供的内容而不是与语言合作的框架提供的内容来对语言做出明智的决定。
例如，为了使用后期绑定的 COM，我可能（不情愿地）选择 VB（或者我可能等待 C# 4.0）。对于一些特定的财务/模拟工作，我可能会认真考虑 F#。对于常规业务编程，我完全的选择是 C#。
但是您可以根据适合不同块的语言进行这些选择，并从不同语言的不同 dll 中将完成的应用程序编织在一起。以前您可能不得不处理部分代码，因为您必须使用语言x才能使其与其余代码互操作。
我认为这实际上取决于提出问题的背景。
假设您正在开发一个供客户使用的库。CLSCompliant您使用属性标记此程序集。这意味着编译器将强制您使用 CLR 保证的功能，并且如果您使用特定于语言的功能则无法编译。
在考虑符合 CLS 的库时，.NET 消除了语言之间的区别。每种 .NET 语言都必须符合 CLS，因此您可以保证平等地支持每种 .NET 语言。
现在，假设您正在用 VB .NET 编写库，并且您决定使用可选参数而不是方法重载。在这种情况下，.NET 突出了语言之间的区别，因为可选参数不符合 CLS（尽管 C# 显然在 .NET 4.0 中支持它们。）对于使用不支持可选参数的语言的人，您的库可能是不可能或充其量难以使用。每种语言都有一些不符合 CLS 的功能，当使用这些功能时，您可能会使某些 .NET 语言的用户更难使用您的库。
所以，我觉得这是一个棘手的问题。如果您正在编写符合 CLS 的代码，那么 .NET 语言之间只有语法差异。如果您不是，那么您可能会编写某些 .NET 语言无法使用的方法。