For Julian evangelists trapped in corporate environments (like I was), this list is actually not very helpful because my managers would not have heard of any of those languages.
I know it sounds silly, but I believe it would help with corporate adoption if you included VBA and even Excel in this list.
If anyone wants to contribute VBA and Excel implementations of these algorithms, they’d be welcomed. Of course, I’m not sure how we’re going to find a benchmark machine that can run all of these implementations, but maybe we can just normalize relative to C on different machines and combine the results.
We could run VB or C# (preferable, I think) under CoreCLR on Linux.
Or run everything on a Windows 10 machine using WSL 
Excel is the tough one – I have no idea how to script running something like this in Excel.
I think it would have to be a composite of Excel and VBA given that Excel uses a Visual Basic variant as its macro language.
Presumably just having a VB implementation and timing it would be sufficient then? I can’t imagine that the Excel VB variant is much faster than the standalone one.
More likely slightly slower. I agree that VB alone should be sufficient although Excel does have some array functions that most people don’t use.
I find it strange that one should invest time and effort in “proving” that excel and VB are slower than say any of the languages that are already included in that benchmark. Is it really not common knowledge? Not to mention the comparison in itself: excel is a spreadsheet program that isn’t meant for the same tasks that the languages in the benchmark are. Apples and oranges…?
VB/Excel benchmarks relate to @anon67531922’s comment a bit further up:
Apparently, it’s not common knowledge, furthermore it probably isn’t common knowledge how big the difference is. Just hope VB doesn’t blow everything else out of the water…
I understand why it would be useful to know that Excel/VB is slower and by how much. I guess I’m questioning if it is “our” (i.e. @John_Gibson) responsibility to provide that specific comparison.
After googling some about python/VB comparisons, it seems like this is not as clear as I initially thought. So maybe a comparison like that would be useful – for us and for others as well.
(My initial reproach was rooted in my own experience in coding something in Excel’s VB, it took 6 minutes to run, then learning and writing it in Matlab, that took less than 5 seconds.)
The problem with VB/Excel is not only speed, it is also numerical accuracy. You can find a lot of “case studies” online, and some articles documenting it. It is not a language designed for numerical work; no spreadsheets are. Benchmarks aside, I am not sure the comparison of spreadsheets vs programming languages can be meaningful. Julia may be much faster than Excel, but that is not really the point, it is comparing apples and oranges.
I would tend to agree. It would be weird to have Excel up there in the julialang benchmarks front page. Nobody would use Excel to compute the Mandelbrot set (right??)
Never say never:
Hi @yakir12,
As I mentioned, most “managers” in a corporate environment have never heard of most (or any) of those languages. Particularly in the insurance industry where I think Julia could have a massively positive impact. Everyone is still stuck in Excel hell. I am the former Head of Risk Management for AIA Hong Kong & Macau. We simply converted a bunch of Excel spreadsheets into Matlab and the results almost seemed like magic. We were heroes. Of course, licensing issues with Matlab were a headache especially when running a server so there is a real opportunity for Julia evangelism within the insurance industry (which is a massive industry) and, like I said, as silly as it sounds, having a Julia comparison to Excel could conceivably carry a lot of weight.
Fortunately, I am no longer a corporate slave and am building my own digital insurance company from scratch and you can guess what language we are using 
Best regards,
Eric
Great.
I too started my own business. I also use Julia in my book keeping and especially when invoicing clients.
This puts all those discussions about large integers in a new light 
Ha!! I wish. Alas. All I need is a bit more than UInt8 
Could you give some background?
I think Matlab licenses may have become more flexible since we were doing this several years ago, but we were using embedded Java in an m-file to run a server that ran Matlab code. Technically this was a license violation and getting that sorted property was a headache.
I also doubt the importance of providing a VB benchmark comparison. In short, the VB crowd is probably not Julia’s natural target group.
Some 15 years ago, we taught business school students to use VBA to do (reasonably complicated) financial calculations. Since then, the same type of students have preferred ML or R (and more recently, Python).
It’s my guess that those still using VB(A) are (a) not very concerned with the speed-up and/or (b) don’t have the time to invest in learning a new language.
Paul S