Visual Basic Community

[KathleenDollard]

I am all about community. As a community, we can improve the experience of Visual Basic programmers.

What does that mean to you?

How do we best do that?

[vbcodec]

@reduckted Maybe VB is promoted as open source, but current MS policy is to lock it to Windows platform, despite recent NET CORE investment (console apps and libraries).

[reduckted]

@vbcodec current MS policy is to lock it to Windows platform

And your source for this information is what?

[KathleenDollard]

There is no MS policy to lock Visual Basic to Windows platform.

[KathleenDollard]

To add to my previous comment.

There is no policy to lock Visual Basic to Windows platform.

But, our cross platform story on Visual Basic is lagging in a couple of areas, including Visual Studio Code and Xamarin forms support, and we do not have an active community which means things like preview usage an community experience is low.

[WolvenRA]

@KathleenDollard "and we do not have an active community"

I'm curious about exactly what you mean by that Kathleen? If you mean this Github "community" isn't very active, I would have to agree. On the other hand, how many VB developers (or language\compiler developers that appreciate the VB style syntax) are even aware that there IS a VB community??? I just happened to stumble across an article that made a random reference to the fact that VB had been made open source and that it was on GitHub.

Perhaps MS (or the people running the VB community) could do something that would let developers know that there IS a "community" and that it's looking for participation\support. I must admit I've been surprised by how few people post anything here considering there are "100's of thousands" of VB.net developers according to Mads Torgesen's blog post. I suspect that the reason is because 99.99% of those developers aren't aware that there is a "community" here.

[KathleenDollard]

My comment was regarding an active community doing cross platform work. I should have stated that more clearly just as there aren't a lot of people doing cross platform VB, and thus you rare a bit more bleeding edge there.

Since you were looking at the broader question I'm interested in finding where there is VB community and adding more of the right types of community. This community is not going to fill the needs of most VB developers - for example, its not a place to ask/answer questions. It's also not the place to develop VB community OSS add-ons (VBContrib on GitHub), or to have a real time conversation (Can someone fill in the Slack channel).

[rskar-git]

"...an active community doing cross platform work."

(It should be pointed out that VB-ish languages for cross-platform development have been and still are around. Xojo and B4J, for instance. There is also, of course, Mono for Linux - "Visual Basic.NET support in Mono is relatively new ... Visual Basic 8 compiler". But anyway...)

I think to encourage people's involvement here, this question in particular needs to be answered (or clarified): Is Visual Basic on an Intellectual Property footing comparable to that of C#? According to https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/en-us.aspx, "Visual Basic" is trademarked. While "Visual C#" is also trademarked - unless I completely misunderstand the situation - "C#" is not. According to https://opensource.com/law/10/8/can-programming-language-names-be-trademarks: "...when Microsoft filed its application for Visual C#, it disclaimed the 'exclusive right to use C# apart from the mark as shown.' Microsoft isn't claiming any exclusive rights to the name C#."

Furthermore, Visual Basic is not, nor is it based on, a "standard" computer language (whether ECMA, ISO, or whatever). In crystal-clear contrast, C# is. (It sort of had to be: .NET+C# was meant to be the obvious alternative to J2EE+Java. Per http://www.zdnet.com/article/what-is-ecma-and-why-microsoft-cares/: After submitting Java to ECMA for consideration for standardization, in December of 1999, Sun withdrew the submission, deciding to eschew standardization and, ostensibly, choosing not to lose control over Java as a result of the standardization process. As Microsoft marches C# into the marketplace, comparisons to Sun and Java are inescapable, so submitting the language to ECMA makes Microsoft look like a good industry citizen in contrast to Sun's now-you-see-it-now-you-don't Java gambit.)

