[RyLuke]

I actually wrote a long article on this [1]—and had a chance to interview some of the team that built the original version of VB that was sold to Microsoft. (Alan Cooper and Michael Geary; Michael actually frequents HN pretty regularly!)

My opinion is that it was a confluence of a few factors:

- Microsoft was very worried about the threat of Java/Sun, and rotated hard into .NET and the common language runtime as a response.

- The most vocal, but minority of VB users wanted more advanced functionality and a more powerful/expressive language (as is often the case). Couple with the shift to .NET, Microsoft listened to them: VB got a full rewrite into an object-oriented language and the IDE moved further away from the VB6 visual building paradigm. That left the silent majority high and dry.

- The web emerged. Working with the Win32 API was suddenly less relevant, and younger devs adopted PHP en masse, rather than adopting VB. (And existing VB6 devs upset about the change also migrated over when they could build for the web instead of Windows) Unforced error on Microsoft's part, since IE had 96% browser marketshare in 2001.

[1] https://retool.com/visual-basic/

[radicalbyte]

The web and the way MS handle the web killed it. Microsoft was pushing everyone towards these horrible activx components. Many moved to PHP or Adobe Flash.

I was using MS Access back in the day to solve business problems - it was like a VB6 DSL focused fully on data-driven applications. It was extremely time efficient thanks to that focus - what took me days to build took a VB developer (or PHP developer) months. That died thanks to web (and the web version being horrific and a dataleak waiting to happen).

The move to C# and the path they've followed since then was, looking back, the way to go. I only wish that they had done more to make the experience for native programmers better out of the box.

[jamra]

In my experience, ActiveX was not what they pushed. They pushed Asp.Net Webforms which used VBScript for the template language. The ViewState monstrosity made it an awful experience. Specifically how it send way more data than needed to and from the server on each request. I shiver when I think of it.

[fodkodrasz]

The real problem was worse than that: it was not a technical, but a legal one: Licensing!

You need to buy CALs for every concurrent user (yes, not only SMB/terminal services users) was the way to go according to some MS license experts, and the licensing was totally incomprehensible, as is today. No wonder most didn't want to risk building a business on these maybe not so solid foundations.

Still I only dare using asp.net for serving public webpages from Linux.

Of course the technical problems were also present, but many didn't even get to think of that as the BSA bullying was keeping them away already.

[Sophistifunk]

I think GP is describing the period before the .net switch. I remember back in those days having to do web stuff on MS platforms, which meant classic ASP, which was great for the job it was designed for: gluing together ActiveX components.

Unfortunately, nobody anywhere ever trusted ActiveX because it (at least gave everybody the impression it) had holes the size of a bus, so you were stuck using a limited language with no library support to do all the glue and all the heavy lifting, it was a very unpleasant period of time if you found your way into a Microsoft shop.

[bowsamic]

The ViewState problem is easily avoided by keeping it on the server

[mike_hearn]

The ActiveX era pre-dated ASP.NET.

When the web was new, it was so clearly not designed for apps that pretty much everyone agreed it was absurd to use it that way. The UX and DX was just such a horrifically huge downgrade. Instead, HTML was for documents and linking, and apps would be given a rectangle (maybe the entire rectangle) through which they could appear in the browser. Netscape partnered with Sun for Java applets. ActiveX was therefore a response to that.

ActiveX made a lot of sense for Microsoft at the time. Firstly, it let the enormous base of Windows devs put stuff into a web page almost overnight. Secondly, it leveraged existing tech that was already designed for embedding one app's UI inside another app (OLE), and for shipping widget libraries to visual designers (OCX). Thirdly, ActiveX was a lot faster and more efficient than Java applets, being based around tightly written Win32 code. Finally, people weren't so focused on security back then and anyway, Microsoft had recently been investing in adding code signing to Windows. It appeared to them at the time that code signing would be sufficient to stop abuse. We know in retrospect it didn't quite work out that way for them, although it's been pretty successful on Macs.

And in fact ActiveX did see quite wide usage, albeit mostly as IE's answer to Netscape's plugin interface. But it didn't take off in a big way because:

1. ActiveX apps were native code and native code is very low level and thus very large compared to JavaScript and HTML. Performance is great because the CPU eats it directly with no intermediate translation layers, but you pay for it in code size. Back then bandwidth and CPU were both tight, but HTML/JS were light on both at the cost of UI latency and primitive controls. People picked low startup time followed by high latency and primitive controls.

