The chronic suffering of the VB.NET community | Hacker News Reader

The chronic suffering of the VB.NET community

anthonydgreen.net

118 pointsmyu70195 comments

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.

I remember this slightly differently; the change to C# was swift and rather brutal, but VB.Net was very much the default choice for most organisations transitioning from VB. In 2001-2002, seeing C# in production eluded a response along the lines of "wow, you guys are quite brave, kudos". By 2003-2004 though, the switchover had pretty much happened, nevertheless there were still swathes of legacy code to be maintained. At least, this was my experience in the handful of companies I worked with around then.

I've seen several moderately large and active projects (5+ developer maintenance team) still surviving to this day, running on VB.Net. In most cases though, these were started in the mid-2000s, simply due to manpower questions, not language advantages. I recall being moderately surprised even circa 2008 that the author of CSLA.Net (an interesting object-oriented framework) was mostly using VB.Net. I guess from their point of view, they were more proficient in that languages, and the cost of switching was too high. I definitely don't see any rationale for benefits, akin to say F# vs C#.

That is how it was for my shop too but honestly I think the semantics of VB.NET was always closer to C# than it was to VB 6. I remember working on a mixed code-base and it was absolutely effort-less because the semantics and of course the libraries were all identical, you just had to switch syntax. Syntax isn't really what takes time to learn in coming up to speed in a new language; what takes more time is language concepts, semantics, APIs and tooling. Once you realize this and observe the fact that C# is winning mind-share there didn't really seem to be any need for VB.NET. It really seems to me like it should have been stopped entirely ~2006 but Microsoft just doesn't do that to products, to their credit in most cases.

Yes, I completely agree. Syntax can be a stumbling block for beginners, but is generally far easier to re-learn than core libraries, or semantics, etc. That said, the syntax shift from a basic-like language to a C-like language is slightly larger than what we are generally used to, within the C-like families. I recently had to work on some VB.Net code, and aside from the occasional "let me Google this quickly" moment for surprisingly basic concepts, it was a breeze for the reasons you mentioned.

I think the MS world of the time was very much a monoculture (and would be until circa 2010 or so), which lead to a lot of developers who had only ever really worked in one main language (plus maybe SQL / T-SQL). I tend to think this is quite similar to children growing up in a single-language vs multi-language environment. The patterns tend to get ingrained in your brain in the former, and there are few signals for our brain to understand that "this concept can actually vary from language to language, don't get too used to it", making later shifts much more difficult. It's kind of a case of over-fitting the data, which is the first language they learned, in this case. I think a lot of the VB and then VB.Net developers had this kind of strong mono-culture of language, which compounded the need to keep VB.Net alive for longer. This may have been further compounded by VB's image as a beginner-friendly language, which a lot of people took up to get into the industry as outsiders, without any formal or informal experience. I really do think this might be the main factor. VB.Net may have had a few tiny advantages in terms of semantics (slightly looser casting and conversion rules), syntax clarity ("static" vs "Shared" - an example of a keyword which is objectively clearer in VB, IMHO), or some convenience libraries (I recall occasionally having to reference core .VisualBasic assemblies to get hold of some helper method which was missing on the C# side, for no apparent reason). But it also had just as many detractors, and I would not think any of these were nearly enough to lead to people choosing it over C#.

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.

I've had to deal with a codebase that's part VB.Net and part C# for the last 6 years.

I don't really feel any pain switching between them, apart from VB.net is a bit annoyingly verbose and I always forget how to do linq lambda functions in it.

One tip I would add is that you can change the colour of the matching {} when you're in a block scope. VS actually highlights the opening and closing of the block. Usually not much of a problem due to auto-indenting, it can help a lot with complex code.

For some idiotic reason the default is a very light grey, but if you make it darker or a different colour, picking out ending } or starting { becomes trivial.

You should try https://viasfora.com/

You're not the only one.

Ada is a lot like this too. I can read, compile and run it in my head during a gerrit review with almost no glitch by now. Written once, read 20 times at least.

There was some talk on HN yesterday about making your code easily changeable. First step is to make it easily readable, understandable. Little things help. End loop helps. Exit loop_name helps. Non-fallthrough case statement help. in / out / in out help so much. Pre and post conditions help also. Clear static types help. Internal functions help. Explicit generic instantiation, while a pita to write, helps a lot at code read time... Lots of lead bullets.

As someone with a passion for programming language design, this is very intriguing indeed. I wonder if a more verbose and explicit language is indeed better...

AppleScript pairs a concise writing syntax with a verbose reading syntax. The writable->readable translation is done automatically on save - think first-class clang-format.

As a simple example you can write an if block with `if...end`, and this will be automatically rewritten as `if...end if`.

I wish every language had built-formatting and also made the reading/writing distinction!

Very cool to know.

Are you the author of the fish shell, bychance?

(I'm a fish user. If you are, I'm super-thankful for fish!)

I have to agree: VB has better syntax, at least for my head. In addition to better block-boundary-matching, I like the type name coming after the variable name. It's silly to put the type first, especially for long ones. And it has a much better SWITCH/CASE statement. Having to use "_" for line continuation can sometimes be annoying, but at least you don't have to deal with semi-colons.

In C-style syntax there's often disagreement on how to format blocks, but there's rarely a disagreement in VB: there's naturally only one choice.

Maybe take the best of VB and Pascal, clean up the key-words by tossing legacy inconsistencies, and produce a next generation "word-oriented" style. #MVBGA!

You are not the only one. I can see a few around me, and there aren't that many developers here :)

Personally, I think every balanced marker (parenthesis, block beginning/termination, brackets) adds a maintainabiliy cost and is better replaced by some unbalanced alternative (on the case of blocks, semantic whitespace is the current winner). The largest the thing inside the markers, the higher the cost.

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

Harder to mismatch.

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

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.

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.

in my opinion, if you are having issues with mismatches braces, you have too much code in your file. I have seen this issue with God classes (which seem to be more prevalent in VB codebases)

If I am at the end of a long code block in C# or JavaScript, I might see this:

          ...lots more code up here...
          return result;
        }
      }
    }
    return -1;
  }

