I'm curious how performance will be compared to VB.NET, I'm assuming you could create some small lightweight executable for simple things that have better performance.
hi guys. performance wise, the initial release of twinBASIC will sit somewhere between VBA (or VB6 p-code) and VB.NET. I haven't done extensive benchmarking comparisons yet, but for the ones I have done, twinBASIC can be up-to 10 times faster than VBA, depending on many factors of course.
twinBASIC outputs EXE code directly now, rather than using an intermediate layer like p-code. Once we turn on support for LLVM compilation, performance should be on par with VB.NET, if not surpass it.
There is no VBA integration yet. I've got some ideas around that, but nothing concrete. For now, you'll be able to create compiled DLLs with twinBASIC (ActiveX or non-ActiveX) that you can reference from VBA.
One of the big advantages (I feel), is that DLLs and EXEs compiled with twinBASIC don't have any dependencies beyond the OS standard DLLs. The runtime parts are statically linked in to the DLL/EXE as necessary
@Vogel612 even so, if you don't have the redist installed, this one C++ program probably won't run so from user's POV, redist is basically required to run this.
in .NET core they introduced the ability to run .NET code without having a runtime installed but doing that makes the binaries way bigger... like hundred of MBs.... :-O
Not really. The whole project, including compiler, debugger, all the vscode LSP support etc, and the runtime comes in at <2MB for the x86 release. So even if the whole runtime gets linked in to your DLL/EXE, it's only going to be 1MB or so. Probably a lot less than that actually.
As things evolve and we add more optimizations to the runtime library, things may grow a little. But realistically, I am keeping things tight, and so I don't see us ever getting to a 10MB runtime library.
The twinBASIC runtime contains all the functions under the VBA namespace which you see in the VBE Object Browser. Like MsgBox(), Left(), etc, plus there's many implicit conversions and things like that which require extra support from helper functions.
Currently only the same support as VBA/VB6 for them. So AddressOf works in the same way (giving you a LongPtr). Possibly we could look at supporting something like VB.NETs delegates.
MsgBox boils down to MessageBoxIndirect, but the issue is that MsgBox takes Variant inputs, and these have to be converted down to BSTRs or even ANSI strings for MessageBoxIndirect. So you don't do those conversions inline every single time you call MsgBox, but instead have a helper routine to do them for you.
VBA Rubberducking
VBA Rubberducking