2. The UI they picked for code signing was a (standard at the time) popup modal dialog. It had very poor usability, being filled with tons of complicated words, often asking you to approve software from a company you'd never heard of (i.e. products/websites did not use the same name as the company that produced them) and worse, malicious web pages could put you into an infinite loop where if you clicked cancel they'd just immediately ask you again, forcing you to click yes. Which was equivalent to downloading and running an unsandboxed program. Back then browsers went years between updates so once they shipped that mistake, it was very hard to fix quickly and so the reputation of ActiveX became very poor.

3. They had no way to sandbox native code at this time, the Windows kernel just didn't support it at all and it probably wouldn't have occurred to them anyway.

The first problem was fundamental to the approach. The second problem was an unforced error.

They could have tried to switch over to a sandboxable bytecode; VB used what they called "P-code" on an interpreter already. But they didn't. Java was becoming too popular, too fast, and they lost confidence in their own tech stack. Instead Gates threw the company into a crash effort to clone Java. By the time .NET had the ability to do ActiveX controls they'd already moved on from that approach and were trying to make DHTML work instead.

[oliwarner]

I have the opposite take, as a non-native programmer in the early 00s.

All the PostBack loops in ASP.Net and WYSIWYG editing in VS.Net 2003+ felt like they were trying to appease native programmers to a fault. VB.Net wasn't bad but it was frustrating how hard it was just to script something without boilerplate. Being limited to IIS was also bunk.

[ksec]

>The most vocal, but minority of VB users wanted more advanced functionality and a more powerful/expressive language (as is often the case).

This is the single reason why most computing tools, ( not limited to VB ) never reached wide enough audience. The nerds keep asking for complexity, but the majority actually wanted even more simplicity.

HyperCard, Delphi, VB6, Flash.

[kalleboo]

I think there's a deeper problem with development tools in general:

There is no tool that goes from 0 to 100.

