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

[mike_hearn]

I thought there were JS style worker threads:

https://learn.microsoft.com/en-us/previous-versions/visualst...

but from looking it seems like people were doing it by writing VB that ran in a separate EXE and then indeed, COM would let you do RPCs between the different processes. So multi-processing rather than multi-threading.

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