Maybe Microsoft could allow "VB" to be a generic name (i.e. formally disclaim exclusive right to use, etc.), and while "Visual Basic" remains a trademark it's meaning can transition to mean Microsoft's implementation of VB? (Or if not VB, perhaps something else. B# anyone?) And also submit a standard for VB to ECMA? Such moves would profoundly signal to the public that VB is now freely a world language! I.e. really really non-proprietary.

From there, I'd bet the community would get active and vibrant!

Finally, I close with this from https://www.itworld.com/article/2795881/development/c---a-friendlier-tune-from-microsoft.html: "C++ programmers envy VB..."

[reduckted]

B# anyone?

Haha, I actually had the exact same thought a week or so ago when the topic of people hating VB simply because it's VB!

[Nukepayload2]

Why don't we do cross platform work primarily with VB.NET ? Because the lack of cross platform tooling support, such as Xamarin and Asp.net Core. If we develop our cross platform apps or websites with VB and tools that are not officially support VB, we will have bad experiences:

• Not all features are working correctly.
• When we are in trouble, we can't get any help unless we translate our code into C# and repost or edit the question.
• Proposals that related to VB support will be refuted or suspended.
• Our code may not work correctly after an update.

There's a deadlock that has been existing for years. We are waiting for MS to make sufficient cross platform tools for VB, and MS is waiting for a large VB cross platform development community. IMHO, this kind of deadlock will eventually destroy the product that is trapped in, just like Windows Phone and Windows 10 Mobile.

[WolvenRA]

@rskar-git Good post! While I hadn't really thought about it before, perhaps it's the truly "free" aspect of Python that accounts for its current popularity. Other than that, I don't see any reason it should be any more popular than VB.net. I think it's also interesting how many people still like VB6. While we gained some things with VB.net, we also lost somethings. I think it would be VERY helpful to add the things we lost back into VB.net.

My only point of disagreement would be with "B#"... A couple of wrong "impressions" that name generates for me are; 1. B comes before C (must be an "older", less sophisticated\capable language than C, C#, D, F#, etc.) 2. B stands for "Beginner" or "Basic" (i.e. again, less sophisticated\capable) 3. Strikes me as a #MeToo type vibe. As in; "We're Sharp too"

Unfortunately, I don't have any brilliant name suggestions at the moment. VB7? BFL? (Better\Beautiful F!@$%# Language) :)

[bandleader]

@KathleenDollard I'm starting to think that you're right, and the community might have to take up VB more than before. The reason I say this is that it appears that MS (and the Roslyn and ASP.NET teams in particular) are not willing to invest more into VB (read: language features and supported workloads), and while you may not be able to confirm that from an authoritative MS point of view, it seems to be the case -- in which case having the community taking up the slack might be the only realistic way to go.

Question 1) Would MS be supportive of such an initiative -- i.e. having people from the community send pull requests to bring VB up feature-wise closer to the level of C# -- i.e. adding language features into Roslyn, and creating templates for the ASP.NET Core workload, perhaps even making a VB-like Razor?

By "supportive," I mean 1) having the Roslyn team collaborate with us, i.e. being in real contact and helping us with the codebase and problems that arise, so that we can feel part of the team and work together on the VB side of things 2) actually accepting the pull requests to give VB the new features -- which opposes the formerly expressed MS position of "almost freezing VB so that new users don't get scared off by advanced features" -- which I am hoping was not serious

If you want to chat offline, please let me know (you have my email address).

[bandleader]

@AnthonyDGreen Would be happy to hear your thoughts on this matter as well.

And relatedly, would someone be able to continue your Roslyn Primer series? If people can easily understand the Roslyn codebase to the point where they can add features and send viable pull requests to MS, then VB has more hope for the future.

More ideas to discuss: 1) example Roslyn PR adding a simple feature 2) instructions for using a newly modified Roslyn within VS 3) perhaps making a big alert in the next version of VS that shows up when you open/create a VB project, that begs you to join the community here on Github...

[zspitz]

@bandleader But isn't any PR, no matter how valuable, going to have to pass the LDM? And the LDM is being very cautious in making changes. Also, the pace of change for VB.NET is not just limited factors relating to VB.NET, but also by the pace of change in C# -- if something isn't already fully spec'ed in C# (at the very least) it doesn't have a hope of being accepted in VB.NET.

[bandleader]

@zspitz Of course; let's say (for now) that we'll focus on adding features that are already being added to C# but MS is not investing in adding them to VB. Expression-bodied members and pattern matching come to mind. Of course the LDT has to approve the specific syntax used in VB, but perhaps they could be asked very nicely to give some attention to that -- #61 has been open for 1.5 years with no response from the LDT, whereas the C# feature already landed in C# 6 (exactly 3 years ago).

(Another interesting idea to float around: making it completely feasible to use your own fork of Roslyn in your projects. Actually I'd much prefer if Roslyn could be made extensible with plugins like Babel, but I understand that this is more difficult in typed, static languages.)

[jmarolf]

@bandleader there is not universal agreement that https://github.com/dotnet/vblang/issues/61 is a good idea. In fact I would argue the syntax is very non-VB-like. The onus is on the language proposal to convince the LDT to look at it. Pattern-matching and expression-bodied-members do not have VB designs that I would consider complete or implementable.

One thing I think is nearly spec'd out enough that it could be implemented for VB is Span and ref struct, things that I am slowly coming around to believing are needed. F# is working on getting span and ref struct support in. Based on the spec bugs they find there, we could look into what a VB implementation is like.

[jmarolf]

@bandleader

Actually I'd much prefer if Roslyn could be made extensible with plugins like Babel

Someone could do this in a fork, but the Roslyn team never wants to do this.

[bandleader]

@jmarolf there is not universal agreement that #61 is a good idea. In fact I would argue the syntax is very non-VB-like. The onus is on the language proposal to convince the LDT to look at it. Pattern-matching and expression-bodied-members do not have VB designs that I would consider complete or implementable.

Um, so far they haven't chimed in at all. Finding a good syntax is something that we can work on (I have my preference as I've detailed there), but they have to be willing to participate.

[craigajohnson]

@jmarolf regarding ByRef structures to support implementations like Span(Of T), this is an example of where VB is at risk since the co-authoring strategy was done away with. I would advocate strongly for inclusion. With the focus on allocation-friendly optimizations in tight loops low in the stack we can only expect the need for this to grow and I don't see any reason why C#, F#, and VB shouldn't be full participants.

Regarding expression-bodied members, this is a great convenience in C# and I've ended up using them frequently to reduce clutter. I feel a little shade of annoyance when I'm in VB and plop in the full property syntax for a simple one-liner. It also messes with my code golf game. Hopefully the team recognizes the value and would work from that premise to evaluate various syntax options.

[jmarolf]

@bandleader

they have to be willing to participate.

An LDT member does not need to comment on every proposal.

Below is not a direct response to your post. This is more some general background on open source language design that I've never posted before, so it seems prudent that I at least type it all out for us to continue this conversation.

Open source language design

No proposal is an island

Language design in open source is challenging and I am open to ways we could do better. In corefx if you want to add an API its fairly straightforward

1. Demonstrate a need for that feature
2. Show the basic design
3. Once you get approval, implement it and send in a PR

With language design there is an additional step that is between step 2 and 3 and it is:

2.5 Consider all language feature interactions with this new feature. 

Intentionally, if I write an new API it can't change other existing APIs. However, in a programming language there is no such isolation. Every feature must be considered with the matrix of all other existing features. This makes it very hard to reason about language feature proposals and this is the main thing the language design team does. The language design team is made up of people who either wrote the current VB compiler, wrote a previous version, or have been using VB for their entire careers and have a background in language theory. For this reason, even a very well written proposal does not reduce much of the work the LDT must do. Pattern matching for C# took hundreds of hours to design and there are still open questions that the C# LDT is working through. The effort it takes for a team member to accurately consider a proposal is such that they cannot do it for all 74 proposals in this repo. The current model is:

1. Someone submits a proposal
2. The community discusses and refines it
3. It is brought to a LDT members attention either because: 3a. It is something they are personally interested in 3b. The community demand is enough and the proposal is complete enough that is needs to be considered

We could do a lot better to make the 3b case more explicit as there is currently no process other than "This issue is getting a lot of traction we should talk about it" conversations happening in the hallways.

Visual basic is a hard language to design for

Internally people will often talk about "The spirit of the language" when they are justifying different approaches to a feature. The "spirit" of VB is something that is likely different for every person but there are some realities about VB that need to be acknowledged, mainly: is a hard language to design for. This is true for no other reason than VB places most of the cognitive burden on language designers over programmers. I think this is one of the great aspects of VB. Features in VB tend to be more do-what-I-mean. For example: VB type conversions. The rules around how the language does conversions is rather complex, but the intent is that the programmer never needs to stop and think "What is the compiler going to do here" instead they simply write the code that makes the most sense to them and then the compiler does what they expect. This is not something we do perfectly but its a really cool aspect of how VB is designed. The hope is that for most features "It just works:tm:". This means that some features that work well for C# of F# need to be more carefully considered for VB.

There are no take-backs