The tools you listed (I'd also add Excel) were great for people starting out, people who had an itch to scratch, people solving a problem. But inevitably, the programs they made worked too well, they got adopted, got added features, became mission-critical, and now outgrow the tool they were written in. And that's when you get the "nerds asking for complexity". Those people didn't start out nerds, they started out as users solving a problem, but now their little "make a formatted report out of this Excel sheet" tool is running the whole companies realtime sales forecasting and they scaled up along with the project.

I think the plan with VB.NET was that ("start out with VB and if you need it you can seamlessly graduate to C#!"), and Chris Lattner planned the same thing with Swift ("it will replace Python!") but none of those plans were ever carried out properly.

[Qwertious]

I have a theory on why: it's because the scope of a general-purpose-ish language inherently increases; there are always users that are mostly covered by the featureset, who just need one more feature and they'll be fully covered, so they'll ask for that feature. But by satisfying them, you'll bring more non-users from their nowhere-near-covered position up to the "99%-covered" boundary, and then they'll want their own last-1% feature.

The same people who want simplicity in their language/tooling also want to not learn a second almost-identical system just to achieve that last 1%, so refusing to expand your scope here isn't necessarily "optimizing for simplicity".

[ShadowBanThis01]

I worked for a company where we built a prototype for a rewrite of their flagship product in VB. Meanwhile a big team of programmers implemented the “production” version in VC++. But at that time a bunch of the controls available in VB were not in VC, so they lagged quite a bit. Of course management saw the prototype working (it was a CRUD app for property management) and said why not just use this. The C++ programmers turned up their noses at working in VB and were summarily fired, leaving me and a team of contractors to finish the job. 100% the right business decision and a good lesson on getting too precious with your tech.

[makeitdouble]

> The nerds

The people with money really. Few people care what the nerds complain about, but Microsoft will listen to Fortune 500 companies that hold thousands of top tier paying users and their complaints about how such or such feature would help them save days of work every months.

This the ultimate "vote with your wallet" I think, those with bigger wallets will have bigger votes.

[glenngillen]

An unfortunate byproduct of this, that I think is an unpopular opinion in these parts, is increased in product analytics/telemetry. People eventually learn that the feedback you receive re your product only rarely reflects the experience of the majority of users.

[antupis]

Adding features to a popular tool later can make it messy. Building a tool where you can add features easily makes it elegant eg Lisp.

[monalogue]

This article was excellent, @RyLuke — I read it a few months ago when it was first published and passed it on to just about everyone I know in my MSFT network.

I cut my teeth on VB6 back in the day — for someone that didn't know much about programming at the time it felt like I suddenly had found a new set of superpowers. VB6 was a big confidence booster + momentum builder that set me on a path to a happy career.

Awesome that you were able to connect with Alan and Michael and thanks for the trip down memory lane.

[viraptor]

> VB got a full rewrite into an object-oriented language and the IDE moved further away from the VB6 visual building paradigm.

What do you mean by this? Visual Studio today has a designer / code editor that works in a very similar way to VB6 that I remember. What do you think is missing?

[highwaylights]

How much time do you have?

P-code debugging with fully rewindable edit and continue.

A one-true-way event model that was derided at the time but was really just years ahead of its time.

Minimal runtime downloads to install apps locally, which also produced tiny, performant executables.

The sweet, sweet With keyword. I know, I know. But I don’t care. Just be more aware of your namespaces.

Also (and I still don’t understand why we can’t have this in VS Code when VS had this in 1998) object combos at the top of the code file for class and method (admittedly VS proper still has this I’m just grumpy at the regression)

[viraptor]

> The sweet, sweet With keyword.

VB.net supports With though?

> Minimal runtime downloads to install apps locally, which also produced tiny, performant executables.

.net framework 2.7 is guaranteed to be installed by default these days so you can deploy one exe without shipping your own runtime. Yes, officially you shouldn't, but there's so much stuff that depends on it now.

[wcoenen]

> net framework 2.7 is guaranteed to be installed by default these days

There is no "net framework 2.7":

https://learn.microsoft.com/en-us/dotnet/framework/migration...

[viraptor]

Typo - I meant 4.7. Although it looks like they finally moved to 4.8 in w11.

[sn_master]

> .net framework 2.7 is guaranteed to be installed by default these days

Yes, but that wasn't the case back in the mid-2000s when VB6 was dying and no one wanted to migrate to VB.Net

[ShadowBanThis01]

One thing that sucks about those combos, if I remember correctly: Don’t they show only the members of the class your cursor happens to be sitting in, and not those in the whole file? That’s just monumentally dumb. I remember cursing at those as I hunted through a bunch of files for some function… only to find it was right there in the file I had up but Microsoft didn’t show it.

I remember scorning Xcode back when it was Project Builder, but saying Hey, at least its drop-down member lists work properly.

[emodendroket]

A lot of people who wrote VB weren’t serious/professional programmers and VB.NET was too complex for them. For the serious programmer group, the stink of “VB” tainted it right out of the gate (despite having complete feature parity for a long time VB.NET jobs always paid notably less than C# ones). So it was kind of a compromise that satisfied nobody.

[analog31]

That was me. I wrote what I affectionately call "crapware," which are small apps that solve a problem but are not intended for use at scale. There was a lot of this stuff, such as little database queries, or hacking together a few industrial sensors with a crude display. Businesses ran on crapware. Maybe they still do. A few thousand lines of code that I wrote for a manufacturing fixture ran bug-free for more than a decade.

I remember that just downloading and installing VB.NET was burdensome, especially in the plant where many of the computers were not networked.

When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.

[ta1243]

I've written a lot of crapware, still keeps my employer working 15+ years on. Meanwhile "replacement" systems have come and gone, but the users still keep using the crapware.

1) See a business problem

2) Put something together to solve the problem

3) Move On

[MichaelZuo]

I was going to say, a few thousands lines of code that reliably solves a real business problem for over a decade is pretty much the exact opposite of 'crapware'...

[emodendroket]

As long as you don’t care about stuff like maintainability or logging sure. The issue is that a lot of times businesses outgrow their bespoke Access app or whatever and then it’s a huge headache to untangle the reliance on it and go more robust. Of course if that never happens it’s great and frees up developers’ time for higher-value work.

[jacquesm]

I came across such a project recently built using FileMaker in 2001 or so. On the original hardware, no less.

[ralphc]

Please encourage them to make a backup and get it into a VM. You should be able to find Windows 2000 if it will run on that.

