
The chronic suffering of the VB.NET community - myu701
https://anthonydgreen.net/2020/03/15/a-primer-on-why-the-chronic-suffering-of-the-vb-net-community-is-neither-necessary-nor-a-matter-of-expense-or-practicality/
======
smacktoward
As someone who was a VB developer back when VB.NET first shipped twenty years
ago, I'm kind of surprised by this. VB.NET was very clearly a second-class
citizen in the .NET ecosystem even back then. While Microsoft paid lip service
to supporting it equally with C#, it was very clear from the huge volume of
documentation, tutorials, books, etc. they put out for C# compared to the tiny
volume for VB.NET that C# was where they really wanted developers to be. And
syntactically VB.NET felt more like C#-with-training-wheels than "classic" VB
anyway, which reinforced the impression.

Given how big C# ended up becoming, I'm wondering why anyone committed to
staying in the .NET ecosystem would have stuck with VB.NET all this time.
What's the attraction? I could see it as a transitional stage to get classic
VB developers started on the road to C#, but as a long-term solution it seemed
doomed to chronic suffering from birth.

~~~
kogus
I think I must be the only person alive who actually prefers Pascal-style
syntax (VB, VB.NET, Delphi, PL/SQL) to C-style syntax. There are lots of small
nice things, such as distinct keywords for end blocks ("End Try", "End Loop",
"End If"), and syntactic sugar like the "With" keyword. Intellisense in Visual
Studio still seems to work better in VB.NET than C#. It does look
comparatively simple; but I'd prefer the complexity of my code to be mitigated
by the syntax, not exacerbated by it.

~~~
naavis
What makes distinct keywords for end blocks nice in your opinion? I feel they
are maybe overly verbose.

~~~
AndrewDucker
Harder to mismatch.

In C# the end to an if and a try both look the same. In VB they don't.

~~~
51Cards
This. I flip between both languages all the time and without issue but I have
to say in VB.Net I never have to go looking for that random missing brace that
is throwing the entire structure off. I spent enough time doing that in my
LISP days. :)

As for the complaints of something being verbose, I see people constantly
adding comments to close braces to indicate what it was they closed.

~~~
to11mtm
The Verboseness starts to get very real when you are dealing with inlined
Expressions/Functions. But maybe that's not what a normal VB.NET project has a
lot of.

And, for whatever it's worth, it can encourage people to not inline which
probably would be more maintainable anyway.

> As for the complaints of something being verbose, I see people constantly
> adding comments to close braces to indicate what it was they closed.

Lazy commenting. If you are for some reason dealing with code complex enough
to need to keep track of it like that, instead take the time to comment what's
happening next as a way to help the reader infer.

Because, let's face it, if it's complex enough to need to track those things,
there's a decent chance it's worth leaving some explanations of what it's
meant to do.

------
Someone1234
It likely takes 3-5 developers just to maintain what they already have until
end of life.

Whenever people come up with these tiny estimates for how much "effort" things
take they ignore the organizational overhead and maintenance costs. For
example, when changes are made to the CTS/CLS[0] a lot of time is spent
considering how those changes will impact other .Net languages, that's a
cost/overhead even without actual work on those languages.

So it might take "3-5 people to keep VB.Net alive" but only if you ignore the
man-hours lost in other teams (.Net Framework, Tooling, Libraries, etc) and
the people already required to maintain existing VB.Net Support (3-5~). 15-20
people is a more realistic conservative estimate.

Plus the language's popularity is almost gone:

[https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...](https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01dpgv,VB.net,C%23)