As with any programming language, once you introduce a feature it cannot be taken out or changed meaningfully (with very few exceptions). This leads the LDT to be very ok with not adding new features. There are many features that were ok or maybe even good but we decided not to do them. Some of these features were fully done from an implementation standpoint, but we pulled them because we couldn't convince ourselves that they needed to be in the language forever. VB.NET has existed for 15 years and our hope is that it exists for 15 years more (according to the Lindy effect it should be around for even longer). I can understand the desire for fast turnarounds on a lot of this stuff but there has never been a feature that took less than 3 years from initial design to implementation to shipping that I am aware of.

[cartermp]

Regarding spans/ref work in F#, for those who are curious, our spec is here. It may be interesting to folks, since F# is similar to VB in that it does not have a tradition of low-level programming like languages in the C-style family.

F# has had a few low-level programming features prior to this work, but they were aimed primarily at interoperation with other components. To make "byref-like" programming pleasant, a lot of work went into defining things from an F# perspective, so if you're comfortable with F# it may be worth reading through the spec and the alternative approaches that were considered. Our design process is quite different from C# and VB, so I don't know the extent of how useful reading it may be, but at least getting a feel for how to adopt a feature set that is not in the heritage of ML-style languages may be helpful.

[jmarolf]

@craigajohnson

ByRef structures to support implementations like Span(Of T)

I am coming around to this being necessary. Previously, the thinking was that VB needed to be able to consume Span<T> and ref struct APIs (which it can today). But creating custom spans and ref structs was thought of as analogous to pointers. In VB I don't see the need for native pointers as they are an escape hatch that normally indicates a need for a better language feature support in C#. In addition the base-class-library (or any other Microsoft maintained library that I am aware of) never exposes pointers as part of its API. With ASP.NET and others requiring Span<T> creation on implementors as indicated by @benaadams comment here it sounds like something we will need to do.

[jmarolf]

@craigajohnson

Regarding expression-bodied members, this is a great convenience in C# and I've ended up using them frequently to reduce clutter. I feel a little shade of annoyance when I'm in VB and plop in the full property syntax for a simple one-liner.

I agree that there is a problem worth solving here (being able to customize properties without much ceremony). But I remain unconvinced that the C# approach would work for VB. There are several concerns I personally have with the ergonomics of expression-bodied-members in C# and am not willing to foist those issues on VB users. I was hoping that some of the ideas in https://github.com/dotnet/vblang/issues/282 would prove a better solution.

---

As an aside: I am personally not very interested in language features that reduce typing. That is something that language tooling is in the business of improving. If customizing a properties behavior was almost no typing because of the IDE then I would consider the problem solved (and IDE changes are much faster to get in by an order of magnitude). Of course there is a subtle different between "clarity" and "reduces typing" so I can be convinced. "clarity" is also difficult in some respect though as it get conflated with "readability", something that is very subjective.

[benaadams]

@jmarolf I don't think it necessarily needs the ability to define them (syntax); but the VB compiler being able to understand them would be helpful. Extra ref structs could always be defined in C#, and then exposed via library.

At the moment you get the api obsolete exception; which is given when the compiler version doesn't understand Span<T>.

I think the need to define new ref struct types will be much lower in VB than C# where its probably already niche; however using them is different. As I said in https://github.com/dotnet/vblang/issues/322#issuecomment-402149382 I think Span(Of T) actually increases safety.

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.

[benaadams]

Previously, the thinking was that VB needed to be able to consume Span<T> and ref struct APIs (which it can today)

It could prior to the obsolete attribute being added; to prevent compilers that didn't enforce stack only-ness from allowing the wrong thing.

This is the main issue; that they can't be consumed/Newed

[jmarolf]

This is the main issue; that they can't be consumed/Newed

@benaadams in VB 15.5 they shouldn't be newable but can you give me an example of consumption failing?

[benaadams]

can you give me an example of consumption failing?

Imports Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http

Public Class ParsingAdapter
    Implements IHttpRequestLineHandler, IHttpHeadersHandler

    Public Sub OnHeader(ByVal name As Span(Of Byte), ByVal value As Span(Of Byte)) Implements IHttpHeadersHandler.OnHeader

    End Sub

    Public Sub OnStartLine(ByVal method As HttpMethod, ByVal version As HttpVersion, _
                           ByVal target As Span(Of Byte), ByVal path As Span(Of Byte), _
                           ByVal query As Span(Of Byte), ByVal customMethod As Span(Of Byte), _
                           ByVal pathEncoded As Boolean) Implements IHttpRequestLineHandler.OnStartLine
    End Sub
End Class

Error   BC30668 'Span(Of Byte)' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'.  
Error   BC30668 'Span(Of Byte)' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'.  
Error   BC30668 'Span(Of Byte)' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'.  
Error   BC30668 'Span(Of Byte)' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'.  
Error   BC30668 'Span(Of Byte)' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'.  
Error   BC30668 'Span(Of Byte)' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'.  

[jmarolf]

Thanks @benaadams I think we just need to fix the VB compiler to not error in this case. Logically we just want to prevent people from newing not referencing the type

ClassLibrary2.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <LangVersion>7.3</LangVersion>
  </PropertyGroup>
</Project>

using System;

namespace ClassLibrary2
{
    public class Class1
    {
        public A ConsumeRefStruct()
        {
            return new A(0);
        }
    }

    public ref struct A {
        public readonly int v;

        public A(int v) : this()
        {
            this.v = v;
        }
    }
}

ClassLibrary1.vbproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <RootNamespace>ClassLibrary1</RootNamespace>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <LangVersion>15.5</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\ClassLibrary2\ClassLibrary2.csproj" />
  </ItemGroup>
</Project>

Imports ClassLibrary2

Public Class Class1
    Sub MySub()
        Dim class1 = New ClassLibrary2.Class1
        Dim a = class1.ConsumeRefStruct()
        Dim v = a.v

        Dim a2 = New A(0) ' 'A' is obsolete: 'Types with embedded references are not supported in this version of your compiler.'
    End Sub
End Class

[jmarolf]

Looks like there are existing compiler bugs in this area: https://github.com/dotnet/roslyn/issues/28558

[benaadams]

Unable to consume C# 7.2 stack-only types in VB 15.5: https://github.com/dotnet/vblang/issues/297

[benaadams]

Logically we just want to prevent people from newing not referencing the type

New should be ok also? As you cannot create Span(Of T) with a pointer (stackalloc or native); so it would only be heap types (e.g. array, string, etc)

[craigajohnson]

I suppose we can eat the table scraps and at a minimum be able to consume these types. Aside from pointer logic, I see no reason why we shouldn't be able to enjoy VB syntax while also having the full power of all new types being included in .NET Core, which, at some point, would likely become part of the .NET Standard surface. We really run into 2nd-class citizen territory when we are told not everything in .NET Standard will be supported on account of our syntactic preference.

[jmarolf]

@benaadams I had some coffee and all the semantics about ref-like types paged in. Of course you can't have something like this work:

Public Sub OnHeader(ByVal name As Span(Of Byte), ByVal value As Span(Of Byte)) Implements IHttpHeadersHandler.OnHeader

its incredibly dangerous. If we didn't error and just let this happen then you could stash away name anywhere in your class without being warned of the dangers. To receive a ref-like type, the compiler needs to understand the interior pointer semantics and object lifetimes that are at play. Otherwise its like doing this:

Public Sub OnHeader(name As Byte*, value As Byte*) Implements IHttpHeadersHandler.OnHeader

The compiler needs know about the semantics.

[jmarolf]

@craigajohnson

not everything in .NET Standard will be supported on account of our syntactic preference.

Span<T> is not in any .NET Standard. It is only in .NET Core 2.1

[jmarolf]

@benaadams I would argue that ASP.NET Core should not have span only apis. @terrajobst was IHttpHeadersHandler approved to be span only?

[craigajohnson]

@jmarolf I thank you and I do understand; however, as per discussions elsewhere on what will be in and out of .NET Standard going forward there seems to be a high probability that useful innovations undertaken in .NET Core will find their way to future .NET Standard surfaces. This is especially important if those architecting various stacks (e.g., ASP.NET) are counting on such support. Otherwise, we are at risk of locking major value in the platform to a single implementation with a single language. This is antithetical to every single premise on which .NET is based.

[ericmutta]

@jmarolf ...there are some realities about VB that need to be acknowledged, mainly: is a hard language to design for...

This is very true and I sympathize with the LDT on that front. One thing that many of us may not think about is that VB existed as early as 1991. That's a full NINE YEARS before the appearance of C# and .NET as a platform. Much of that legacy was carried into VB.NET making the language much larger and more complex to design for. For example, Option Strict Off has a dramatic effect on what you can do and its interaction with new language features is something that has to be considered for VB but is not even an issue in C# (they started with a clean slate which makes design easier).