[jacquesm]

I actually did just that. But I can't enforce things, only recommend.

[sn_master]

Also, most machines did not have the .Net framework installed, and back then it was 20 MB download which was gonna take ~2 hours on dial up back in the day vs MSVMVM6.dll which was on all Windows versions from 98 until 7 at least.

[deaddodo]

> When VB.NET came out, programmers hung on to their VB6 disks, and kept using it for easily another decade. By the time VB6 really reached the end of the road, its replacements (e.g., Python for me) were up to speed, and free.

VS6 was still the majority IDE well into the mid-00s, at least in an academic setting. I still remember getting handed an academic license DVD to use for my C++ courses in University around that time.

The disconnect between "classic" and ".NET" VS took a long time to break, I would say until about VS2008/2010.

[nextaccountic]

what you called crapware is just scripting, but with a gui rather than running in terminal

it's like a quick and dirty shell script or what once could be a tcl or perl script, but today would most probably be a python script

[SamuelAdams]

I think today python fills that void - people who are not serious programmers but need to put something together. Think academics, data analysts, etc. And since Python is cross platform and easy to get started with it is a lot more attractive than VB.

[cstejerean]

It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.

[Blackthorn]

Honestly it's harder to put together a quick GUI application in anything than it was in the VB6 days. By losing VB6, we've lost a lot of power and ability to do GUI things quickly.

[sn_master]

WinForms in C# was pretty decent tbh. Not so sure about WCF/Metro/Modern and whatever it is now that Microsoft been releasing. They just stopped caring about consistent UI for apps on Windows altogether since ~2010 or so.

[markus_zhang]

What's the bottleneck to build a modern VB6? Just curious.

[lelanthran]

> It's significantly harder to put together a quick GUI application in Python than it used to be in the VB6 days. Just getting all the dependencies installed can be a pain, and then good luck trying to add another button to that app say 2 years later, chances are nothing will build anymore.

I would say that it is harder, but not significantly so.

Lazarus gets mentioned a lot on these forums, but have you tried it? I use it to whack together decent native looking applications.

It's a single download, it comes with a comprehensive list of components which you drag onto a form to build the GUI, never breaks old apps on an update, and works on Windows, Mac and Linux.

[emodendroket]

Python is also more palatable to professional developers than VB ever was.

[bdavisx]