[0] [https://docs.microsoft.com/en-us/dotnet/standard/common-
type...](https://docs.microsoft.com/en-us/dotnet/standard/common-type-system)

~~~
phillipcarter
The author worked on the team for 8 years, including the transition to Roslyn
which unified much of the expensive concerns around VB.NET and C#. It's the
author's extremely strong familiarity with that engineering system that led to
their claim. In the post he walks through how team sizes grew significantly
smaller across the board. 15-20 people would be far larger than the current C#
language/compiler team.

------
nv-vn
One thing the author failed to consider when discussing F# was that F#'s
community leans heavily towards compiler/programming language people.
Historically, MLs have been extremely popular for writing compilers and a lot
of the folks using F# today either come from that background or have been
exposed to people from that background and learned about some aspects of
compilers. I would wager that maybe 25% of F# users are _capable_ of somehow
contributing to the F# compiler compared to maybe 5-10% for C# and VB.NET. I
also imagine the F# compiler's source code to be drastically smaller and
simpler given both its history and the ease of writing compilers in F#.

~~~
josteink
Edit: disregard

~~~
contextfree
The VB compiler is written in VB:
[https://github.com/dotnet/roslyn/tree/master/src/Compilers/V...](https://github.com/dotnet/roslyn/tree/master/src/Compilers/VisualBasic/Portable)

------
nxc18
I’d advocate for the opposite: VB is never going to get first class support.
It was clear that I should jump ship when first learning it back in 2010.

Microsoft should just kill it (aka put it into mature support) and give clear
guidance that developers should move on.

If you can learn and understand VB.NET you can learn and understand C#. It’s
time to rip the band aid off.

------
kstrauser
I worked for a shop that was heavily invested in Visual FoxPro, after that
time had come and gone. I spent a few years switching most stuff to Python and
PostgreSQL, then moved to another city. When I checked in with some friends
from there to say hi, I found out that they'd replaced all my "weird Python
stuff" with good, standard VB.Net (starting in 2013). I didn't know whether to
laugh or cry (with strong leanings toward the latter). It's too bad. I love
that company and the people there, but I'd like to smack the person who
convinced them to go for that particular rewrite, or at least make fun of them
in public.

~~~
eitland
The obvious choice for anyone who has tried a few languages should probably
have been C#, but personally, if it was my choice to make and the team was
experienced in Visual Foxpro I'd probably choose VB.Net if they wanted it.

The alternative would be C#.

Full disclosure:

Languages sorted by when I learned them:

\- Basic

\- Visual Basic

\- C

\- Assembly

\- Java (well, I "learned" that I was hopelessly ineffective with it. Still
got a B.)

\- Javascript

\- Python

\- PHP

\- AutoHotKey

\- Java (actually learned it)

\- Perl

\- Delphi

\- C#

\- VB.Net

Reasons:

Once I actually understood the value of a real typed language there's no way
I'll go back except for scripting and small one-offs.

~~~
kstrauser
Thing is, there was only one person there who was really maintaining the VFP
stuff. We'd already done the switch for everything else.

I agree about strongly typed languages. I'd never give Python and its strong
typing to switch to a scripting language.

------
manigandham
A decade too late. This is like complaining that Flash and ActiveX are gone.
The world has moved on. C# is easy enough to learn and unless there's
maintenance required on legacy code, it's irresponsible to continue using VB
on any new projects.

~~~
at-fates-hands
Just started working on RPA (Robotic Process Automation) and the tool we
primarily use is UIPath. Ironically it's built on VB.Net and requires VB
syntax if you want to do anything mildly complex.

Not sure why they went that route, but I've ran into several issues when using
REST services and other functionality that would be easy to get done in C#,
but are time consuming and painful with VB.NET.

~~~
vb6sp6
If you were going to train and support users that may not already be
programmers, it makes a lot of sense to use a language that is similar to
English.

------
mellosouls
"Chronic suffering" seems a wee bit hyperbolic, especially in the current
apocalyptic climate. Perspective, please.

OT I remember when VB.Net first came out and some VB6 devs were rather
sniffily referring to it as "Visual Fred" due to the lack of resemblance wth
VB beyond keywords.

It was obvious from the get go VB was now a second class citizen, and c# was
the future...

~~~
wvenable
VB.NET's only purpose _should_ have been 99% compatibility with VB6. Instead,
it was too much like C# to be compatible and too much like VB6 to be
consistent.

I had lot of experience with VB6 back in the day but I moved straight to C#.

------
60secz
> I am a PURE VB.NET developer. I have never used any other language full-time
> for any significant portion of my education or career—a client project here
> or there but nothing that somehow made me NOT a VB developer. How am I
> supposed to engage?"

Every developer should be polyglot. Adapt or die.

~~~
smacktoward
I dunno, there are plenty of slices of the programming world where you can
quite profitably work in a single language for most or even all of your
career. If you specialized in Java twenty years ago, you'd have skills that
are still in demand today and will likely still be in demand twenty years from
now (as long as you keep current with changes to the platform).

But betting your career on a single language is definitely a big bet. And any
bettor will tell you one of the key skills is knowing when to cut your losses.

~~~
balfirevic
It's fine to happen to develop (or only have developed) in a single language -
you might have found your niche and all that.

But the way the author of the article put it is just so weird - choosing the
word "pure" in all caps - like it's a point of pride, or big part of their
identity.

------
alkonaut
VB is dead. Get over it. It was a concession to an army of classic VB devs to
not risk losing them to other technology when .NET and C# were born.

Since then, every VB develooper has had _two decades_ to realize that VB.NET
never was a "new VB", but just a C# dialect. It offers zero value over C#, and
it's so closely related that anyone who knows VB.NET can pick up C# instead in
literally no time at all.

I don't see why the author brings up F#. F# is just as much a second class
citizen in the .NET world, but it is a project of a great community and of ms
research.

~~~
tomashubelbauer
> It offers zero value over C#

I loved VB .NET XML literals. Less relevant today with JSON all the things,
but I did choose VB .NET a few times over C# just because of these guys. Made
for amazingly readable (to me) XML wrangling code.

~~~
steverb
Used to occasionally import VB libraries into C# for that sort of thing. :-)

~~~
uk_programmer
A little known secret is that in the VB namespace in .NET full fat, there is a
really nice CSV file reader/writer.

[https://coding.abel.nu/2012/06/built-in-net-csv-
parser/](https://coding.abel.nu/2012/06/built-in-net-csv-parser/)

~~~
to11mtm
My colleague showed me this a couple weeks ago, which makes me laugh even more
when I think back to all the CSV parsers I saw in VB.NET in past gigs.

I'll admit, I'd written more than one in C# myself before I discovered
FileHelpers.

~~~
uk_programmer
I think I've written some CSV parsers until I thought to myself "I can't
believe they don't have this in .NET".

------
rufius
Why uhhh... why wouldn’t people just start writing new components in C#.
Surely learning C# is not beyond them?

It’s not like there’s a compatibility issue. Just stop writing it.

~~~
contextfree
what if they don't want to?

~~~
chrisseaton
Are they going to pay Microsoft enough to maintain VB.NET just for them?

Or they could re-implement and maintain VB.NET themselves?

Those are their options. You can't just demand that someone provide you a
product if they don't want to.

------
uk_programmer
VB gets a lot of hate. But the language is perfectly fine for the most part.
One of the most annoying things about VB.NET is that projects need to be
configured with certain options out of the box otherwise it allows you to
write some very sloppy code.

I still use VB.NET for creating quick tooling for either myself or non-
technical users. There doesn't appear to be anything else really these days
for doing that. The newer options from Microsoft tend to enforce a lot of
patterns, which just slow you down, when for small tools you don't really
require all that guff.

I hope with an open source .NET compiler it will be possible VB.NET to carry
on well beyond Microsoft's culling.

------
gus_massa
As a VBClasic user that never made the transition to VB#.NET, a wish you the
best but I loose my hopes a long time ago.

~~~
w3mmpp
Out of curiosity, do you develop professionally in VB classic?

~~~
foepys
I know somebody that does. It's working surprisingly well considering that it
has been deprecated since 2001.

Interop with C# is working fine and as long as don't have to do too much in
the VB part of your program, you can just use it as a "library" (which is
technically isn't because you should only call C# from VB, not the other way
around). The only two disadvantages I know of are restriction to 32-bit and no
easy CI/CD support. Maybe also that it doesn't support HiDPI forms and Windows
just scales it up but who is really expecting that from a 90s technology?

~~~
w3mmpp
Yes, and I guess it could also be ran into a VM with Windows 95-98 or that
other open source clone, can't remember the name now and still be useful.

~~~
jacobush
Wine + Linux and ReactOS would work equally well.

Wine would probably be easier to setup.

------
benjamoon
We're a .NET dev company (all C# coders, but most of us have a background in
VB as well), I asked my team if they had to choose would they rather have to
develop with:

A: C#, but with WebForms (including using code behind and the built in web
controls where possible).

or

B: VB, but with MVC and WebApi.

They all chose C# WebForms even though they all hate WebForms, just not as
much as they hate VB.

Personally I love VB and WebForms, I never get to do work with it nowadays
(I'm not even sure we have any legacy systems that still run it), but I built
my company from scratch off that stack and coming from a classic ASP
background I was blown away with controls like GridView and Repeaters etc. I
remember our first designer being so confused with the mess of html outputted
by these controls and the hatred our purists had for viewstate that polluted
their lightweight designs.

I still remember how excited I was when I first used the AjaxControlToolkit
and the UpdatePanel control, it was like magic!

Now everything's pretty much all C#, RazorPages, WebApi, Angular or Vue and
I'd never go back, but I do miss the old days. It's not often I see tech that
seems magical any more, SignalR was probably the last big thing that blew me
away in terms of just doing something that felt so different, but it's really
rare now.

I would add that we just finished a prototype app for a client using Blazor
WASM and coding that did seem like witchcraft and certainly brought back some
of the old feelings of being amazed, maybe we'll all look back on javascript
frameworks in the same way we look back on VB in a couple of years if Blazor
play outs.

------
asdfman123
They make the argument that it would take very little effort for MS to
maintain VB.NET.

If that's true, I wonder if part of the reason MS is killing VB is that it
doesn't serve any necessary purpose, and it is simply uncool. I wonder if
"uncoolness" is a primary factor.

It sounds silly to write, but think about it -- technologies live and die by
coolness. MS is doing everything they can right now to shake off their uncool
past, and VB is certainly a relic of the uncool past.

Developer share is crucial. You get a lot of developer share by being cool.
Thus, being cool is very important. Damn, _I_ want to drop a Medium article on
hackernews now with my hot new take.

------
ourmandave
My take away from this is either:

1\. Start a go-fund-me to get a VB.net team started.

2\. Start work on an open source VB.net to F# transpiler.

------
jbn
I don't even like VB, but this is a great read. Very informative. The author
clearly points out that the deficiencies of the organization that sign the
death warrant of VB.NET, regardless of the intrinsic value of that
language/compiler/environment.

------
greatjack613
As someone who started programming in VB.NET, this is so true.

It was a great language for beginners that also had enough oomph to build
commercial applications, everyone who I spoke to who actually used it loved
it.

Why a 1 trillion dollar company like microsoft can't hire 5 dedicated devs is
beyond me.

~~~
aliswe
That goes back to if the decision to assign them is strategic, or not. If they
wish to deprecate the language, it will not be done. Also one could argue that
that small code change which took 5 minutes could have cost the company
hundreds of hours supporting their clients if something happened. So that
would make that very small change a very big change, not based on effort but
on impact.

------
kelvin0
Imagine how the poor Fortan and Cobol devs feel.

~~~
vb6sp6
I imagine they feel pretty good considering the type of money they make

~~~
chrisseaton
Is there a lot of money in Fortran? Anyone could learn Fortran in a week if
they wanted, and there's tons of research assistants who know it already.
How's it lucrative?