@jmarolf As with any programming language, once you introduce a feature it cannot be taken out or changed meaningfully (with very few exceptions). This leads the LDT to be very ok with not adding new features.

As cool as it is to have new features, I personally SUPPORT this cautious wait-and-see stance for VB as a programming language. If we assume there's a theoritically optimal version of VB which has just the right combination of features for all major scenarios, then I dare say the current version of VB is about 98% of the way there. All the big stuff (e.g generics, object-oriented programming) is already in place and much of what remains (whatever it may be) probably falls into the "nice to have but not game changing" category. So as someone who has used VB for 20+ years, I am also very ok with not adding new features to the programming language itself.

However, we should be very ok with adding new features outside the programming language in the area of tools and platforms support. For example, take VB exactly as it is and support it in Xamarin (which I personally work with heavily). Right now C# gets a positive vibe because it gets both new language features AND first class support for new platforms. Quoting @AnthonyDGreen from Digging Deeper into the Visual Basic Language Strategy:

But with regard to the cloud and mobile, development beyond Visual Studio on Windows and for non-Windows platforms, and bleeding edge technologies we are leading with C#

So, we know where C# is taking leadership, which leaves an interesting question: in what areas and in what manner will VB take leadership and set the standard to delight those currently invested in VB and entice those who are not currently using VB?

[craigajohnson]

@cartermp regarding the F# spec, yes, the value propositions on which this considerable effort was based apply to VB in its entirety. Congratulations to the team for working through some gnarly changes. I see the implementation is already basically done. Now with 2 languages providing support let's move forward with VB.

[craigajohnson]

@ericmutta we also use Xamarin heavily and intend to use it even more. A large majority of our Xamarin projects are indeed VB (with .NET Standard 2.0 and all of the libraries that now support it being a huge benefit!) As mentioned a gazillion times on this forum, Xamarin/VB would be a natural fit. The unanswered question I've had for over a year now is what exactly is holding back a VB integration? I know there is a lot of codegen with Xamarin and we also know that Miguel and others are C# proponents. It would be helpful to know both the cultural and technical barriers to getting an integration done.

[benaadams]

The compiler needs know about the semantics.

Completely agreed.

However, if/when the compiler understands the semantics; new isn't a problem as from VB you can only call new using an array or string.

I would argue that ASP.NET Core should not have span only apis.

The regular ASP.NET apis don't have Span only apis; this is the low-level apis that provide parsed windows over the input socket's data and provide it with zero copy; which is why it is also the fastest TechEmpower implementation. To provide a non-Span version you both have to allocate and additionally copy.

This api is also in the a pubternal namespace "Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http"

I don't think particularly may people will use the apis at this level even via C#; as you jettison most of the ASP.NET Core stack at this level.

However; performance and using these Kestrel that isn't why I think VB should be able to consume Span and ReadOnlySpan.

Its for the safer windows over data; as ArraySegment which is a previous incarnation allows you to read anywhere from the aray, beyond Offset and Count; whereas Span locks you so only be able to read the data window specifed and doesn't allow reads outside that area. Also ReadOnlySpan forces the array elements to be readonly; so it communicates intent; in addition to the constrained window. Passing an array is always read/write; which is problematic.

Span and ReadOnlySpan are safer apis.

[ericmutta]

@craigajohnson we also use Xamarin heavily and intend to use it even more

Glad to see I am not the only one! It is an amazing piece of tech (and Microsoft seems to think so, they bought the whole thing!) :smiley:

@craigajohnson The unanswered question I've had for over a year now is what exactly is holding back a VB integration? I know there is a lot of codegen with Xamarin and we also know that Miguel and others are C# proponents.

I think the main disadvantage facing VB here has to do with cultural heritage. The type of people who work on compilers, language frameworks and virtual machines have traditionally done so in C/C++ for decades. It is completely natural and expected that they would later have a preference for C# when it emerged. Seeing as it is already a lot of work to implement something for just one language, I can see why they start with C# and leave VB in the "maybe later" category. It is understandable but not much fun for us in the VB camp!