And as a programmer who preferred more c style languages, vb.net sucked (and I understand that's just, like, my opinion man). Way more verbose with weird syntax. Can't remember the exact syntax for lambdas, but it was a joke.

[reactordev]

VB6’s concept of OOP was different. Sure the same keywords are found: Module, Sub, etc but it was rewritten to run on IL/NET VM. Fundamentally changing it from a COM compatible language to a .Net framework compatible one.

[wvenable]

VB6's concept of OOP was simple enough it could have been translated into .NET and .NET is broadly compatible with COM. I'm certain Microsoft could have made it work. They really needed to consider VB6 as a backwards compatibility target instead of building VB.NET as a modern replacement. VB.NET really has no reason to exist; it's not compatible enough with VB6 but then also includes a bunch of VB6's weirdness.

[gabereiser]

Yeah, I agree. They didn't know it at the time but .Net and C# (their answer to java) would take over everything they did.

[deaddodo]

The visual editor is the same...but even with VB Classic, you couldn't just design a UI and have it magically work, you needed to wire up the logic. That component has a much higher learning curve backed by a particularly more difficult to grasp language.

[wkat4242]

Vb.net was a bit weird yes but visual basic did need work. Vb6 did not have multithreading which was really starting to hurt its efficacy by 2002. You could work around it by using events as much as possible but there were still some things that were blocking. Also the events were not even on a separate thread either leading to the need to pepper DoEvents everywhere.

This was a dealbreaker for vb to ever become a serious language and kept it squarely in the hobby bob / prototyping arena. But who wants to prototype in a language that requires a full rewrite in another language to go to production?

In the long run this was always unsustainable. The rewrite to .net fixed this but it was a significant departure from vb underpinnings and in particular the seamless winforms integration that was pretty amazing.

Also, with .net came multilingual capability and c# got really popular quickly and displaced vb.net

[gadders]

VB was probably 80%+ line of business CRUD apps. What would you write in VB that needed multi-threading? You're not writing trading systems or games in it.

[wkat4242]

> VB was probably 80%+ line of business CRUD apps.

That's more a result of it not supporting it I'm sure. It could have been a great general purpose language if it was a bit more powerful.

I used to write apps in it and I often ran into these issues. Mainly small business custom administrative stuff. Like a management system for a chain of hostels. It was still important to have multithreading because things can get updated by other users, or even clients themselves through the internet (in fact I spent a lot of time adding ASP frontends back then). I don't like using locking too much in a multi-user environment because it gives a terrible UX, so I would have to constantly check if nothing had changed.

In this day and age you will also have to deal with a lot of web API calls that can happen asynchronously. Locking the main thread is really not an option. Remember that VB6 even locked the User Interface when it was doing something, even the visuals didn't have their own thread. Making for a very choppy experience.

Like I said peppering DoEvents everywhere helped mitigate this a bit, but sometimes you had to call stuff in external DLLs and while the call was away the whole UI would be hanging.

[3np]

Electron seems successful regardless of lack of multithreading on the language level?

I don't buy this one.

[mike_hearn]

Correct, nobody cared about "true" VB multithreading. Besides VB supported multi-processing very well, much better than the JS world does today. You could call objects between threads no problem. Behind the scenes it was using DCOM, so if you passed an object from one thread to another, the other thread would get a proxy that'd do RPCs to the first thread. So there was no true shared memory multithreading, but for VB users what they had instead was in some way even better, it was basically web workers but more transparent. Specifically, it meant that object calls couldn't run in parallel to UI updates or other logic so there was no need to think about locking.

[wkat4242]

But the whole thing of the UI being on the same thread was a really big problem. You could get around it by calling the Win32 Threads API but that would quickly lead to a crashfest due to the no shared memory thing. Electron doesn't have this problem because the UI is handled by the renderer, not the JS engine. So in that sense the UI is in a separate thread. This wasn't the case for VB6.

And events in VB6 were not great. They were good for the time, sure. Because they had to be. If you'd write an app in it today with lots of external API calls it'd be a mess.

VB6 was serviceable at the time but without multithreading support it didn't have a future in an ever more API-driven environment.

[mike_hearn]

I don't quite understand what you mean by UI being in a separate thread. You could have background threads in VB from what I recall (it's been a while...). The only difference is that Electron/JS forces you to do your own IPC messages whereas Windows would abstract that out.

[wkat4242]

What I mean was that if you ran a large function that would take a few seconds, any UI redraw would be blocked completely for that time. So resizing a window would not cause a redraw of the UI until it came out of the function, pressing a button would not visually reflect the button status, basically it would seem like the application was hanging.

You could avoid this by peppering DoEvents in your loop. However, this was not always possible like if you were calling an external DLL function. I had an application that would talk to a Kodak digital camera by using their DLL and that would take considerable time.

It's really what separates a serious programming language from a toy, or at most a prototyping tool. Like Fisher Price, you can make something quick but it's not capable of actual use.

I think people have this rose-colored view because back in those days UX standards sucked and many apps had a lot of quirkiness. But times were changing and even a few years later this was unacceptable.

There were no official background threads, you could use the Win32 Threads API but it would cause instability due to not having memory protection.

But this "hanging" behaviour was really not suitable for a general purpose application. Electron doesn't have this issue because the renderer is independent from the javascript code.

[wkat4242]

Javascript is better at asynchronism than VB was, and in Electron the user interface does run in a separate process. Unlike Visual Basic 6, where the UI would completely hang when you were busy with some external function call.

[dkga]

As someone who loved coding in VB6: (I actually dreamt about it the other night, thought I woke up some 20 yrs ago!)

- very cool that you got to interview the VB team, your article is high on my reading list :) - to OP’s point, I recently started doing some things in Swift with XCode and found sim having just as much fun. I’m using SwiftUI. So maybe not the same experience for everyone but I wanted to share here.

[ShadowBanThis01]

I did a shitload of programming in VBA, specifically Word macros. Word 6 was the peak of that product. I wrote entire text-processing applications in it, with dialog boxes and everything. Started my career at a Big-6 firm with one, actually.

Now I’m learning SwiftUI as well, and like it so far. I’m an experienced iOS dev, but SwiftUI is new to me. But I like it (and QML in Qt) more than I expected. Good luck!

