Update on VBLang

[KathleenDollard]

I wanted to share a few things with you.

• I hope you heard the announcement that Visual Basic.NET will be in .NET Core 3!!!
• @jcouv just posted the the Visual Basic language version history.
• We have started a conversation on guidelines for library authors on how to not exclude VB. Initial focus is the .NET Core framework libraries. (Example: provide overloads for span<T> overloads).
• There is ongoing improvements in Visual Studio and Roslyn, such as a stream of Analyzers and Code Fixes, IOperation, and of course bug fixes.
• We have reviewed a handful of issues. This work will appear to be on/off, because of working on these other issues that we consider larger and because there are a lot of vacations in the summer. But we still plan to do this.

I am happy to be "the face of VB", but I don't want this to obscure how many people in Microsoft see Visual Basic.NET as an important part of .NET. The .NET Core 3 decision was made higher in the org by folks that think Visual Basic.NET is part of .NET. I am not fighting to make any of these things happen - I hear about many of them when the GitHub notifications come across my email.

I know we have a boatload of problems. I am not diminishing them by sharing that Visual Basic. NET is part of .NET.

We think .NET Core 3 is an important developer workload for Visual Basic.NET. VB is great at WinForms. Preliminary work has also made us realize the shortcomings of VB on .NET Core. There has been a bit of mea culpa on this. Clearly there is a chicken and the egg problem - VB isn't VB on .NET Core today (missing parts of the VB runtime and non-strict/explicit scenarios) so people aren't submitting bugs because it's so bad they aren't working in it (tell me I'm wrong), unless they are writing a VB dialect of C# development (tell me if any of you are doing that). The test apps I wrote didn't illustrate the size of the problem.

I wanted to post this today to restate that Microsoft is committed to Visual Basic.NET and to ask a few things:

• Stick with us. I know we've fallen short of your expectations, and I hope we'll be able to clarify the Visual Basic.NET strategy to clarify how we will prioritize developer workloads in the short/mid term soon.
• Can the community take on updating the Visual Basic language version history? We'll move this into the docs when it doesn't look like we did nothing prior to 15.0. I'd like to get this up faster than we are likely to get to it, because @jcouv and others are writing code.
• Is there someone that can explore and update us on the Entity Framework code generation. EF was designed to have plug-in generation (so that it could support VB), but the community needs to create the templates. I know that work started at the MVP Summit, but there has been no action in that repo for 3 months.

I believe in Visual Basic.NET as an experience, much more than a language. I want us to work toward an Open Source embracing community that reflects that. You are important to the future of VB.

[ocdtrekkie]

I was super excited to see the .NET Core 3 news, and I will probably try to shift my VB projects over to it if possible. Though VB feels to me like it is primarily used in desktop apps, and whether you are using WinForms, WPF, and UWP, you are still tied to Windows. So far, my only .NET Core app I wrote with VB was a console app that I am pretty sure will work cross platform.

I do feel like the remaining "missing piece" in the .NET Core strategy, as a whole (but being particularly impactful on VB), is a cross-platform UI strategy. I've heard Avalonia suggested as a possibility, though I guess my preference would be if UWP was built-on to work on non-Windows platforms, so there was a master strategy for building .NET platform UI. Microsoft killing mobile and now going to React with both Skype and Office has left Microsoft's UI strategy very unclear.

[ocdtrekkie]

One thing I still think needs some sort of solution to start to build the VB "community", is a better solution for communicating what is going on with VB.

https://blogs.msdn.microsoft.com/vbteam/ is rarely updated, but some stuff shows up there from time to time.
https://blogs.msdn.microsoft.com/dotnet/ is more frequently updated, but has a lot of non-VB news, nuggets just kind of appear there.
https://github.com/dotnet/vblang/issues of course is where this post and the LDM notes and stuff appear, which is good too.
https://www.reddit.com/r/visualbasic/ is sometimes interesting to see what people are doing with VB, but often just homework help requests, often for VB6.
http://vbdotnetforums.com/ I've visited from time to time, but it literally has boards which haven't had a post since 2007, so it's hard to see the activity there.

If I'm doing something cool with VB (or at least, that I think is cool), where do I share it with other VB developers? If people want to keep an eye on VB development, where is the best place to do that? Where do I find out what other people are doing with VB? (These are the four things I did with VB recently-ish: https://blog.jacobweisz.com/making-visual-basic-cool-again/)

[gafter]

I suggest tapping https://en.wikipedia.org/wiki/Visual_Basic_.NET#Version_history for more information on version history.

[KathleenDollard]

@gafter Thanks!

[reduckted]

The .NET Core 3 decision was made higher in the org by folks that think Visual Basic.NET is part of .NET

That's good news 😄

I am happy to be "the face of VB" ... I hear about many of them when the GitHub notifications come across my email.

😕 If the "face of VB" is only hearing about decisions via GitHub, doesn't that mean that you're not being consulted in the decision making process? That's not exactly going to ease any concerns we have about the future of VB.NET.

We have started a conversation on guidelines for library authors on how to not exclude VB. Initial focus is the .NET Core framework libraries. (Example: provide overloads for span overloads).

Why put the burden on library authors to include VB? That might work for large libraries, or libraries created by Microsoft, but it's very unlikely to happen for small libraries that are created by third-parties. Wouldn't a better option be to actually support Span<T> in VB.NET?

but the community needs to create the templates

I really dislike this concept. If VB.NET is really going to be a part of the .NET family, why is this sort of stuff thrown over the fence to the community with little to no communication/documentation on how or when to do this? The EF Core stuff is a perfect example. As you say, it was designed with the ability to support VB, but at no point did I hear anyone actually saying that, nor did I hear anyone providing documentation on how to do it. As it stands, it's currently being prototyped by someone on the EF Core team (presumably in their spare time) because they're the only people with knowledge of what needs to be done.

[Berrysoft]

We have started a conversation on guidelines for library authors on how to not exclude VB. Initial focus is the .NET Core framework libraries. (Example: provide overloads for span overloads).

Why doesn't VB.NET support Span<T> and other ref structs? They are all important members in .NET Core.

...unless they are writing a VB dialect of C# development (tell me if any of you are doing that).

I used to write a C# dialect of VB development...but C# has more features than VB now. In other words, VB isn't a good dialect of C#, because of the lacking of some useful features, especially Span<T>.

[KathleenDollard]

@reduckted I don't understand your concern about improvements being made for VB, like analyzers without my involvement.

The EF template repo is on @bricelam 's repository because he wanted to make sure the community had access to a working location. Brice has been pretty clear that he doesn't know VB and can't do a good job of creating VB templates. He can answer questions, but I would not expect documentation.

[KathleenDollard]

@reduckted and @Berrysoft,

span<T> is a variation of how to do pointers. VB doesn't do pointers.

span<T> is the hot new kid in town, but it's designed for a narrow-ish set of scenarios and was created as runtime support for C#. It is being added to F# (community) but that isn't practical for VB. VB also doesn't support other pointer features like local refs or in parameters.

You will benefit from span<T> as it supports infrastructure.

Writing low level high performance infrastructure isn't a key scenario for VB.

[reduckted]

@KathleenDollard Maybe I misunderstood what you meant. You said:

The .NET Core 3 decision was made higher in the org by folks that think Visual Basic.NET is part of .NET. I am not fighting to make any of these things happen - I hear about many of them when the GitHub notifications come across my email.

I interpreted this to mean that you hear about a lot of VB.NET decisions via GitHub (not minor improvements and analyzers, but decisions on the actual direction of VB). That's why I thought it sounded like you weren't being consulted in those bigger decisions.

Brice has been pretty clear that he doesn't know VB and can't do a good job of creating VB templates. He can answer questions, but I would not expect documentation.

I think you missed my point here, but what you've said just re-enforces what I said. If the only person capable of creating VB.NET templates for EF Core can't actually write VB code, isn't that a problem? And if it's not possible to create documentation, how can the community be expected to create the templates instead of the Microsoft team doing it?

In short, for EF Core:

• It was designed to have plug-in generation (so that it could support VB)
• It seems that the only people with the knowledge to create the "plug-ins" for VB templates don't know how to write VB.
• There is no documentation that the community can use to create these "plug-ins".

Do you see where I'm coming from? If there's an expectation that "the community can do that for us" (which is far too often the case for VB), then surely the community should be given the resources (documentation, etc.) to be able to do it.

It is being added to F# (community) but that isn't practical for VB.

May I ask why it's not practical for VB? I'm not disagreeing with you, I'm just curious what the reason is.

writing a VB dialect of C# development (tell me if any of you are doing that)

I'm not 100% sure what you mean by this, but I think you're referring to writing C#-style code using VB.NET. If that's what you mean, then that's exactly what I do. I could write code in C#, but I prefer the VB.NET syntax, so I use VB.NET. I don't use VB.NET because it gives me things in the Microsoft.VisualBasic assembly/namespace - in fact I almost never use anything in that namespace.

[Berrysoft]

@KathleenDollard VB doesn't do pointers because pointers are "unsafe", but I think Span<T> is a safe way to manage pointers and improve performance.

I'm agree with @reduckted . I prefer VB.NET syntax and I need high performance too.

[benaadams]

I think VB understanding Span<T> and ref struct would be good; it doesn't need to use the pointer based overloads or be able to define them (which could be done in a C# lib if additional ones were required).

However I think there are two very important benefits Span<T> over arrays and strings would bring to VB:

Safer bounds: Slicing gives an enforced safe "data window"; that for example ArraySegment or a custom StringSegment can't provide as while they define the bounds (offset+length); the also must expose the full Array or string so anything you give ArraySegment to can happily access out of bounds. Span only lets you see its window over the data so the (offset+length) bounds are enforced.

Simpler unmodifiable arrays: ReadOnlySpan; omg arrays with read only elements! This has been a missing feature for .NET in general forever. If you wanted to enforce readonly when passing data; previously you'd have to create a new array then do a defensive copy it it. More complex, and also inefficient. It also allows api intent to be shown in the parameter. Passing an array is almost like a ByRef for an int as all its elements can be changed; passing a ReadOnlySpan is more like passing an int ByVal as the callee can't alter elements in a way that are reflected back into the caller.

The most benefit from ref struct (e.g. Span etc) would be VB being able to understand them and enforce the stack only nature.

Working out a syntax for defining them I think is less important as that would be more niche and creating a C# lib defining the type wouldn't be onerous to that niche.

[benaadams]

Also currently not understanding Span is problematic (string2/subString2 below)

[benaadams]

If anyone wants to take a look: TechEmpower/FrameworkBenchmarks#3905

I've added a VB.NET techempower ASP.NET Core entry for plaintext, json, and raw ado (fortunes, single query, multiple query, updates) for both postgres and mysql; using middleware. I haven't done ef as I'm not greatly familiar with it.

[Nukepayload2]

@KathleenDollard

writing a VB dialect of C# development (tell me if any of you are doing that)

I'm writing both C#-styled and VB original style code using VB.NET. When I'm writing applications, I use Option Strict Off, Option Explicit Off, Option Infer On and Option Compare Text to make sure my codes are easy to read. When writing class libraries, I use Option Strict On, Option Explicit On, Option Infer On, and Option Compare Binary for easier performance optimization.
I'll try every possible optimization tricks to ensure the hot paths of my codes are fast and powerful enough, regardless whether those tricks are unsafe.

I think both Span(Of T) and unmanaged should be supported.

1. I used to use IntPtr and System.Runtime.InteropServices.Marshal to avoid unnecessary heap memory copies when processing huge bitmap data. Because if the device copies all pixels from the back buffer to an array, the application may crash due to OutOfMemory. If Span(Of T) is supported, my existing unsafe code will be much safer.
2. I'm maintaining a parser written in VB.NET . It's slow because it always allocates small arrays (logically they are always smaller than 256 Bytes). So, I want to replace small arrays with stack allocated buffers without rewriting to c#. This optimization requires both Span(Of T) and unmanaged support.

[ericmutta]

@Berrysoft I prefer VB.NET syntax and I need high performance too.

I agree, and I think this raises a very important issue in language design that @KathleenDollard and team could think about as far as VB is concerned.

Imagine if someone created a new version of English, but instead of just indicating what words can be used (i.e the vocabulary) and rules about combining those words (i.e the grammar), they actually went further and started telling you what topics you were allowed to discuss or express in that language. That would be considered outrageous in human languages and a violation of free speech, but it is exactly what is happening when a certain concept/feature is added to one .NET language and omitted from another for reasons like "that language is more for X type of projects".

Can you imagine for example, if English was designed for talking about the weather and about football but if you wanted to talk about politics or biology you were told to go use French instead?

Going forward, I propose that as far as language design for .NET goes, we should begin by asking what idea/feature/concept is worth expressing and then having decided that, go ahead and provide a way to express that concept in all languages within an explicit time frame.

This Span<T> business is a good example. Some smart people sat down, deliberated and concluded that "this is an idea worth expressing". They then went ahead and added support for it in C# but not in VB, probably because "VB is not for performance sensitive projects"...all of which is fine until you get people like @Nukepayload2 who have the desire to express that idea in VB but can't.

In pursuit of the worthy ideal that is freedom of expression, I think a good rule of thumb is to say that if a feature is so important that it already has CLR-level support or requires CLR-level changes then it should be added to all languages.

[reduckted]

@ericmutta I think a good rule of thumb is to say that if a feature is so important that it already has CLR-level support or requires CLR-level changes then it should be added to all languages.

Agree 100%. It's the sensible thing to do.

@KathleenDollard, can you explain what you mean by "developer workloads" (as well as giving some examples)?

[jrmoreno1]

@KathleenDollard

I hope you heard the announcement that Visual Basic.NET will be in .NET Core 3!!!

Got a link to that? I haven't seen it. Unless you mean the statement that VB can be used to create desktop applications? If so, I'd question just how much that meant -- was any work done, or did it just work?

[KathleenDollard]

The announcement of .NET Core 3 is at .NET Core 3 and Support for Windows Desktop Applications

It's not surprising that there is a bit of confusion so early about a step as big as .NET Core 3 - what it means and why programmers will care.

.NET Core is a fundamental rethink of .NET 18 years later. The design reflects a world vastly different than the old one. .NET Framework (1.0-4.8 currently) has evolved in amazing ways, but fundamentals - it's single installation, performance related decisions, just on Windows, and a huge set of long standing API's that exist for backwards compatibility. This is great, but it's not a good foundation for a world of cross-platform demands and rapid evolution of platforms and frameworks. To focus on just one aspect: machine wide installation of .NET Framework means there is an very, very high bar for breaking changes - even across major versions and across millions of installations, even the smallest thing might break someone, somewhere.

Enter .NET Core - a new platform, framework and design based on everything that has gone before. You control how it is installed and roll-forward on production machines. This doesn't necessarily require app-local installation of the frameworks because you specify the roll-forward strategy among the many .NET Core Runtimes on the production machine. You get the stability and the modernization that makes sense for that particular .NET Core app.

And then there is performance, new APIs, cross platform, and all the other goodness that is .NET Core.

And, yes, my goodness, there is work to do. Anyone trying to do Visual Basic development on .NET Core today has encountered challenges. For example, the Visual Basic runtime is not complete on .NET Core. And we'll wade through it to determine how to restructure it so the Windows specific features are available on Windows without breaking cross platform. At present we believe in taking VB as VB onto .NET Core, so, although I am committed Option String/Explicit On developer, we anticipate taking these scenarios to .NET Core where they don't exist today.

.NET Core is where the future expansion of .NET will focus. Visual Basic being there is a big deal. The support of management to make sure it's there is a big deal.

And yes also, you will be able to do WinForms and WPF development on .NET Core 3, where Visual Basic's My and the direct event decorations are so very nice.

[Bill-McC]

Sometimes when travelling carrying to much luggage can hinder the journey, especially if it is luggage that is not used. I'd gladly trade Option Compare and Option Explicit, checking that baggage in a locker if it meant speeding up the journey. I'd want to take Infer with me. And I'd gladly leave Option Strict Off behind if I had a more explicit form of duck typing. If VBs baggage is slowing it down to these new platforms maybe it is worth leaving some of it behind Regards, Bill.

…

________________________________ From: Kathleen Dollard <notifications@github.com> Sent: Tuesday, July 10, 2018 2:36:07 AM To: dotnet/vblang Cc: Subscribed Subject: Re: [dotnet/vblang] Update on VBLang (#322) The announcement of .NET Core 3 is at .NET Core 3 and Support for Windows Desktop Applications<https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/> It's not surprising that there is a bit of confusion about a step as big as .NET Core 3 - what it means and why programmers will care. .NET Core is a fundamental rethink of .NET 18 years later. The design reflects a world vastly different than the old one. .NET Framework (1.0-4.8 currently) has evolved in amazing ways, but fundamentals - it's single installation, performance related decisions, just on Windows, and a huge set of long standing API's that exist for backwards compatibility. This is great, but it's not a good foundation for a world of cross-platform demands and rapid evolution of platforms and frameworks. To focus on just one aspect: machine wide installation of .NET Framework means there is an very, very high bar for breaking changes - even across major versions and across millions of installations, even the smallest thing might break someone, somewhere. Enter .NET Core - a new platform, framework and design based on everything that has gone before. You control how it is installed and roll-forward on production machines. This doesn't necessarily require app-local installation of the frameworks because you specify the roll-forward strategy among the many .NET Core Runtimes on the production machine. You get the stability and the modernization that makes sense for that particular .NET Core app. And then there is performance, new APIs, cross platform, and all the other goodness that is .NET Core. And, yes, my goodness, there is work to do. Anyone trying to do Visual Basic development on .NET Core today has encountered challenges. For example, the Visual Basic runtime is not complete on .NET Core. And we'll wade through it to determine how to restructure it so the Windows specific features are available on Windows without breaking cross platform. At present we believe in taking VB as VB onto .NET Core, so, although I am committed Option String/Explicit On developer, we anticipate taking these scenarios to .NET Core where they don't exist today. .NET Core is where the future expansion of .NET will focus. Visual Basic being there is a big deal. The support of management to make sure it's there is a big deal. And yes also, you will be able to do WinForms and WPF development on .NET Core 3, where Visual Basic's My and the direct event decorations are so very nice. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#322 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AID_hGVJctzHkUM8E87JQ3-4R3Cr5mK3ks5uE4Z3gaJpZM4U_pBK>.

[bandleader]

Brice has been pretty clear that he doesn't know VB and can't do a good job of creating VB templates. He can answer questions, but I would not expect documentation.

@KathleenDollard Not sure I understand -- is Microsoft unable to find the EF team a developer for hire who is proficient in VB?

[tverweij]

I kept following this group after I left (yes, I am Ghost), and still haven't seen any fixes or implementation of any of the requested functionality. And I think that is really a loss.
VB / VB.Net were both very good languages, but with VB.Net we lost the COM programming. And now VB.Net doesn't get the attention and support for new functions (including creation of templates) that it deserves. Advanced technology like unsafe won't ever be added to VB (this was made very clear). And new technologies won't all be available for VB.

That's why I left VB, after about 25 years. I gave up. I moved to Pascal (Oxygene), because it is almost as verbose as VB, but supports all that C# supports. Bugs are fixed within weeks (sometimes even days) - as it should have been with VB. Feature request are filtered and within a few weeks you know if it is going to be build or not - if it is going to be build, it is build within weeks.
I would never have left VB if this had been the case for VB. And I still hope that VB will be resurrected and be taken seriously again, including fast fixes and fast implementation of feature requests.
VB became a zombie language. @KathleenDollard: You are the only one who can change this. Get the support for VB back, to safe the language and bring it back to life.

This was my last message on VBLang. Hope that everything changes for VB.
Wish you all the best.

[ghost]

@KathleenDollard
I'm glad to hear these goog news, but I need some more info or a link about:

the announcement that Visual Basic.NET will be in .NET Core 3

thanks

[reduckted]

but I need some more info or a link about:

The a link a few comments above.

[bandleader]

@MohammadHamdyGhanem She posted it above: https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

That said, I didn't think there was much VB-specific in the announcement. It was more about WinForms, WPF, etc. (which I'm happy about, but are not what was being requested).

VB was already supported since .NET Core 2. The community's worries are not about VB getting into .NET Core, but 1) VB continuing to improve with features used in modern programming, and 2) tooling support for things like Razor, Blazor, EF, Xamarin, and of course project templates.

[jrmoreno1]

@KathleenDollard : The reason why I was questing the amount of work, was because they ported Paint.Net using just the binaries (without the source code), which makes it seem likely that VB as a language should work out of the box, That the only difficulties would be in missing dll's such as VisualBasic.dll...and I'm not sure that is covered by the announcement.

[ghost]

@bandleader @KathleenDollard
Until I can write Razor and Blazor and Xamarin codes with VB.NET, then VB.NET still didn't make it to .NET Core. Also, I wish WPF and UWP can work on systems aother than windows. It's not easy to megrate aps written with these techs to Xamarin forms. This is an essue even in C# not just VB.
MS can't fool me by big empty announcements!

[reduckted]

VB was already supported since .NET Core 2.

Yeah, it's a bit weird saying that VB will be in .NET Core 3 when VB was already in earlier versions. @KathleenDollard, can you explain what's so great about the news that "Visual Basic.NET will be in .NET Core 3". What does it actually mean for VB developers?

can you explain what you mean by "developer workloads" (as well as giving some examples)?

Also @KathleenDollard, any feedback from my previous comment?

[benaadams]

VB was already supported since .NET Core 2.

Yeah, it's a bit weird saying that VB will be in .NET Core 3 when VB was already in earlier versions.

Not completely: "Port remainder of Microsoft.VisualBasic" https://github.com/dotnet/corefx/issues/31181

[ocdtrekkie]

Between Microsoft.VisualBasic and WinForms support, .NET Core 3 will be the first time you could legitimately take a VB desktop app, as one conventionally might have, and change it to run on .NET Core.

Like, I wrote a thirty line console app with VB against .NET Core 2 once, but there was no way I could, say, move my home automation software to it.

[KathleenDollard]

What I say is, of course, a combination of my opinion and my role. Here is my opinion, not my role, not an official Microsoft opinion.

Visual Basic.NET in .NET Core is at best half-hearted and at worst an embarrassment. What is Visual Basic without the Visual Basic runtime (visualbasic.dll)? Who's used it and been happy? Who's used it in a production app? Actually serious question: Who's already used it in a non-trivial way and how did it go?

Back to me both opinion and role:

.NET Core 3 is a reset of the work on .NET Core. It is a big step from the perspective of .NET overall. Yes, it is a big deal that VB.NET is in .NET Core 3. It's fine if you took it for granted, because it is the right thing to do. But it is also significant work.

Visual Basic.NET is Open Source, like all three .NET languages. Visual Basic is behind the other languages in getting OSS right. It's still very early in .NET Core 3, but I hope this cycle will provide an opportunity to improve that. The focus from Microsoft will be on getting VB as it is today right on Core so you can port apps. VB has always been great at building desk top apps in WinForms and WPF, and focus will be on getting this experience right (for C# an VB).

@reduckted

What does it actually mean for VB developers?

It means they will be able to move apps to .NET Core 3, which is where Microsoft has announced it is focusing attention. Ask the reverse question: What would it mean if Microsoft had announced that VB wasn't going to be supported on .NET Core 3?

[KathleenDollard]

@reduckted

can you explain what you mean by "developer workloads" (as well as giving some examples)?

Sorry I missed this.

In one sense developer workloads are the selections you make in installing Visual Studio (regardless of whether you are using Visual Studio). In my use of the word I was extending this a bit. ASP.NET Core supports Visual Basic.NET. Razor does not. So I was using the word in a more granular way, the kind of work you're doing, a set of libraries and major experience. Scenarios might have been a better word, but I am not crazy about it because you often use multiple "workloads" together, such as a WinForm front end for a WebAPI, or EF usage with any other workload. Scenarios seem to me more like the meal you order while workloads are the "item from column A and item from column B" on the restaurant menu.

I meant a kind of work that you do in VB.NET. Examples of what I meant include (whether available in VB.NET or .NET Core):

WinForms
WPF
WebForms
WCF
Xamarin
WebAPI
MVC/Razor
EF
etc

[KathleenDollard]

@MohammadHamdyGhanem

Until I can write Razor and Blazor and Xamarin codes with VB.NET, then VB.NET still didn't make it to .NET Core. Also, I wish WPF and UWP can work on systems aother than windows. It's not easy to megrate aps written with these techs to Xamarin forms. This is an essue even in C# not just VB.
MS can't fool me by big empty announcements!

Why do you use the phrase "can't fool me?" What message did you hear that made you think that?

I think all this has been said. I think Microsoft, including me, has been transparent. If you have a question, I'll try to answer it. Things do change and evolve, so if something was said that you think needs clarification or feels wrong - let's talk about it without accusing anyone of trying to fool anyone.

As has been discussed: ASP.NET Core's version of Razor (and by implication Blazor) was designed for a single language due to very low adoption of vbhtml and much higher cost of a language agnostic engine. That decision, right or wrong, was made years ago. It is highly, highly unlikely that Razor will be rewritten to be multi-language. This is OSS, but there has been a clear warning that rewriting it is an enormous job, and due to the magnitude might not be incorporated. The guidance is to create your views in a separate dll that is in C#, or use a client side technology (that was in increasing popularity at the time the decision on single language was made). My personal opinion is that Razor is an OK but not brilliant generation engine, so if you are going to work that hard, build a better one.

I don't have experience with Xamarin in VB.NET, but I understand that Xamarin, but not Xamarin forms, works with VB. Xamarin has many pressing issues. It is unlikely that Xamarin forms in VB, or improvements to VB overall in Xamarin, are likely to become a focus for the Xamarin team. Part or all of that is OSS.

Is there anyone on the planet that doesn't want a real cross platform client side solution that is safe enough for enterprise, crosses platforms comfortably and is easy to program in? In the meantime, WinForms, WPF and UWP and XAML Islands will all be available in .NET Core 3 on Windows.

This is where we stand. Is it the best place we could be in? Of course not. Are people at Microsoft and elsewhere constantly trying to push beyond this, yes. But if Razor and Xamarin forms are a prerequisite, then VB.NET isn't the right language for you into the foreseeable future.

And nothing I said here has anything to do with the .NET Core 3 announcement. You may consider it empty if you don't care about WinForms and WPF on Windows, because that was a big focus of the announcement. But .NET Core 3 is far more than that. It is a reset of the basic architecture - you can run side by side copies of the framework. And it moves your code into the world that Microsoft plans to focus on. It should continue the trend of being faster (VB.NET is blazing fast as @benaadams 's TechEmpower benchmarks show, but not as blazing fast as C# if you just care about raw performance).

You may not care about any of that. OK, but it's not correct to say it's empty.

[ghost]

@KathleenDollard
In short: I will not be able to do any thing new with VB.NET. Just run on a nother in-progress new framework.
Lets focus on Razor:
I agree VB.NET doesn't fit in ASP.NET (Webforms and MVC) because of Java and HTML syntax.
I generally dislike both, and hoped for years to write ASP.NET with only VB code.
After webAssembly and Blazor, the opportunity represents itself: It is logical now to write XAML istead of HTML5 (differences are minimum) and VB.NET instead of Java script (the same way C# replaces Java now in Blazor).
I already asked for it (but from C# prospective) and there is already some project trying to do that. See replies in this issue:
https://github.com/aspnet/Blazor/issues/389
I think, VB.NET should do the same, and have a project to design ASP.NET pages with XAML and VB.NET code, making use of the work done in Blazor. If it starts now, it can grow steadily, instead waiting for Blazor and Ooui to stable and then say it will be expensive for VB.NET to catch up.
Thanks.

[reduckted]

Thanks for the info @KathleenDollard. 😄

I guess the .NET Core 3 announcement (with respect to VB) just seems a bit odd given that Microsoft has previously committed to VB.NET. Announcing that it will be supported in .NET Core 3 should really go without saying, and I think that's why some of us are a bit confused as to what it really means. After all, there wasn't any announcement that C# or F# will be supported in .NET Core 3 - it's just assumed that they will be. 😁

It's fine if you took it for granted, because it is the right thing to do. But it is also significant work.

This is where I'm a bit confused. What's the significant work to get VB.NET on .NET Core 3? If we take the Microsoft.VisualBasic.dll out of the equation (and maybe that's the bit you're referring to), is it really any different to C# or F# on .NET Core 3? After all, the compilers for each language just compile to IL, and it's the IL that runs cross-platform.

I just feel like I must be missing some key piece of the puzzle here. 😃

Now, to answer some of your questions...

What is Visual Basic without the Visual Basic runtime (visualbasic.dll)? Who's used it and been happy?

Me, and I'm very happy!

I know you were talking about .NET Core, but I'll include the full .NET Framework here as well.

With the full .NET Framework, I almost never use anything in Microsoft.VisualBasic.dll. I say "almost" because I occasionally need to use ControlChars to get things like the TAB character (something like this from #299 would be a nice solution to that problem).

The .NET Core experience is fine. ReSharper support for VB.NET seems to be lacking in .NET Core, but that's an issue for JetBrains (not sure if Microsoft have any influence over that).

Who's used it in a production app?

Also me (and the team I work with)! Again, this is all full .NET Framework though. The main applications are about six Windows services, plus two back-ends to web applications (with the front ends written in JavaScript). There's also a couple of command-line applications, class libraries for exposing APIs to customers, and a couple of simple WPF applications used for configuring things in the Windows services. All are currently using the full .NET Framework, and none have used anything in Microsoft.VisualBasic.dll (apart from things like ControlChars, as I mentioned above).

Regarding .NET Core, I'm in the process of moving the back-end of an in-development web application from Web API 2 to ASP.NET Core 2. It would have been in .NET Core from the start, but ASP.NET Core wasn't ready for VB at that point.

Actually serious question: Who's already used it in a non-trivial way and how did it go?

The services and web apps range from reading files and importing their data into a database (the files come from other third-party systems), through to full employee management systems, so they're definitely non-trivial.

At no point have we ever been hamstrung by using VB.NET. We've never had to say "if only we were using C# we could solve this problem". We (my team and I) are all comfortable working in VB.NET, but we can also work in C# if required (a requirement if you want to, for example, read source code on GitHub or in ILSpy) and we also work in JavaScript/TypeScript, so it's not like we're only capable of reading VB-style syntax.

But, more importantly, our clients are happy with our products - they don't care what .NET language is used!

Just this week I was hacking together some quick prototypes using ASP.NET Core in C# (due to the lack of project templates for VB). No dramas doing it, but moving back to VB.NET afterwards was refreshing. I don't know what it is, but the VB syntax just feels so much nicer to me. Which is odd, because I also love TypeScript. ¯\_(ツ)_/¯

[benaadams]

What's the significant work to get VB.NET on .NET Core 3?

There are at least 87 classes across 8 namespaces as tracked by https://github.com/dotnet/corefx/issues/31181

namespace Microsoft.VisualBasic
namespace Microsoft.VisualBasic.ApplicationServices
namespace Microsoft.VisualBasic.CompilerServices
namespace Microsoft.VisualBasic.Devices
namespace Microsoft.VisualBasic.FileIO
namespace Microsoft.VisualBasic.Logging
namespace Microsoft.VisualBasic.MyServices
namespace Microsoft.VisualBasic.MyServices.Internal

Also probably more

[pricerc]

This comment:

(VB.NET is blazing fast as @benaadams 's TechEmpower benchmarks show, but not as blazing fast as C# if you just care about raw performance)

Can you provide the links that support that?

It took me a while to find VB on the benchmarks - I had to go to the 'continuous benchmarking' page to find it @ https://www.techempower.com/benchmarks/#section=test&runid=f2e525b1-9d14-4bbd-922d-7c1ed28416f6.

When I filtered it down to show only benchmarks that include VB, I got to this:

and

which seem to indicate VB having an edge over C#.

for JSON serialization, single and multi query, there's nothing in it:

edit: only in PLAINTEXT does VB come in at barely a margin of error behind:

[benaadams]

The VB and C# for those particular implementations are within the margin of error and can switch around between runs.

What is being referred to is the platform level tests which you can't currently implement in VB; where there is more difference

[pricerc]

Is there language limitation that prevents them being implemented in VB, or just an absence of support for the language within the platform?

[benaadams]

Is there language limitation that prevents them being implemented in VB, or just an absence of support for the language within the platform?

Lack of support for Span<T> and inability to use ref struct types; so it can't directly implement the low level raw Kestrel apis IHttpRequestLineHandler, IHttpHeadersHandler

void OnHeader(Span<byte> name, Span<byte> value);
void OnStartLine(HttpMethod method, HttpVersion version, Span<byte> target, Span<byte> path, Span<byte> query, Span<byte> customMethod, bool pathEncoded);

Or use the BufferWriter type

public ref struct BufferWriter<T> where T : IBufferWriter<byte>

[bandleader]

@KathleenDollard I think we're all grateful that .NET Core 3 will add support for

1. Microsoft.VisualBasic.dll,
2. WinForms etc. (which isn't VB-specific, but useful)

...it's just that these aren't the huge pain points with VB (across all frameworks, not just .NET Core), which (as discussed at length in #251 are: 1) VB not getting new features, and 2) VB not supported for modern workloads (perhaps because of 1).

Therefore, when I heard the big announcement "I hope you heard the announcement that Visual Basic.NET will be in .NET Core 3!!!", it felt disingenuous because

1. the desktop stuff is not VB-specific,
2. it isn't a pain point anyway, as we were using the desktop framework for those things anyway,
3. the only VB-specific change (Microsoft.VisualBasic.dll support) isn't a big thing for me anyway, as I use the modern .NET-wide APIs for most things,
4. Microsoft.VisualBasic.dll wasn't even mentioned in the blog post nor in your announcement here, so I personally had no idea there was a VB-specific change at all.

I think that explains the disillusionment felt by those here, though I'm sure it wasn't intentional on your part (not to mention that you're in a very difficult position here).

Anyway, yes, please convey our thanks for Microsoft.VisualBasic.dll; I understand that it's non-trivial. I just personally wish that the effort had been spent elsewhere on VB instead.

I understand that MS has an interest in bringing .NET Core to the point where it can replace .NET Framework, so that they don't have to maintain two codebases. I guess we'll have to wait for the rest of it. But I just feel bad because through all of this they still find time for all the C# work and VB is left stagnant for so long already.

[ocdtrekkie]

@bandleader I would suggest if you're using VB but not heavily using Microsoft.VisualBasic.dll, you're probably the exception, rather than the rule. For me, this is huge, as I look to ensure my code has a future if VB ever goes away, just being able to see what it does, it being in open source code, is a Big Deal.

I would also point out that for many people, the My namespace is a huge part of VB, and for VB's 'intended audience', the My namespace is where a lot of potential improvement/new features might live. It being open makes it plausible for it to see some community contribution.

[ericmutta]

@KathleenDollard It is unlikely that Xamarin forms in VB, or improvements to VB overall in Xamarin, are likely to become a focus for the Xamarin team.

I really hope you can push for that to NOT be the case (i.e we SHOULD see improvements to VB support in the Xamarin context). From a simplified perspective Xamarin = cross-platform mobile development. Seeing how absolutely huge mobile is as a platform (over 2.5 BILLION smartphones in use), if VB remains a second-class citizen in Xamarin, it would be missing out on something very significant!

Now, as pointed out in #238, the situation isn't THAT bad. Thanks to portable libraries and .NET Standard 2.0 my current Android project is 99% VB and it works well enough. However some things are not optimal. For example, the debugger has a C#-oriented view of code, so when you step into the VB portions of an Android app, things look "strange". Little details such as these would be resolved if Microsoft (which owns Xamarin) decided that mobile was important enough that all it's languages would get first class support.

[zspitz]

@KathleenDollard

clarify the Visual Basic.NET strategy

Would it be accurate to say that VB.NET is more oriented to the "bus driver" programmer -- people who are focused on completing the immediate task at hand, without caring that there might be a more elegant / efficient / maintainable technique?

Would it also be accurate to say that the majority of VB.NET programmers is of this type?

---

Some background: I initially started programming .NET using C#, and I worked as a lab instructor in C#, which (I feel) gave me a deeper understanding of the language and .NET. For the last few years I've been working in a VB.NET shop (WPF, ASP.NET MVC, EF), The following are some comments I've heard over the years, which were rather disconcerting to me coming from a C# background:

• "Why do we need interfaces? You have to rewrite the same method over and over again."
• "What's the difference between making something a field or a property? In any case I'll call it with object.member?"
• "I'll write the check for Nothing later, if the code falls."
• "Since I can't enforce a contract on a Shared member, I'll create an overridable instance member in the base class, override in the derived class, and create a dummy instance when I want to invoke the overridden method,"
• "Why do we need namespaces? Everything can go into Public Functions / Subs ."
• "I never use type-checking; the syntax is too complicated to remember."
• "We don't use Async / Await; BackgroundWorker and Dispatcher.Invoke is enough."
• "If we need value tuples then we'll use them."

The common thread in all of these, is "I need to complete a task right now; don't bother me with new paradigms that I'm going to have to learn, understand, and then apply." It could be argued that this mindset is dangerously shortsighted and inefficient, or it could be argued that this mindset is practical to the extreme.

However, there are many features in VB.NET that reinforce this mindset, e.g.:

• Eschewing symbols, except for basic mathematical operators, which are understood universally (and not just among programmers); because it's easier to learn -- and be reminded of -- new paradigms using words, which are more explicit, than symbols.
• Case-insensitivity -- because case-sensitivity is another more advanced paradigm
• If x <> "" Then will check for both a ZLS and Nothing
• Blithe conversions between numeric strings and numeric data types

To a certain extent, all programmers are bus-driver programmers: the C# programmer can't be bothered to manage memory, the C++ programmer wants his data and behaviors bundled together in a single entity; the C programmer wants to use English instead of memory addresses; assembly programmers don't want to bother with butterflies or emacs.

However, I would suggest that what makes VB.NET unique is that the bus-driver programmer cannot be expected to learn new paradigms at all, even if introducing a new paradigm makes the code for a given task easier to write, less complex, simpler to reason about, or more maintainable, The fighter-pilot programmer -- the archetypal opposite of the bus-driver programmer -- is enthusiastic about his tools, reads the instruction manual from cover to cover, notices and investigates when new features have been added.

---

If the majority of VB.NET programmers is indeed of the bus-driver programmer type, then it's very difficult to know what they want -- they don't express their feelings strongly on GitHub, Twitter, Gitter, Slack, or any other communications channel. They may not even be able to articulate what they find wrong with the language; they'll just shoulder the burden and keep on their way. They may not even understand the benefits that a given new paradigm might bring.

OTOH, I think it's hard for the VB.NET power user to understand the bus-driver programmer's needs -- Whaddaya mean you don't need Span(Of T)? Why aren't you using .NET Core already? And EF Core? VB.NET doesn't support discards? Xamarin Forms?

By extension, the LDT has it even harder. Presumably, everyone on the team understands not just the precise paradigms that VB.NET is trying to express, but the internals of the compiler; and designing VB.NET features for the bus-driver programmer while holding this inside knowledge must be very difficult. Kudos to the custodians of VB.NET past and present, for staying this difficult course.

---

If I am correct in everything up to this point, I would suggest that fixing overcomplicated syntax ought to take higher priority over new features, because these are of more benefit to bus-driver programmers. For example:

• There are no less than four different ways to get something from one type to another
• Current type checking syntax is overly cumbersome (like If ValueOf x Is 5 Then) and sounds more limited than it actually is (in simple English, the TypeOf "abcd" Is not IEnumerable; it is String)

Also, I would suggest that features that solely improve clarity and readability by using natural language constructs should not wait for a similar C# implementation, because C# doesn't have the goal of approaching a natural language. These are areas where VB.NET can be the trendsetter instead,

[bandleader]

I don't think the "bus drivers" care one way or another; they were fine with VB6, and they're fine with any VB.NET as long as their code doesn't break and we don't take away On Error Resume Next 😄.

On the other hand, those of us who take programming seriously (i.e. adopt new features, understand modern programming concepts, use best practices, care about code safety and maintainability), are the ones trying to participate in the community because we care about the direction of VB, and want to continue to be able to use it in a world that demands these things.

I'm fine with all the "little fixes" you're suggesting to benefit our dear bus drivers, but they don't make a huge difference to anyone (the bus drivers are doing fine, aren't going anywhere, and most likely will never learn about the changes anyway).

---

As an aside, interesting that you chose the example of "a more clearer English syntax for type checking." As I've argued in #277, I don't think there is a problem here (except that people need to know what a type hierarchy is: b is absolutely an A). But more importantly, the natural place for the problem to be solved is within pattern matching, a feature baked into all the modern languages, and which C# has had since 7.0 (March 2017), whereas it's still dreamstuff here on vblang (#124) as far as any participation or even comments from the LDT.

---

Also, I take issue with the proposition that VB is reinforcing the bus driver mindset. Yeah, there's a lot of implicit type conversions that should never have been (though we're still way better than JS...); there's some legacy VB heritage that we're stuck with; we just try not to write such code.

But case-insensitivity, and using keywords instead of symbols? What has that got to do with bus drivers? It has to do with making the language more human (because humans read words and don't differentiate between cases), which was one of the original goals of BASIC, and is part of the VB till today (see my post here).

[KathleenDollard]

@zspitz I read your post a few days ago, but wanted to be thoughtful about answering. The knee-jerk was 'you are assuming an awful lot about all VB developers from a narrow set'. That is still part of my response, but I believe you posted in good faith and were not trolling. And I think about this a lot.

I don't like the phrase "bus driver programmers". I'm fine with your characterization, but let's for now call them "super-hero" programmers. They are more "focused on completing the immediate task at hand" and care less "that there might be a more elegant / efficient / maintainable technique?" I don't think they don't care, just care less. I think they use the best techniques available to them and most do learn, although it's not their main focus.

Super-hero programmers often leave a little chaos behind but the world/company is saved. I believe that there are more very old VB programs because they are effective.

There are lots of super-hero programmers working in both C# and VB today. They are the majority in both languages. If we combine the groups, and round a bit, there are about 3.3 million programmers each month. Of that 3.3M, those that are super-hero often chose VB in the early VB days because it was demonstrably more productive (don't throw things, C# didn't have IntelliSense or any real time compiler). C# has come a long way and generally matches VB productivity. I think this deserves celebration.

Of the 3.3M programmers that spend considerable effort to be "cutting-edge", they are more likely to program in C# because it is more productive to be cutting-edge in C# - most things will come to C# first. There are ten time as many developers, so I think its reasonable that it takes the lead. It has been frustrating to be a cutting-edge VB developer for a good number of years.

And some C# programmers are jerks about VB. Not most of them, and I do not have any respect for the behavior and little for the people, but I've been booed for VB and I know many VB programmer do not want to raise their hands in places like local user groups because people were think they were crappy coders. C# doesn't make you a better programmer and VB doesn't make you worse. In fact every VB cutting-edge programmer I ever met was ahead of his C# counterpart because he knew both languages.

We are very self selecting in our contacts in this industry and most of us don't realize it. Java has a huge presence and I know about half a dozen Java programmers, most from a single conference I go to just to mingle with Java heads. VB/C#, super-hero/cutting-edge are similar points of segregation.

The very fact you are here makes you a cutting edge programmer, and most of the interactions with C# people are going to be cutting edge. If you were to walk into a random C# shop, you may find the same kind of responses. I know that is hard to believe, but I've crossed enough boundaries in this industry to believe these are real.

Summary, there are more cutting-edge developers in C# than VB. There are more super-hero developers in C# than VB (there are more developers). But programmers with each approach program in each language.

Can I chat with you more about your experience going into this VB shop? My email is kdollard@microsoft.com.

[zspitz]

@bandleader

I'll adopt @KathleenDollard 's "superhero programmers" over "bus driver programmers"; it more accurately captures the characterization, without the negative connotations and implications.

I don't think the "bus drivers" care one way or another; they were fine with VB6, and they're fine with any VB.NET as long as their code doesn't break and we don't take away On Error Resume Next.

Once we define these programmers as "superhero programmers", who still care about proper programming techniques, but place less emphasis on these then on resolving the immediate issue, it becomes even more essential that the syntax be uncomplicated and not carry any incorrect implications. Either this will be the only exposure they will have to the paradigm expressed by this syntax; or when they finally have a chance for a deeper look at the paradigm, they will be hindered in understanding by the bad syntax.

I agree with you that such trivial fixes don't make a difference to cutting-edge programmers. I would argue even further, that the broader goal of making the language human is far less useful to cutting-edge programmers; since the cutting-edge programmer is deeply aware of the paradigms which the language aims to express, he only needs a syntax which vaguely suggests the paradigm.

The design of VB.NET also recognizes this:

• basic mathematical operations are represented using symbols and not words
• even though outside of programming = means equality, in VB.NET it also can mean "assign to"
• Pascal case keywords Make The language look Less human

Even more, I would suggest that on a theoretical level every humanization of the language comes at a cost. It is currently impossible to use natural language for programming; the closest we can get is something vaguely English-sounding. Without the goal of sounding like a natural language, programming language syntax has two goals when expressing the steps of a program / calculation (in no particular order):

1. The compiler can "understand" (i.e. parse) the steps, and
2. Humans can write, understand, and reason about them

Having a third goal -- to make the syntax as English-like as possible -- which 1) can never be fully met, 2) is frequently at odds with either of the other two, and 3) which cutting-edge programmers don't really need; I think potentially could add a lot of not-so-useful deadweight to the language.

Of course, for the super-hero programmer, who doesn't have this deep store of underlying paradigms to draw on, having an English-like syntax is essential, because he has no other way of keeping the syntax in mind.

---

As an aside, interesting that you chose the example of "a more clearer English syntax for type checking." As I've argued in #277, I don't think there is a problem here (except that people need to know what a type hierarchy is: b is absolutely an A).

My issue with the TypeOf x Is y is a perfect example of this. You know, and I know, and virtually every .NET cutting-edge programmer knows, that a given object's type can be compatible with multiple types -- currently either the exact same type or via inheritance, or interface implementation; and theoretically could include other type relationships. When a cutting-edge programmer sees this syntax, the exact wording is unimportant, as long as the syntax vaguely suggest in some way Is x type-compatible with the y type?. But if I specify in English:

If the type of this dog is the classification Animal, then

while the meaning can be contorted in all sorts of creative ways, the implication is that a dog has a single type -- the Dog classification -- and the plain meaning is that we're asking if the Dog classification is the same as the Animal classification, which it is not.

To answer, this isn't a problem, because people need to understand type inheritance is sidestepping the issue. Cutting-edge programmers don't need precision in the syntax because they already understand the rules of type compatibility; and superhero programmers may not know about inheritance, and will not properly learn type compatibility rules from their brief exposure to this syntax.

---

An example of an over-successful attempt to humanize a programming language which eventually collapsed under its own weight, Anders Heijlsberg was recently asked in a QA session, What is the most underused feature of C#? to which he replied LINQ keyword syntax.

I can confirm this from my own experience, both in C# and in VB.NET. When I first learned about LINQ keyword syntax, I thought it was an incredibly powerful idea. But eventually I simply stopped using it. What happened? I found that trying to remember the details of LINQ keyword syntax got in the way of what I was trying to express.

Even so, I think LINQ keyword syntax had -- and still has -- tremendous value, because it popularized functional approaches to data processing in imperative languages: before you'd have to write a series of nested control structures when processing data; now all you need are the appropriate calls to Select, Where, OrderBy, GroupBy etc.

I think that any humanization of the language should be approached in the same spirit: 1) give the superhero programmers a syntax which is for them more approachable, while 2) encouraging the cutting-edge programmer to advance to higher-level techniques.

---

To sum up, my hypothesis that most VB.NET programmers are super-hero programmers appears to be empirically invalid; and therefore my corollary that VB.NET encourages this kind of programmer has no statistical foundation. However, I think that VB.NET is strongly oriented to programmers who require syntax that both precisely expresses the meaning from a natural language perspective, and is easy to use (e.g. beginner- and super-hero-programmers); and that the effort put into such syntax will help these programmers advance their programming skills.

---

(Unrelated but,

the natural place for the problem to be solved is within pattern matching

I've proposed a syntax for pattern matching here and I'd appreciate your input.)

[zspitz]

@KathleenDollard

Your characterization of "super-hero programmers" is spot on., and much preferable to "bus driver programmers".

'you are assuming an awful lot about all VB developers from a narrow set'

I'll admit, it's quite possible that if I had learned VB.NET in an academic environment, and then gone to work in a C# shop, I might have made a similar assumption that C# encourages superhero programming (and written a lengthy post to that effect on the csharplang repo).

most do learn, although it's not their main focus.

My own experience bears this out. We've ended up using LINQ method syntax, reflection and custom attributes, loads of extension methods, expression tree rewriting -- all topics which are considered more advanced.

But I think the border between what is learned quickly and what is not, is if the technique brings immediate benefits or not, and if it's possible to do without or not. Processing data using LINQ method syntax has a visibly clearer code structure than a mess of nested For Each, Do While and If ... Then blocks Expression tree rewriting enable certain scenarios that would be impossible otherwise.

OTOH techniques like programming to interfaces instead of classes (the benefits of which are better decoupling between various components), or better code organization using namespaces, even though in the long run they ease maintenance, but they don't provide immediate, dramatic benefits; the superhero programmer may never learn these -- there is no burning fire that could be resolved by programming to interfaces.

I believe that there are more very old VB programs because they are effective.

Presumably you mean VB.NET here, and not VB6. (If not, it could be argued that the simpler programming model available in VB6 means that programming with it is less error-prone.)

In fact every VB cutting-edge programmer I ever met was ahead of his C# counterpart because he knew both languages.

Perhaps it's a reflection of knowing multiple languages that express similar paradigms, as much as simply being a cutting-edge VB.NET programmer. We'd have to look at cutting-edge VB.NET programmers who are unfamiliar with any other language. (I'm not sure we can find any such programmers; given the relative dearth of resources available to the cutting-edge VB.NET programmer, it seems to me almost inevitable that they will have to pick up some C#.)

---

The question I was trying to answer in my original post still remains: What proportion of development resources are devoted towards VB.NET answering the needs of beginner and superhero programmers, and what proportion towards answering the needs of cutting edge programmers?

Would I be correct in the following assumption: Since VB.NET aims to target more the beginner and superhero programmers (even though cutting-edge programmers are a statistically significant part of VB.NET's userbase) more resources are devoted to the needs of beginner / superhero programmers ?

[J0rgeSerran0]

Hi @KathleenDollard and all here.

Disclaimer: I don't know if is this the place to talk about naming/branding of "Visual Basic" for .NET Core 3, but I have not found another place, so apologies If I am wrong to write here.

In these comments I have read 70 times VB.NET.
One thing I saw in the past when .NET Framework went out is that a lot of Visual Basic people though that Visual Basic and Visual Basic.NET were different.
A lot of people in the Community (me too) tried to explain that the language was the same, but for a lot of people have been very difficult change this.
But it was an error committed by a lot of people around the world.
I have written books, articles, posts, and used VB.NET too in the past, but when I look back in retrospective I have learned that it was a big mistake committed by all us, so please, avoid to use "Visual Basic.NET" (again).

We have a new opportunity to fix our past errors with this.
Now we are talking about VB and .NET Core 3.0, we should not to use VB.NET.
The language is "Visual Basic", not "Visual Basic.NET".
.NET is implicit in .NET Core 3.0.

I don't know if you share my personal point of view with this, but in my opinion we should change the chip and talk and write about Visual Basic and forget Visual Basic.NET or VB.NET.

Kind regards.

[rskar-git]

@J0rgeSerran0

The language is "Visual Basic", not "Visual Basic.NET". .NET is implicit in .NET Core 3.0.

That is so very true, and yet... The reason a lot of Visual Basic people thought that "Visual Basic" and "Visual Basic.NET" were different is because, in the early 2000's, they were. Visual Basic.NET is a re-design of a ten year old language, with Visual Basic 6 being the end of the line of that original design.

However... Alas (and alack!), if one searched on "Visual Basic" using Bing or Google, both now (today!) display a blurb-block on the right about Visual Basic 6. ("vb" on Bing also shows VB6 blurb.) This despite the rebranding that happened about when Visual Studio 2005 was released.

Meanwhile, Visual Basic for Applications (VBA) never underwent any sort of re-invention; its syntax is more-or-less the same as VB6. A "VBA.NET" never materialized. VBA is still a standard feature of Microsoft Office, and remains frightfully popular among Excel and Access users.

Also, meanwhile, the old, deprecated, unsupported, no-longer-on-sale, VB6 clung on to life for a remarkably long time. Despite the overall wartiness of its language, it was nonetheless a revolutionary thing. Some VB6 tricks are applicable to VBA, and vice-versa; maybe VBA kept VB6 going?

Anyway, while the first generation of VB was warty, the latest VB is quite nice. The TIOBE index is suggesting an ever growing population of "super-heroes" and/or "bus drivers" picking it up. And yet... Most who program in Visual Basic on .NET (whether Core or Framework) find they must search on "C#" to get their answers. Searching on "vb.net" is only somewhat helpful. Evenso, despite nearly 20 years since the re-design, VB6 still manages to steal the spotlight.

So, for better or worse, it may be at least another decade before this "Visual Basic"-and-"Visual Basic.NET" is no longer a thing.

[J0rgeSerran0]

@rskar-git

Thanks a lot to share your points of view about this.

I am agree with your comments.
VB6 is alive for a lot companies around the world yet (for example, I share a personal experience with this. I'm living in Spain and an US company contact me some months ago to mantain and develop some apps in VB6).

Anyway, the summary of the last years is similar to:
The VbScript died with PowerShell.
ASP died with ASP.NET, PHP, JavaScript frameworks,...
FoxPro died with SQL Server and .NET (I worked in a migration from FoxPro to .NET with C# too)
However, VBA continues alive.
And VB6 too...
VB.NET sounds different for a lot of people yet.

There are a lot of developers using VBA and VB6 yet.

I have had meetings with a lot of people that were doing great things using VBA and VB6, but they were not developers... they worked very hard reading books and taking some mentoring courses, but they did not know anything about good practices, OOP, or other... so they wrote code smell.
They didn't want to learn anything new.
Is incredible, I know... but is real.
Most of them are not competitive today.

.NET is a standard and today, .NET Core is stronger than the old VB6, so when I want to talk about Visual Basic in a .NET Core context, I know that is Visual Basic for .NET.

Microsoft and the Community here are very relevant to pull in to those VB old developers, but to be honest it will be a very hard path.
We have to be sexy again and the name of Visual Basic.NET is not sexy and too long.

[rrvenki]

I'm programming in VB since 1.1 (1995) to date. First LInQ to Entity debug Visualizer (2009-11), Spell tolerant search in SQL server, MsgBox equivalent in Silverlight/WPF, etc are some of my free tools.
I wish to contribute to VB (B#) in some way. If there could be, please guide me for working in EF.Core, data comparison in various types, etc.