Barring an executive order from above, to the tune of "thou shalt support VB everywhere C# is supported", we are likely to continue seeing what we are seeing now (C# getting the good stuff first).

On a positive note, the open-source angle does at least make a community effort possible in theory (though in practice it would need an explicit decision from Microsoft to invest effort in supporting community-led developments, perhaps through "Here Is How It Works" videos which give an instructional account of how something like Xamarin works for C# so someone could replicate it for VB and F#).

[craigajohnson]

@benaadams thank you. From various presentations at Build and from your own commitment to squeezing every last drop of performance, these concepts simply represent sound engineering practices that shouldn't be the exclusive purview of a particular managed language. For instance, the elegance of F# and the protection of immutability for concurrency in many scenarios seemed to have come at the cost of excessive allocations. However, we are seeing optimization claw-backs as of late. If certain primitives in the languages ease the path for bounds protection/reducing allocations/etc., then I would strongly advocate for their inclusion across the board. I also think that abstractions grow in strength when multiple implementations are thrown at them. I basically use VB as I would C#, and it is enjoyable to see how the VB language designers have distilled core concepts into the natural/readable syntax we love about VB, all while emitting reasonably similar or identical IL and giving up nothing from a perf perspective. I can peruse a VB source tree with rapid speed because it openly declares its intent, allowing me to focus on the particulars of the problem being solved. I did this with your VB port of the TechEmpower tests and it all makes perfect sense. I'm curious enough to VB-ify it a bit and compare perf.

So yes, the current conversation with Span/Memory/etc. is one of those areas of concern that someone, somewhere who decrees that a VB developer just isn't or shouldn't be interested in these concepts can create some real trouble for those of us who appreciate staying current. It shouldn't be a question.

Thank you all the same for your interest in VB.

[VBAndCs]

This is my answer: https://github.com/dotnet/vblang/issues/445

[Berrysoft]

@jmarolf

Span<T> is not in any .NET Standard. It is only in .NET Core 2.1

Now Span<T> is in .NET Standard 2.1.

[jmarolf]

@Berrysoft yep. Currently only .NET Core implements .NET Standard 2.1 :) but its becoming clear that by-ref-semantics are a thing that all .NET languages need to know about. VB unfortunately is more complex than F# in this scenario as we need to think about VBs unique binding semantics.

[ericmutta]

@jmarolf VB unfortunately is more complex than F# in this scenario as we need to think about VBs unique binding semantics.

VB does indeed have a much larger surface area than the x# languages which makes it incredibly flexible and also much harder to evolve. It has been nearly 20 years since the last round of weeping and gnashing of teeth that occurred during the jump from VB6 to .NET.

Perhaps now is a good time to take inventory of what is actually used out there and then dump the baggage so VB can evolve faster?

Maybe we need a faster moving "VB.Core" which, like .NET Core, is going to focus on innovation while VB .NET Classic gets the same treatment as the classic .NET Framework where the focus is on stability and compatability.

Whatever terminology is ultimately used, the bottom line is that VB needs a language evolution strategy that doesn't sacrifice innovation at the altar of compatability.

Without innovation, things stagnate, people lose interest and eventually the language will just die in obscurity (which would really suck because VB is pretty awesome!).

[Berrysoft]

@jmarolf

VB unfortunately is more complex than F# in this scenario as we need to think about VBs unique binding semantics.

Maybe it is complex to think how to author a ref struct, but it is very simple to think how to use Span(Of T) - the compiler should just ignore the ObsoleteAttribute.

[Nukepayload2]

@Berrysoft No, the VB compiler should also diagnosis the unsafe use of ref struct and ref readonly. And it needs to provide reasonable tooltips for ref struct and ref readonly.

[jmarolf]

@Berrysoft

the compiler should just ignore the ObsoleteAttribute.

That would be extremely dangerous. Span has special pointer semantics, ignoring them means all span code in VB becomes unsafe

[Berrysoft]

@jmarolf Not exactly. VB doesn't support pointers, therefore span code in VB is still safe.

Actually you can now use Span in VB like this:

Dim s = "Hello world!"
Dim span = s.AsSpan() ' If you don't write the type explicitly, the compiler won't error.
' Use span however you like

[benaadams]

the compiler should just ignore the ObsoleteAttribute.

That would be extremely dangerous. Span has special pointer semantics, ignoring them means all span code in VB becomes unsafe

I'd go with "stack only" semantics; that it might can also over pointer data is a detail that isn't useful to expose to VB. However ignoring the "stack only"-ness would risk allowing invalid programs.