What's that next-to-last "}" for? To find out, I need to scroll way up, and hope the code is properly indented, or use an IDE feature to collapse the block.

But with a Pascal-family language, it would be more like this:

          ...lots more code up here...
          return result
        End If
      End Loop
    End While

    return -1
  End Function

It is more verbose - but its verbosity with a purpose, and it helps me avoid the distracting question "What is ending here?".

I recognized that I had to move from VB.Net to C# because that's where the jobs were 15 years ago. Anyone sticking it out now won't quit until they have zero options left.

I actually quit a company in 2004 because they decided to go VB.net first. Was a good move because they are still on it and up shit creek now. I’m not sure how they managed to retain any staff as long as they did.

I did a lot of VB6 around the time C# took hold. I initially thought that switching to VB.NET was the move, but with the .NET framework the whole paradigm shifted anyway so I figured I would go the way of the curly bracket. I was also tinkering with C/C++ at the time doing DSP/VST plugin development so while VB was a great RAD/Line of business platform it quickly ended up feeling verbose(most of the time, but sometimes not) and clunky. I soon could parse curly bracket languages much more quickly as well. Be it nostalgia or stubbornness I don't see a problem with sticking with VB if that is your jam, but you cant expect the world to not move on either...

We moved from vb6 to vb.Net and within about 2 years it was clear that c# wa the path forward. We transitioned after that but still have legacy apps that combine both. It was actually the smoothest, least painful technology dead-end I've ever experienced.

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...

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

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.

With the interest fading so much, I think Microsoft probably just wants to nix the project as something official. While it's not expensive for them to maintain, I imagine they don't want to be tied to a dying product like that. They probably want to actively discourage development of VB because VB does not fit into their vision of the .NET ecosystem anymore. I think that's the point the author is missing here.

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#.

I work on F# for a living, and the total number of contributors to the F# compiler (not counting trivial changes) is a very tiny fraction of a percent of our measurable user count. I imagine that fraction gets smaller for the real user count, since F# is used a lot in finance and other analytical domains where machines tend to be locked down and product telemetry is turned off. I can't comment on figures like 25% or 5-10%. Once the sheer number of users involved is too big to conceptualize (I can only picture about 1 thousand people in my head before it turns into nonsense) numbers like that don't really hold much meaning to me.

The F# compiler codebase is smaller than that of the C# compiler, but only in line count. F# code is massively more compact than C#, which is another way of saying that the concepts are dense too. There are some unique aspects of F# - custom metadata format for things not representable in C# or VB but must be carried over across F# projects, type inference and the massive number of rules for typechecking, a core library acting as a de facto replacement for a subset of the .NET libraries, custom IL reader/writer (this predates System.Reflection.Metadata), and many more - that lead to an enormous concept count that is anything but simple. Luckily, the codebase is quite maintainable and despite countless qualms I personally have with how things are organized, it's proven to be an excellent foundation for continually adding new features over the years.

Thank you for your work on F#!

While I don't get to use it nearly as often as I would like, every time I have it's been really fun to play with/use.

One of the nicest things is that I find is that every time I get to play with it, the language is intuitive enough and IDE support is rich enough that I'm never feeling like I've forgotten how to work with it.

>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#.

I agree that the F# compiler's codebase is much smaller than C# (wc suggests 417k lines for dotnet/roslyn:src/Compilers/CSharp/ vs 190k lines for dotnet/fsharp:src/, which is hopefully all the right files).

But as far as simpler goes, the compiler is quite a bit complicated by having to implement F# in terms of .Net. Enum variants are actually classes inheriting from the class representing the enum, modules are actually classes, core library members being called by different names in F# vs not, the desugaring of computation expressions into state machines, ...

Then there's F#-specific stuff, like the core library, having two different kinds of parsers (#light on and off), two different kinds of generics, quotations, ...

Edit: disregard

The VB compiler is written in VB: https://github.com/dotnet/roslyn/tree/master/src/Compilers/V...

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.

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.

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.

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.

The hitch there is that there's not so much an ecosystem for individual Microsoft products as there is a Microsoft ecosystem, where all the products are puzzle pieces that snap into each other. So if you're in that ecosystem and a Microsoft product you're currently using stops being available, there will be a strong gravitational pull drawing you towards other Microsoft products to fill the gap. You can fight that tendency by bringing in non-Microsoft products, but even if they're much better than the MS alternatives, MS people are always going to feel weird about using them. It's like telling them to defy gravity by standing on a chair all day.

I think his dismay was that they chose VB.Net over C# for their rewrite.

You're right. If they'd picked C# (again, in 2013 or so!), I would have been disappointed but understanding. Hey, it's not my project anymore and you've gotta pick what works best for you and your team, not to satisfy my preferences. But to finally be on an open non-Microsoft platform, and then to change back to it for VB.Net? That's just mystifying.

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.

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.

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.

When was it ever responsible to use VB on new projects for anything more than hacking excel?

Don't confuse VB with VBA (Visual Basic for Applications, e.g. Excel's scripting language). VB was super-useful for building things like graphical frontends for databases, back when such things were typically delivered as desktop applications rather than web applications.

VBA is the exact same language as VB 6, with the same implementation and the same IDE. It lacks some options (like compiling to an executable and setting some module attributes) and the forms library is different, but the language is identical. Since diverging, VBA has had some small revisions, with VBA 7 adding support for 64-bit pointers.

You might be confusing it with VBScript, Microsoft's old vaguely VB-like alternative to JavaScript that was used in Internet Explorer and (I think) classic ASP.

You can still do WPF/Windows Forms with C# if you wish just as you would in VB. Drag and drop and double click to write code, all that good stuff.

Probably better to just go web-based nowadays though for the instant portability of targeting all of desktop/mobile/tablet all in one go unless you have a reason not to

Right, you can do that stuff with modern tools, but there's just not nearly as much demand for it these days.

And back when there was demand for it, VB was among the best tools available to do that job.

"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...

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#.

> 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.

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.

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.

Java is a bit different though. Whatever we think of 'enterprisey', it does mean that a lot of systems were built with it with the expectation it would be around a long time.

As far as 'bets' go, it's also a bet on oneself. The skills of an 'average' developer between two languages can have notable differences in concepts and requirements. i.e. I'd be a bit curious about an 'Average' C/C++ Developer who couldn't write a linked list (or at least groks them), versus an 'Average' C# or Java developer who may never have to write one in their career.

I'll say that unless you intend to be a hardcore Systems developer or Finance Sector, Javascript is never a bad thing to at least learn enough of to at least pass equality questions on interviews.

The nice thing about learning other languages however is that it may help expose you to patterns you don't normally see in your main language, or may expose you to things that make it easier to understand certain concepts (i.e. doing Javascript sites with KnockoutJS helped me learn better MVVM practices, as well as concepts like observables which I could then use back in C#)

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.

> 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.

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

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/

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.

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

For better or worse, VB is still very much alive as an embedded language inside Office. It hasn't been enhanced in years but it probably won't be removed any time soon.

is VBA the same as VB.Net? I thought there were differences?

It's almost completely different. There is only some superficial similarity in syntax.

VBA is a dialect that sits roughly between VBScript and VB6, both defunct technologies.

VBA syntax and standard library is nearly identical to VB6.

F# is an interesting case. It's a second class citizen but it's also the testing ground for a lot of features that end up in c#

In general, many of the "new" features introduced in the past years, both in C# and in many other languages, simply come from the world of functional programming. So yes, F# in the natural playground for these new features simply because it's functional first.

Also, in many other ways is an incredibly powerful language, which leverage in a vry powerful ecosystem, sadly is kinda left behind without big sponsors.

You're not wrong. I need to put more time in with F#. It feels so elegant when I use it, I just have a bad habit of defaulting back to C# when writing .NET code as that's what I know best.

