, 63 min read
Best programming language for high performance (January 2017)?
70 thoughts on “Best programming language for high performance (January 2017)?”
, 63 min read
70 thoughts on “Best programming language for high performance (January 2017)?”
I really like this way of reasoning about languages. I have, however, a bone to pick with your reasoning about no particular cross-platform build system for C/C++. While it is true that there is no cross-platform build and test system as defined by the standard, CMake comes really close to such a system. With the new C++11–17 standards that abstract away many of the OS-specifics such as multithreading and file systems, C++ with CMake gets as cross-platform as it could possibly get.
@Skand
Have you tried Go tools? Ok. We have this project in Go. You know what you need to do to get it and all its dependencies? And then run tests to make sure that it works?
That’s it. And this pretty much works with any Go project.
There is simply nothing like it in C++.
I don’t know what fraction of C++ programmers use CMake. I estimate that it is actually quite small. For one thing, users of Visual Studio won’t touch CMake and I would not be surprised if they made up more than the majority of users.
While CMake can call your tests, it does not really provide a testing framework, you have to roll your own. If there are dependencies, you have to provide them on your own. If users need to resolve dependencies, they have to figure it out on their own.
With Go, you can just pick up any project and you have a pretty good idea how to build it, no matter where you are.
That’s not to say that Go is perfect. It still has major faults. But CMake is nowhere close.
Visual Studio 2017 ships with CMake. They are actively working on CMake integration and working nicely with the C++ community to figure out how best to make things work in real production environments. So your intuition about Visual Studio is completely off.
And CMake’s support for Visual Studio is not the best, but it does work. After some digging, I can usually get what I want done in a cross-platform manner. The rub is that I’m dealing with decades-old legacy 3rd party libs and brand spanking new libs. Nothing will ever, EVER, cover these builds/configs in one simple way. CMake makes it so that I can work with these disparate technologies and still have a flexible build system.
The main problem with your analysis is that I think it’s unfair to compare the build tools and say “CMake is nowhere close” because CMake does so much more than the Go tools have to. For large, cross-platform C and C++ projects where they do dev work with Visual Studio and things like CLion, CMake is the way to go. And if you look up projects that actually use CMake, I think you’d be surprised at the list.
@Caleb
So we are clear, I use CMake all the time, almost daily. E.g., see https://github.com/RoaringBitmap/CRoaring
Visual Studio 2017 ships with CMake.
Ah! That’s interesting. So I was wrong to underestimate Microsoft. I am happy that my pessimism was unwarranted. Thanks for educating me on this issue.
The main problem with your analysis is that I think it’s unfair to compare the build tools and say “CMake is nowhere close†because CMake does so much more than the Go tools have to. For large, cross-platform C and C++ projects where they do dev work with Visual Studio and things like CLion, CMake is the way to go. And if you look up projects that actually use CMake, I think you’d be surprised at the list.
I don’t think I am being unfair. CMake is a major contribution. I do not underestimate the difficulty.
But the truth remains that CMake solves a fraction of what the Go or Swift tools solve.
You point is that I am being unfair because neither Go nor Swift has to support “decades-old legacy 3rd party libs”. I agree with your wording, but I think I am being fair. Hear me out.
When the C and C++ came about, nobody had the idea that testing, building and managing dependencies had to be part of the language. So it was built separately, by different people, and it evolved without any standard. It is too late today to really solve this problem. It is like retro-engineering a Chevy Impala so that it runs on solar energy. I mean, in theory, it could be done, but you just know it won’t get done.
So CMake is a lot better than autoconf/automake. No question about it. It solves hard problems… ok. But it is only so incredibly hard because we are retro-engineering.
But let me go back to my Go example. Realize that what I described, running tests, downloading dependencies, and so forth… that can all be done without any configuration file. With Swift, there is a configuration file, but it is maybe 5 lines at the most. Rust is similar.
So Swift, Go, Rust… they have this idea that the language needs to come with its own high-quality tools, by default. I submit to you that it is an innovation. They did not invent this idea… I mean “Turbo Pascal” came with its own IDE. So did Visual Basic and so forth. But you have to give credit to the folks involved: they knew enough to realize that languages today need to be a lot more than just syntax and a compiler.
If we are going to move forward in software, we have to learn from our collective mistakes. C and C++ are great, but if we had to do them over, we could do a lot better.
If world were ideal then you would be right. 🙂 But C++ build-world is a mess, and nothing will change. In the wild you find: custom makefiles, autotools, Microsoft’s VC files, even Boost has own build system. There are too many libraries, too many eco-systems (unix, windows, mac) and incompatible compilers. I work with C++ and every time I need to compile an external library it is a pain in neck.
C++17 would be an answer if it were came 10-20 years ago, now it’s too late, there are billions of lines written in C++98, C++03 or C++11.
I cannot disagree with the point of C/C++ builds being a mess, but I must point out that there are ways to build a wide variety of libraries on wide variety of platforms in uniform way. Recently, I have used conan package manager to automate downloading and building of a bunch of libraries. This includes building custom-configured FFmpeg (which is a huge pain on Windows otherwise), managing dependencies between zlib/minizip/mbedtls/libcurl, using static libraries instead of DLLs, and some project-specific hacks.
In conan, one can write a “recipe” for a library, which is basically a Python script for building it. There are also tons of helpers of all kind, dependency management, packaging customization, tagging artefacts, etc. Of course, in order to use it successfully, one has to invest tons of time into learning conan and specifics of platforms, ABI, build systems, etc. Otherwise you will be limited to using already available recipes with default configurations, Which, by the way, include boost, qt, poco =)
So, a uniform system for dependencies exists, but it will never be as easy as npm/pip install.
P.S. Some other signs of gradual improvement:
CMake becomes more and more popular for C/C++ libraries, even old ones migrate to it.
Header-only libraries are quite convenient to use. Just remember that there are good and bad header-only libraries, otherwise you will quickly get into build time issues.
I love C++ with CMake
I’m an java programmer and now begining with C++ to prepare for any kind of future project in future.
Python comes with JIT (pypy) and cool libraries libraries like numpy, theano, so, is also a choice, imo.
I do address Python. It is certainly possible to write very fast software in Python… but I don’t think it is in the same class as the languages I consider.
Some Python libraries are essentially C libraries just with Python bindings. They’re very fast hitting almost C performance. Google ie. Numba. It is possible to write fast apps (regarding Python is interpreted – not compiled!), but the programmer should know which part of code are executed slower and then ie prefer list comprehensions instead of “normal” for loops which are not very fast in python (but comprehensions are quite fast indeed!).
Go. You can turn off GC in Go and use “bare metal” memory allocation. However Go is not very suitable for processor programing, because the Go niche is internet and Go executables contain a lot of additional stuff (they’re much bigger than C ones) .
You can transpile your Python code to Julia, Rust, or C++ to get additional performance. Sometimes you can use Pypy (but you can’t use certain libraries if you do this), and sometimes you can use numba’s jit, @rpython, or cython.
Even Pypy is not exactly “high performance”.
Ada with the Ravenscar profile would likely hit all your points with flying colors. Its syntax is quite simple to read, and GNAT is pretty much all you need.
yes you are right. Ada is amazingly fast and safe as well.
I don’t think you can ignore Rust in such a comparison. It was designed specifically to address many of your criteria. While it’s certainly too early to tell if it can win the hearts of c/c++ programmers such as myself or if something better will come along first, it is gaining momentum in certain circles. Personally I still find the language overly difficult to work with, but really interesting system level projects such as https://github.com/jwilm/alacritty are starting to pop up which are quite intriguing.
I definitely agree. After all, Mozilla is actively working on implementing parts of Firefox in Rust right now, along with a number of companies and organizations (albeit mostly smaller ones) who already have production software based on Rust.
I have put a time stamp in the title of my post because I expect that my current opinion might change drastically in a year or so. Maybe Rust will grow.
I think that my rationale (“coding is a social activity”) makes a whole lot of sense. It is not simply how many people use the language, of course… but also, very much, how many people “like me” use the language.
I don’t know how much trust you can put in those things, but TIOBE puts Rust at position 41, below Haskell and Logo. In contrast, Swift and Go are ranked at position 13 and 14. Redmonk has roughly the same ranking with respect to these languages.
A Lisp family language that “transpiles” to C would be optimal, if it did a good job. Chicken and Gambit are in that category, if I remember correctly, but they don’t seem mature/polished/stable.
I would like to have a good language for efficiency, e.g. in a raspberry pi, but there’s no perfect language, and if I have to concede on something, efficiency seems like a good candidate to give up on it. Expressiveness is much more important, and much more than that the libraries, frameworks, and tools available for the language.
Even if Java was already take out of the question, the Garbage Collector is configurable, so that one can avoid the FullGC and ‘stopping the world’.
the Garbage Collector is configurable, so that one can avoid the FullGC and ‘stopping the world’
Not in any realistic sense. Sure, you can choose a different GC configuration, but all of them stop the world for significant lengths of time.
Not Azul Zing https://www.azul.com/products/zing/
Is there any independent assessment of Azul Zing?
Customers pay for Azul Zing. That’ s evidence.
One language that you should consider that is probably a very good fit for your specific requirements is Delphi. If you’ve never tried it, try it. You’ll be surprised to see how fast is is to code with, how fast the compiler is, how fast and efficient the code that is produced is, how good the memory manager is, how well multi-threading is supported, and how you can embed assembly inline in the few situations where you might want to use special cpu instructions.
Oh, and it’s super easy to call C functions.
After Basic, I learned Pascal (Turbo Pascal). When I moved to Windows, I started using Delphi in the 1990s.
I have nice memories of Pascal. Free Pascal is alive and well. Performance is still good. Pascal got many things right.
However, I think it is fair to say that Pascal is, at best, a niche language. And there is little chance that it will ever become popular again. I am not exactly sure why it faded.
Every language is niche. That’s why we have so many of them and why they are so very different. Delphi is becoming popular again despite the fact that it is also expensive and not “free” like the “popular” languages. But, sometimes you get what you pay for. If it’s been 20 years since you’ve touched Delphi, I would suggest that you look into it again. If your not sure why it faded, I would offer a perspective: maybe it didn’t fade away, rather, maybe programmers that once touched it faded away from it. Also curious to note, it’s #11 in 2017 on the TIOBE list as shown in the link above by a previous comment. It’s ranked higher than Swift and Go, so maybe it’s not as faded as you might think. Every programmer I’ve ever met (including myself) gets stuck in their ways. We choose a language or technique usually based on what we know and what we are comfortable with. We rarely take the time to investigate the possibility of using a different tool even if it might be a better tool for the job than the one we are familiar with. One final note: I do like your thought process on this blog post. It feels like it has an authentic tone of objectivity (which is very rare these days).
Also curious to note, it’s #11 in 2017 on the TIOBE list as shown in the link above by a previous comment.
That’s an interesting observation. I had not realized that Delphi remained so popular throughout the years.
Delphi is, by far, the best programming language and tool. Currently, Embarcadero just released Delphi Community and it compiles native to Android, Windows , iOS and also web with Intraweb. In case you you want open souce software you could try freepascal
The language syntax is more human, is consistent (passing variables is always the same behaviour as it copy data). Has ARC for memory management that gives you fast performance than stop the world garbage collection algorithms.
You have a experienced languange with high performance, fast and deterministic garbage collection, consistency, well known RAD tools that compiles to all platform.
Agree!!!
“I am going to ignore…”
Just thought that once you ignored all, you would be left with only one choice.
Swift does have some access to SIMD as discussed here: http://www.russbishop.net/swift-2-simd
@Neil
Swift does have a simd package, but it is macOS only for now. It is not a critical issue because Swift can call C without overhead, so you can design your own SIMD functions if you want.
Interesting post. A couple of nitpicks:
You say that you narrow it down to a list including Rust, but then later you say you’re ignoring Rust, but then within the same paragraph imply that you’re talking about two languages instead of three. I’m not sure if I’m misreading or there’s a typo somewhere there, but it seems slightly off. Either way, I got the impression you wrote off Rust, which I personally would not have.
> … and Python appear unable to support natively multithreaded execution
I’m not sure exactly what you mean by “natively multithreaded,” but Python’s multiprocessing module *does* let you use multiple cores if that’s where you were going with this statement. Having said that, I agree with you that Python is unsuitable for systems programming.
Overall, nice article though 🙂
You say that you narrow it down to a list including Rust, but then later you say you’re ignoring Rust (…)
I first narrow it down to system programming languages, and I include Rust in this list… but then I remove Rust because I fear it is not yet popular enough. I had a misleading “both” that I removed. As I have written elsewhere in the comments, this may change if Rust becomes a lot more popular. I don’t think “I wrote off Rust”. I specifically mention it has a valid system language. But look… one has to be realistic… Rust is below Haskell, Scheme, Lisp, Logo in the TIOBE ranking. We hear that Mozilla (the organization that promotes Rust) might use Rust for some things. It is not a great validation. Swift has the whole might of Apple behind it. Go has… well, Google… Docker, Netflix, Dropbox…
For all I know, Rust is the future… but I’d like to have hard data to back this up.
I’m not sure exactly what you mean by “natively multithreaded,†but Python’s multiprocessing module *does* let you use multiple cores if that’s where you were going with this statement.
I distinguish “process-based parallelism” and “multithread execution”.
Hi Daniel, I don’t know how up to date are you with Go’s garbage collector. It runs concurrently with the program most of the time, had two short phases that were “stop the world”, and recently managed to remove one of them. https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md
From my post…
Go has generational garbage collection (like Java or C#) which means that “it stops the world†at some point to reclaim memory, but the Go engineers have optimized for short pauses. That’s a good thing too because “stopping the world†is not desirable.
Yes, I did read the fine article before commenting, I just thought you might be interested in the recent improvement regarding StW since that description could describe a year ago. :-)
Your headline is misleading because high performance is far from the only criterion you are using, otherwise assembly language would be at the top of your list.
As long as you are using other criteria, you might consider that C and C++ are security nightmares, safe languages are much easier to program, and consequently, less and less programming is being done in C and C++.
Perhaps the future of C and C++ is like assembly today, where the great majority of programs are written in other languages that might call into a small assembly language stub when it really makes sense.
More here: http://trevorjim.com/c-and-c++-are-dead-like-cobol-in-2017/
Your headline is misleading because high performance is far from the only criterion you are using, otherwise assembly language would be at the top of your list.
In the real world, you want to produce the best/fastest software possible given a time budget.
Even so, I would not be able to consistently or even generally beat a C compiler on performance in assembly. I need tools to get the job done and programming languages and compilers are a must.
At a higher level, if you don’t put enough effort into it, it is far from certain that your Java program will run slower than your Java program. And there are many cases where you just don’t have that much time. If I had to write very quickly some high-performance backend, I am not sure that C/C++ would win out.
As long as you are using other criteria, you might consider that C and C++ are security nightmares, safe languages are much easier to program, and consequently, less and less programming is being done in C and C++.
I relative terms, there is no denying that C and C++ are less popular than ever… but I am not sure what the picture is in absolute terms. I submit to you that there are probably more C++ programmers in 2017 than ever in history.
Perhaps the future of C and C++ is like assembly today, where the great majority of programs are written in other languages that might call into a small assembly language stub when it really makes sense.
Yes. This makes sense to me.
I think it’s bizarre that you miss such a major topic as compile time dispatch. In C you are frequently stuck using function pointers which can’t get inlined. Or passing an array with fixed compile time size as a pointer + size into a function. This can easily lead to introducing indirection where it’s not necessary. This is very avoidable in C++ and D, mostly so in Rust (and afaik Swift), and very hard to avoid in Go and C.
I also wouldn’t put safety at C++ as “minimal”, on par with C. While you can shoot yourself in the foot in either, RAII and the standard library definitely encourage you to write modern C++ quite safely.
I agree. And with modern C++ you can use smart pointers to eliminate risk of memory leaking. Standard containers almost eliminate the need for manual memory allocation.
Another point you neglected: Swift’s support for Windows is inexistant. To my eyes, that disqualifies it immediately.
@Kevin Generally, Swift supports few platforms at this point. It reflects the lack of maturity inherent to the language at this point.
I expect full Windows support in a couple of years.
Version 4 looks like it will have Windows support. From reading the Swift Git commits anyway. People already have working versions, so …
Regarding your point about Swift and non ARC/GC free memory management.
https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md
Swift 4 is on track to have manual, none ARC managed memory.
If you consider Rust, how would be the table shown at the bottom of your analysis?
Just curious.
As I explain in the post, I set Rust aside for the time being because I do not judge the uptake to be sufficient.
This being said, here is my poorly informed opinion about Rust:
There are few things that make me think Rust will have trouble gaining a wide audience:
I know that I am repeating myself, but this issue should not be understated. Rust relies on a lot of explicit annotation. To be fair, C++ has a terrible syntax, so the path from C++ to Rust can be seen as a step forward… but it all comes down to perceived productivity. Is Rust readable to Rust programmers? I think C++ is not readable even to C++ programmers.
Thanks for this excellent read.
I have not been programming for a living some years, but I always enjoyed it and am about to embark on some coding projects again.
So it was good to see a current analysis from the perspective of active and informed programmers.
Hello.
If you consider concurrent, safe, and bare metal programming languages, how about Ada2012. The language inspired Rust to some extend and it is mature to run on mission critical systems like Helicopters, Sattelites,… Even NXP used it for their board printing machines for motor control. It is suitable for true Real Time systems.
Just to give you an incitement.
See this paragraph which applies to Ada:
“until many more people start coding in these languages, I am going to ignore them”
Instead of being ignorant, please take a very good look at ADA 2012. You talk about “high-performance programming”, but you are very vague about the specific requirements and your analysis table is rather primitive. Performance is not everything, quite often scalability, reliability and maintainability are much more important.
Instead of being ignorant, (…)
In 2017, programming is a social activity. That’s why we all learn English. Not because English is intrinsically superior, but because many people use English.
Hello,
as long as we are no social streetworkers only and we like (at least I do) to code things that WORK in the end, the language matters, no matter how “unpopular” it might be. C is fast, bare metal and has a high library variety. But here it ends already. The big joke is, that most of the systems are programmed in a language that is least reliable and totally error prone. You will not see this language very often in mission critical systems, you have to rely on. Automative still uses C and we all know the headaches (I guess Audi calls back again, not for the lying part of diesel consumption, because a bug is in the control software). The avionics requirement DO178B has strict usage rules for C (even C++ is mentioned nowhere), like MISRA. But countless code lines, one hour or one coffee too much and a programmer misses the curly braces around an if()-statement… On a train-track control system. NO GOOD. Klocwork tells, that there is a possible NULL pointer dereference, but missed braces around an if? Naaa. and According to the vague requirements you made, no one exactly knows your criteria. English might be used by most people. Use English when talking to other developers, yes. But there are also around 70 Million people (at least) that talk German. That is a huge user group, don’t you think? Ada for instance is used by more people than Rust. So where is your “critical mass” of users? You use the tool which is best for the job to be done. When you want to crank out all of the speed possible out of a device driver and want a bit more flexibility than Assembler -> please use C! But test the hell out of it, if someone’s life depends on it. and C++: What is a language of use that offers me 1000 ways to do things where you have 999 of them being pure crap? And you cannot even detect this. When you want a reliable and fast system with more than 500000 lines of code, that is of advantage programming multithreaded, and you are willing to sacrifice 10% speed penalty due to runtime checks compared to C, and need an average size user group use Ada. Make the code generation automation easy or write down a test frame for your fast code system in a day? Use Python.
as long as we are no social streetworkers only and we like (at least I do) to code things that WORK in the end, the language matters, no matter how “unpopular†it might be.
If it works, but you alone can review and maintain it, you have a problem. If you can’t use tools developed by other people because they don’t care for your language, you have a problem.
English might be used by most people. Use English when talking to other developers, yes. But there are also around 70 Million people (at least) that talk German.
Using German is fine.
The big joke is, that most of the systems are programmed in a language that is least reliable and totally error prone.
And yet, here we stand. The software industry dominates the world. So we must be doing something right. Note that most software is not written in C. I bet that PHP and JavaScript are more popular.
You will not see this language very often in mission critical systems, you have to rely on.
I am pretty sure that C is being used for critical systems.
Ada for instance is used by more people than Rust. So where is your “critical mass†of users? You use the tool which is best for the job to be done.
And how many people know and use the tool in question matters.
Use Python.
I love Python.
Python is somewhat fragile when it comes to using includes on different target platforms.
I’m curious about multiprocessing performance for Monte Carlo Analyse for each of the hardware systems on the market.
Loved this article . In one of my earlier profession as a nuclear engineer , We used FORTRAN , supposedly that was the fastest for mathematical functions . and the language was also simple . But ofcourse as you mentioned , its use case is completely different from system programming languages .
I like C for its simplicity and power . ( Not that I used it professionally ) and same for for python .
I wish that they had created python with the under pining of C
or maybe a flag for turn off and on
1) memory management
2) pre compiled vs interpreted
Every major energy suppliers management systems are based on FORTRAN. Hands down, today, FORTRAN compiles faster code on any platforms than C does. AI is undoubtedly relies on mathematical functions, heavily. Not surprising Nvidia supports FORTRAN, search cuda-fortran, so not a marginalized language at all. Also Pypy in many high performance needs is faster than C. Benchmark them before you judge. As per German, more Europeans speak German than English or French 😉 , not me unfortunately.
That’s a good argument for learning the language if you want to work on these legacy systems.
Outside of Fortran’s main applications (i.e., numerical analysis), I doubt this statement.
For the record, here is what I wrote about Fortran: “Fortran is out for similar reasons: it still has important users, but they are specialized.”
If you want to make such extraordinary claims, you need to provide the evidence.
As per German, more Europeans speak German than English or French 😉 , not me unfortunately.
I did not object to using German anywhere on this page.
Hi
Can Julia (https://julialang.org/) be considered a comparable choice?
I think you have a few errors in your Swift assessment. While Swift has been moving very fast, with major releases every year… Many of your points were true at Ver. 1.
1) Swift has ALWAYs had low level memory access, pointers, and byte level memory tweaking. Anything doable in C and C++ on bare-metal is doable in native swift.
Swift adds some nice features too that aren’t available in C/C++. Pointers can understand and introspect their pointees. I can walk around a pointer in memory, then ask the pointer, what kind of memory is this, and then return it in that type, or or increment the pointer by the length of the pointee. Neat (and safe) stuff.
2) Core isn’t maybe, but yes++. GCD/Libdispatch has been available on other platforms since the open sourcing of Swift. We use it on Linux. It is several levels of sophistication, safety management, flow control, and small task issuance over and above threads.
3) Simple syntax. There is no doubt that Go’s goal is syntactic simplicity. Swift’s goal is to be a powerful all-in-one multi-paradigm toolbox. But Swift isn’t C++ either. It was built around the idea of Progressive Disclosure. You can start writing swift with 1 line in a RPEL: print(“Hello”)… done. Simple as python. complexity builds with expertise.
There’s a typo in this sentence: “I think there will be no disagreement that C and C++ and system programming languages”
Do you mean “I think there will be no disagreement that C and C++ are system programming languages”?
Indeed.
Have you heard of Vala?
It compiles to C and uses reference counting.
You missed Julia and Chapel
It was unfair that you removed Rust from the list, and put Swift (Apple) and Go (Google) inside. As I understand if you added Rust to the list you should remove them almost in each sections. Sorry to mention but it is too much commercial oriented article.
And also for high-performance things we used cython that you can call it pythonic-C and you can do whatever you like with real high-performance and embed it inside Python. I understand that python class is different but removing Rust in favor of that mostly Go it is just fun, there is an OS written in Rust man :/
Sorry to mention but it is too much commercial oriented article.
I want to build software that businesses will use. If that is what you mean by “too much commercial oriented”, then I am guilty of that.
And also for high-performance things we used cython that you can call it pythonic-C and you can do whatever you like with real high-performance and embed it inside Python.
That is true, but in these instances Python is using C as the high-performance language.
I understand that python class is different but removing Rust in favor of that mostly Go it is just fun, there is an OS written in Rust man :/
At least in January 2017, I felt that Rust was too much of a niche language. Things have changed since then and I consider Rust as a more serious contender now.
Hello Daniel,
Just a few pointers to interesting resources:
– GraalVM (http://www.graalvm.org/) backed by Oracle. You could write code in n languages and run it on the new SubstrateVM. Or you could compile Java code to binary, high speed & low memory executable format.
On this front please read this blog article: 10 Things To Do With GraalVM (https://chrisseaton.com/truffleruby/tenthings/)
FN project(https://fnproject.io/), also backed by Oracle; write a function in Java/GO/Python/Scala/JS/Ruby and then pack it in a tiny container.
PARLANSE language by Semantic Design (http://www.semdesigns.com/Products/Parlanse/index.html?Home=Main)
Chapel Parallel Programming Language (https://chapel-lang.org/) backed by Cray
my favorite under the radar language is pony (https://www.ponylang.io/)
Regards,
Cristian.
Something is interesting about the GrallVM vs non-Grall benchmark there. Grall runs it in:
real 0m17.367s
user 0m32.355s
sys 0m1.456s
While non-Grall takes:
real 0m23.511s
user 0m24.293s
sys 0m0.579s
So yes, it’s running in about 73% of the wall clock time as HotSpot (assuming the second run is HotSpot), but it takes about 36% more CPU! So you can’t really argue that the GrallVM is more efficient in this benchmark, but rather that it finds some way to run on about 2 cores on average, while the other benchmark runs on only ~1, and this additional parallelism is able to overcome its CPU-time inefficiency.
There doesn’t look like any inherent parallelism in the benchmark itself (unless Grall has some magic autopar going on), so maybe it’s a different in garbage collection?
Dropbox is actually powered by Rust as well as NPM, and a whole lot more.