[dkga]

Thanks! Good luck to you too!

I don’t have experience with iOS - I am actually doing a bit of macOS development with that SwiftUI because, well, desktop apps kind of take me to my teen years building VB programmes (no one called them apps, at least I didn’t).

[thread_id]

VB and the Web: The VB model for rendering Web pages was Active Server Pages and Server side rendering. Very similar to Java Server Pages. Which was still better than PHP but the IDE did not have a community version and php was easier to get started and was being taught in college curriculum.

IE having so much browser market also killed anything MS because they always tried to create their own standards which nobody wanted to follow. The client side was so difficult to script with having to test which browser and accomodate quirks mode. Another unforced error. Corporate adopters are still trying sunset critical apps which only run in IE or Edge with IE mode turned on.

[nrivoli]

As someone that started in vb6 and then php in 2001, this.

[seanmcdirmid]

My understanding is that the target audience for VB.net was happy enough with C# instead, so it was a product without much of a user base.

[yoava]

I do not think the problem with VB was the language. I think it was the graphic / UI expressive power, a simple way to add and create custom components.

At the same time that both VB and Delphi reached peak usage, the web started to show how easy it is to express graphically and UI using CSS. When you have to write tons of lines of code in VB to get to the same as 3 lines of CSS...

[marcus_holmes]

This doesn't match my experience, if anything the other way around.

CSS back then was a lot harder than it is now. There's still memes around this, but even something as common as centering an item with CSS was not trivial at all. Now we have flex and it's easy, but back then it was very much not.

VB didn't work on the same paradigm - it was a more WYSIWYG environment. You drew a button on the form, set some properties in the sidepanel, and that's that. Notably there are zero lines of code involved in this, so the whole "you have to write tons of lines of code in VB" is simply not true. Possibly you're thinking of its successor, XAML, for which this is true.

[yoava]

Having worked for 10 years on both Delphi and VS, I understand the experience you are talking about. Having the ability to draw UI is amazing, and super productive. For business applications, it is amazing.

However, I still remember at around 2002 that we where asked to build specific custom user experiences, I think it was around reports, and using VB or Delphi was a lot of programming using draw commands... while using HTML and CSS it was fairly easy, even with the browser differences of CSS.

Any custom component in VS or Delphi (I am talking atomic components, not composite) requires using basic draw commands, and a lot of them.

The end result was that both platforms are not as expressive in terms of UI as the web, you cannot compare basic draw commands to structured CSS.

[marcus_holmes]

Reports, yes, that was a pain in the arse. Anything where you had to generate controls on the fly based on data was painful. Crystal Reports was both a nightmare and a lifesaver at the same time. I always thought that someone should do a better job of it, but I did not want to go there ;) By comparison producing a report (or anything data-generated for that matter) in HTML was easy.

[mike_hearn]

These tools were built for GUIs, not typography where they were very weak. They outsourced document production to other tools like Crystal.

[fendy3002]

can vouch on this, since originally I really prefer WYSIWYG UI (VB, C# winforms, wpf) over web early. However security-wise it's hard to enforce when using them, since they don't really operating using client-server by default, having your backend logic prone to be reverse engineered.

This doesn't happen in web apps, since backend logic stays on the server. Whipping a html UI over the already server-client architecture is easier. In addition with ease of deployment of application making web apps very favorable.

[yoava]

VB and Delphi reference architecture was 2 tier - client and database. With this reference architecture, you are right about the security and distribution problems. You just reminded me of the shareware market and the hacked shareware markets...

However, early on, around 1998, people started talking on 3 tier architecture of client - server - database on both platforms. There where even attempts to build web pages using both platforms (and later on .Net), which failed because of a lot of reasons, one big reason was not understanding the advantages of CSS.

[fendy3002]

Yes and nowadays there's nodejs with react, where there's javascript on both client and server, with addition of html and css making desktop app that's not multi platform, almost obsolete.

Which is why lately companies are trying to use electron or react native to replace them.

[marcus_holmes]

I opened VS and looked at WPF again the other week. It was a surprisingly pleasant experience. Though my C# is sooooo rusty now (and not in a crab-like way).

I wonder if there's a market for "WPF for Golang"? ;)