that's F#s problem. C# is a good language, and while F# has some great things ( discriminated unions, computational expressions, pipline) that make for better ways to create software..... they aren't so much better that it justifies the learning curve to get good at F# compared to just writing things in C# ( unless of course you are a F# programmer and then you can't live without all your toys... ). Also, good luck hiring F# devs. My own experience at my company, I did a bunch of things in F#, but upskilling people just proved too much of a side track that I ended up rewriting all the F# in C#, and it was actually amazingly quick to rewrite in C# ( I didn't like the C# as much, but it's fine).

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.

There are 1 to 1 transpilers between languages (with few exceptions such as LINQ to XML in VB) that are really good.

I've migrated hundreds of thousands lines of VB to C# in past years.

Had similar experience - I transpiled a ~120kLOC legacy winforms app in day and a half - mostly spent fixing build errors between not exactly translatable elements / missing rules in transpiler.

what if they don't want to?

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.

They're welcome to maintain their own ecosystem. Microsoft made it clear over a decade ago that VB.NET was symptomatic treatment at best.

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.

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.

I've ran into it at a couple jobs in the last decade, there's more VB code out there than people might expect.

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

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?

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.

Wine + Linux and ReactOS would work equally well.

Wine would probably be easier to setup.

Anecdote:

I remember in 2007 or '08 a colleague was assigned to Ericsson, to work on a time reporting "application" made in VBA, contained in a gigantic Excel spreadsheet. I also assisted in some troubleshooting.

It was called Tratten, swedish for "the funnel", and I remember him telling me that when he presented it to some kind of stakeholder board and when said "sometimes, the application gives a 'read error'" and the whole board reverberated "read error?!" amongst themselves ...

I do. We build a desktop app used by businesses around the world, including some mentioned regularly on hacker news :)

At the time we stared (1999), vb seemed like a great choice for desktop apps: It had a ton of built-in controls for building UIs, it was quick and easy to do so, and there were tons of dlls and ocxes we could tap into from a ton of different vendors.

The vb language was also appealing on a larger scale because you could take existing knowledge to other areas of the windows ecosystem: excel\outlook automation, classic asp if you need web stuff, windows automation\administration, and ie scripting.

MSDN was also an incredible learning resource

I attended a few small group sessions with microsoft in the early days of .net and we were planing on migrating ~100k lines based on what we were being shown. It looked awesome.

I managed to get hold of an early beta version and did the obligatory "hello world" and was gut punched. It took a few seconds to load took like 20ish mb of ram.

It seems laughable by today's standards, but in 2000 our target customers were still clinging to win98 and the pc's generally had garbage specs. IT people were livid we were wasting 4mb of their ram to run the vb6 version of our app. We lost sales and spent hours on the phone justifying our ram usage (fun times). A 5x increase in ram was completely unacceptable so we put it on hold in hopes that the release would improve things.

Things didn't improve so we put the plans on hold in hopes that vb7 would get released or they would reduce the runtime requirements.

Then something really strange happened: We almost lost a sale because the IT guy thought we were using .net and he refused to install the .net framework because it "used too much disk". I had to take 2 meetings with this guy and was literally screaming into the "WE DONT FUCKING USE THE .NET FRAMEWORK, DONT FUCKING INSTALL IT, WE DONT USE IT". And this wasn't the only incident. I'd get pulled into calls and would have to talk irate IT guys down from the ledge and assure them that no .net framework was required to run our program.

Today, things are much different, no one cares about using gigs of ram or hundreds of gigs of disk space. But there is a new set of problems trying to explain how a desktop app works to someone who only knows how to admin web apps.

And the .net framework eventually become ubiquitous via windows updates and other, more critical software, starting to require it. But the early days were really, really odd (at least for us and our customers).

We aren't complete luddites though. We do utilize some .net (asp.net\vb.net) on the server side for a few tools. We have a mobile app (xamarin\c#) that has some companion features, raspberry pi (python) for some "smart" displays, Arduino, and have started to look at blazor to the replace the desktop app.

I might still recommend vb6 for a desktop app with the caveat that it is a pain in the ass to install on later versions of windows.

tldr: vb6 mostly just works and is a great tool for desktop apps

Great story! Can you share the name of your app?

Reading your post, I did a search for vb6 to see what's currently out there, found some screenshots of the IDE, instant nostalgia :)

> Can you share the name of your app

no, sorry

there are few forums with some really dedicated users if you ever want to hop back into it :)

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).

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.

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.

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.

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.

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.

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.

Imagine how the poor Fortan and Cobol devs feel.

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

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?

Is that really true, or is it just a myth?

Reply on news.ycombinator.com