Visual Basic .NET 5 blog post #497
Comments
and
These are both very broad and sweeping statements, with an air of finality to them. Will there be any exceptions at all to this? |
|
Additionally, while WinForms and WPF support in .NET 5, it continues to be painfully clear Microsoft has dropped the ball on cross-platform desktop development. If Microsoft selects a new UI framework that would finally enable cross-platform .NET applications, should we expect VB to be left behind? |
What's the meaning of "Future features" here? Will existing .NET Core 3.1 features, such as |
How does it play with your plans described here What if someone from community enhance VB, do you accept it, and release with VS ? |
|
@vbcodec That sounds like the C# team is more committed to VB than the VB team itself! |
|
@zspitz "evolve" implies we have a direction and are working toward that and "may not" implies that we might. So, I am not certain what you are asking. @ocdtrekkie We don't know what a cross platform UI will be based on. If it's based on Razor syntax, we have no plans to create a Razor engine. If it's based on something else, I don't know. @Nukepayload2 "What's the meaning of "Future features" here? Will existing .NET Core 3.1 features, such as ByRef-like structures, ByRef ReadOnly, Asycn Iterator Function, Nullable reference types and Default interface implementations be ported to VB in the future?" We have no plans to port these. We will continue to ensure VB users have overloads available in the BCL and in naming (the index constructors were named as a VB like approach to indexers). It is likely that third party vendors will be slow to demand these features as earlier versions of C# could not use them. @vbcodec Triage needed isn't plans. It indicates that the feature is in need of triage. |
This argument is similar to not supporting .NET Core when it first started. Look at the landscape now. |
|
@KathleenDollard Let me be clearer. Both statements (which I quoted from the blog post) are saying that Visual Basic will not change. My question is, how absolute is this position? Are there any circumstances which would force change on the language? |
|
Thank you to be finally clear about the future of Visual Basic at Microsoft. |
|
@KathleenDollard So the stance is that Visual Basic will stop having new features and go the way of Pascal? |
|
@zspitz One statement says Visual Basic will not evolve - we are not going to set a goal and go after it and we have no language changes planned. The second says we may not support all .NET Core features. Neither says there is no future where changes would occur in the language. At this point, we do not know what a future that inspired us to make language changes would look like. |
|
@Happypig375 I don't have a crystal ball. My personal opinion is that it is not a similar situation, primarily because in terms of experience in readability languages in general are asymptotically approaching what can be achieved and within the limitations of the platform (.NET) Visual Basic has arrived close to that state. |
|
I'm sorry Kathleen, but you're sounding like a politician with your responses to this. Both here and on the Visual Studio forum. Some of your answers are non-answers and others are a bit patronising. The lack of enthusiasm for Visual Basic from anyone with authority at Microsoft remains incredibly frustrating for those of us who appreciate the language and consider it superior to C#. Nothing I've seen since your 'announcement' has given me any confidence in the future of my development platform of choice. It looks to me that for Microsoft, VB.Net is now a 'legacy' product that they'd rather people stopped using. Although I'm sure the business has made the decision for commercial reasons that make sense to Microsoft management, I think this is incredibly short-sighted. They have done themselves a lot of harm by destroying goodwill built up over years amongst previously loyal supporters of their platforms, some of those supporters being decisions makers in large businesses. If Microsoft no longer wants to maintain or improve VB.Net, that's fine; it's their prerogative to do whatever they want with their product. But I think they are making a mistake. |
|
Thanks for sharing your personal opinion. I’m afraid your opinions have been disappointing for quite some time.
|
|
I don't mean to sound political and certainly not patronizing. But I am keenly aware that I can't tell you what you want to hear. And I'm not going to discuss the process to get to this decision. And I don't think my opinion matters (I regret sharing an opinion in relation to what I think was a poor comparison). There will be no further language development on any language in .NET Framework. There are few people using Visual Basic on .NET Core - mostly because we didn't support key platforms like WinForms. Now we will. This avoids closing a door on Visual Basic programmers that want to experiment with .NET Core and people with mixed language environments. And we got clarity where I think we've needed it. |
Really? Somehow I don't think further developing of the C# language will stop. |
|
C# 8 is not supported on .NET Framework. There will be no new versions of the C# language targeting .NET Framework. @KathleenDollard is absolutely correct on this point |
|
@jmarolf Doesn't read like that. Language Development <> Target Framework Why not simple state as of version of the insert language, will no be able to target .net framework. |
|
@AdamSpeight2008 This was announced some time ago.. C# 7.x supports .NET Framework. C# 8 and above do not. All future innovation at Microsoft is planned for .NET Core. This was all announced some time ago. |
|
My reactions are on my twitter account as some people don't like it when I do it here. |
|
@tverweij I wish you well in that endeavor. I am happy we are Open Source so you can improve based on feedback in this repo. If you are able to stretch what VB could be, @AnthonyDGreen's work is great. As you move toward release, be cautious with trademarks and branding. I would like you to avoid the wrath of Microsoft marketing. I can connect you with people if you have questions on that. |
|
@KathleenDollard While I understand you don't want to talk about the "process" that got MS to this decision, I think MS owes it to the VB.Net community (programmers, businesses, and government organizations) to explain what the motivation is behind this decision. In the big picture of MS, all of the costs associated with the VB language amount to pocket change... It seems completely irrational for a business to do something that's going to alienate and create a huge amount of ill will to such a large number of customers. Whatever "cost savings" they get will be absolutely nothing compared to the losses they will incur from programmers and businesses moving to non-Microsoft platforms because of this decision. |
|
@kathleen: I posted a message that I regretted within 5 minutes, so I removed it. And thank you very much! |
|
I ment @KathleenDollard instead of @kathleen - sorry. |
Are there any Visual Basic -like alternatives for .NET? I think all that would happen is these business would move to C#.
If I understand correctly, if someone starts a greenfield project today with a choice of .NET languages, they will probably choose C#, or perhaps F#. The customers of Visual Basic are in the main people and companies who already have projects written in VB; potentially the only major change they'll want to make is to move from Framework to Core, as long as it's a no-brainer. These customers don't feel that Microsoft has failed them, because they're not exactly champing at the bit to add new features to Visual Basic. And it's essential that the migration from Framework to Core be as smooth as possible, otherwise these clients will indeed feel alienated. That's how I read Microsoft's stance -- your current VB codebase will be usable on .NET Framework which will be available for a long time; we'll try to keep .NET Core as compatible as possible with .NET Framework, but no guarantees. |
Wouldn't changes to the language to improve C# interop be a compelling enough reason to update the VB Language (for .NET Core) - I like the approach that C# has taken by making C# 8.0 compatible with .NET Core/5.0/+ versions of the framework and not for .NET Full Framework. Couldn't VB take a similar approach? |
|
A few of us here just don't want to understand the message. |
|
It is a sad day. It was obvious since 2017, and this is why I kept shouting here: MS is killing VB! In this replay, I said:
If we can write other languages fragments in interpolated strings with a intillsense and compiler support, we will need no more improvements to VB.NET. We can just embed some C# chunks in VB.NET to borrow the new features directly inline. @KathleenDollard Could you please give VB.NET that honorable closure? |
|
@ zspitz
I'm the owner of a software business. If MS follows through on this policy, the alternative is to forget .Net and MS altogether. I suspect that, like myself, VB software companies\developers are sick and tired of being abandoned by MS. Yes, I can move my existing desktop applications to .Net Core. But in the long run that's a short term band-aid. VB.Net web applications are already not an option on .Net Core. The ability to write cross platform applications in VB.Net isn't going to be supported. To be competitive long term, I will have to rewrite my applications... and if I'm forced to do that, I can guarantee that it won't be in C#. It will be in a non-MS language that isn't dependent on .Net or MS SQL. When it comes to cloud hosting, do you think I'm going to use or recommend Azure? I'm just one of thousands. Will they all leave the MS stack? No, but many will. Do the math. It's a losing proposition for MS. And for what? To save a few pennies? Really? |
|
A small press kit for you. What the tech industry thinks of MS and the decision concerning vb.net. Spoiler alert: mockery and scorn. |
|
I saw this coming. |
|
This also can be a good closure: An Extensible VB.NET Compiler |
|
Dear @KathleenDollard If we are going to keep using VB, we have no choice but to eventually move to .Net 5 if we do not want our applications to become Legacy. You do not want to evolve VB? OK: Give us everything that was in VB up to VB 16.0 in .Net 5 so that you can achieve the stability you want going forward... Also, please talk to us: good or bad news, let us hear it so that we can make balanced decisions for our businesses and work...let us walk with our eyes open; not closed! We do not want to keep second guessing Microsoft's intention with regard to VB. |
|
In the blog post referenced in this issue, would it also be appropriate to include WinUI 3 (https://microsoft.github.io/microsoft-ui-xaml/) in the list of supported platforms starting with the release of .NET 5? I think mentioning it would affirm that Visual Basic can be used for producing “modern” Fluent applications for Windows 10-based devices. It states that Visual Basic is a supported language in the “Future of Windows development” section. |
|
@KathleenDollard Please share your response on this: https://anthonydgreen.net/2020/03/19/part-ii:-a-direct-response/ |
|
This is already a long thread but I wanted to add my simple two cents. The blog post is the current plan. Mike Tyson so beautifully misquoted the saying "Everybody has a plan until they get punched in the mouth." (no say that out loud while trying to mimic his voice - I don't care who you are, that's funny). Plans come and go. They change. They evolve. What I read in this post is that between now and the release of .NET 5... VB isn't seeing anything new to speak of. Watching the VB repo and the WinForms repo clearly show that there is a ton of work to do and it's a mountain of work to not only get finished, but to get right. And you know what? I'm OK with this. What happens after that... well... regardless of what that might be, thanks to the work done by the Roslyn team... nothing is ever truly final in the world of open source. ;-) |
This is true, in my region the decision on VB.net did not go well! Some are talking about leaving C # for other languages that have a bigger curve of existence in which ROI is not the definitive factor of continuity or non-continuity. Over here it grows every day aggressively is Python replacing C #. |
For new projects I also think that way! I will use a language that does not depend on ROI, today was VB.net and tomorrow it could also be C #. I already lost money believing in Microsoft when I bought 600 units of Nokia WindosPhone, today there is no more! Tired of being sad about Microsoft. |
|
In my opinion, to say that C# does everything that VB.Net does, is actually not correct. In my opinion, C# should get complete and full parity with VB.Net, not just 98% parity. But I also think that Microsoft should not discontinue support for VB.Net like they seem to want to do according to that blog post. |
|
@mdell-seradex You are correct, but you are only scratching a very, very, very tiny portion of the whole surface of what makes VB different. The reality is that (with the benefit of hindsight) as time has passed, the certainty and finality of the originally reference statements of concern in the original blog post have actually been proven false. Sure, I'm not saying that a great deal has changed with the language; but facts are facts and changes have been made. So, I stand by my original statement that plans are plans and plans do (and often) change. What hasn't changed is the stance that VB has "matured"; meaning that it is a lot harder to introduce new things and this was never news to me. I've been a part of some of these changes (in relatively insignificant ways) and know several others personally that have done significant groundwork (both on and off the team) in getting changes (new things) introduced. My observations (supported by several viral memes) of what is going on with the evolution of C# simply makes my head hurt. It is my opinion that many of the changes are being done simply for the sake of change... which I don't believe is good... but, again, that is just my opinion. To say this another way, it is my opinion that I'm witnessing what it must have been like to watch something like Perl evolve. Once can write clean, concise, very easy to read and understand code in Perl; on the other extreme of the spectrum though, one could write something in Perl that even the author that wrote it would have a hard time comprehending after taking a short nap. This doesn't mean that Perl is a bad language; but it certainly can promote some problematic code by developers who are "smarter than everyone else". Again, doesn't make it a bad language as there are things that you can do in Perl (for key scenarios) that can indeed be far more elegant than using nearly any other language. |
|
@DualBrain I have noticed some of this as well, but it does feel like the pace of changes to VB.Net still essentially makes the statement about no plans to evolve the language true. Regarding your statement about Perl, I would say the truth is that you can have the same problem in any language. A simple way would be if everything was obfuscated, but even just patterns that are employed to solve a problem, if not thought out, could end up being a completely tangled mess that is very difficult to read. I would love to see Microsoft a little more officially reverse their stance on VB.Net, and bring the best of new changes from C# into VB.Net. One thing that I have pondered is since everything actually compiles down to IL, couldn't Microsoft have made all the tools work with that instead of specific languages. I'd think if they had taken that approach, then they'd be language agnostic. |
|
In terms of parity, I would put it less regarding syntax constructs, and more about being able to create applications on the same platforms you can create UI's as well as you can create C# applications in them with using Visual Studio's Tools. For example, WinUI 3.0, Xamarin for mobile devices, and web interfaces with Blazor. Being able to use the XAML Designer with VB.NET for these platforms. A lot of times, a syntax parity may help in making this process easier. |
This is a multipronged set of problems; some of which are...
A relatively recent change is the introduction of Source Generators. When this first arrived on scene, I figured (incorrectly) that all hope was lost regarding existing code generation across the technology stacks. It turns out that many (if not most) of these are indeed being rewritten to utilize Source Generators. Using Source Generators, of course, isn't the silver bullet in and of itself though... it is necessary that the author of these generators actually leverages Roslyn to stitch together the code. Even if they do this, it may not be automatic that everything is as desired for multiple languages... but it does make it a lot easier for community members to provide small tweaks that could potentially be easier to accept. Unfortunately, I am aware of projects that are actively choosing not to leverage Roslyn to create the actual generated code (they are basically generating the code / manipulating the text directly) and I've gotten responses from some of the people on these teams "justifying" this choice. In my opinion there is no justification unless the code generation is absolutely intended for a very specific language choice. Even then, I'd argue that it's still probably a bad idea. In any case, there is hope as we see these code generators being rebuilt as Source Generators and (assuming they do) take advantage of Roslyn to stitch the output... even if the original authors don't support VB, it would be something that could be approached by those in the community. I think there is still more to be learned and ironed out in this space, but in the end I do still think there are reasons to be optimistic that things are changing. |
@sahil48 I was meaning less in regards to exact syntax, and more in regards to syntax concepts, one could say, like in the example I gave. In VB.Net, parameterized properties as actual properties. In C# they are not, which makes it harder to understand and code against. It is not important to me that the syntax of properties is the same. |
|
@DualBrain You are right that code/source generators can complicate things. Either way, I still hope that Microsoft will not leave VB.Net in the dust. |
We posted an announcement on Visual Basic on .NET Core on the Visual Basic blog today.
https://devblogs.microsoft.com/vbteam/visual-basic-support-planned-for-net-5-0/
I know it's been a long wait. I know it has been frustrating, I have shared much of that frustration.
The text was updated successfully, but these errors were encountered: