It's been 20 years so my information could be very much out of date, but at that time anyway I would not have said this statement was true. C++ then was a superset of C, and any C++ compiler was capable of compiling ANSI C.
int new;
would not compile in C++. int *x = malloc(sizeof(int) * 15)
is legal c, but in c++ you would have to cast the malloc call. Also, type of character literals is int in c but char in c++. String literals are const only in c++. Functions that take no arguments must be declared as taking void (as in void func(void)) in c, but simply () in c++.I know proficient Python programmers who were starting projects from scratch in 2017 and didn't want to use Python 3.x because they were in a hurry, worried that they didn't know how to write Python 3.x in a timely manner because they hadn't invested the time to learn it. Lots and lots of people just knew it was a known unknown for them, had no idea of the magnitude of the effort required to switch (tiny for new projects! tiiiny) and just put "look into this" somewhere deep on their backlog.
I vaguely remember that, when Perl 6 was first announced, the idea was that it would be able to run unmodified Perl 5 programs (and not only that, but it would also be able to mix Perl 5 and Perl 6 modules in the same program).
Note that you can mix the languages in the same program, but it's no different than the capability of such modules as Inline::C and Inline::Python in Perl, and doesn't actually involve natively implementing a Perl interpreter.
Except, you know, rampant incompatible syntax. Being invented by the same person and having an overlap of desirable features doesn't make it the same language, in the same way that C# is not Delphi.
> Perl 6 performance has now gotten to the point where it's often comparable to Perl 5 or surpasses it. It still needs some work in this area, but the work is clear, the goals are straightforward, and Perl 6 is going to easily oustrip Perl 5 in terms of performance. If the Perl 6 community wants to rename, it's perhaps the perfect time to do so. It doesn't look like a bad choice if performance is a primary concern.
Shrug.
Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.
Performance has been enhanced by a few factors since it was released in 2015.
For a lots of things the next stable release (as soon as the latest round of optimization have been merged) will be on par with perl5 / ruby / python ...
The main slow thing remaining is Grammars which if I understand correctly are not available in those other languages to compare speed, but that is next on the road map for optimization.
Here is a recent talk about the state of perl6 performance: https://www.youtube.com/watch?v=QNeu0wK92NE
I've been writing perl for twenty years, and while I love its practical expressiveness (higher than any other language currently in use, as an objective measure), I've frequently wished it had better performance and lower memory footprint.
The go-to solution for that has been to profile one's code and rewrite the critical path in C, with which perl interfaces readily. It's the same story with python -- very expressive, but slow and fat (slower and more memory-hungry than perl, even), with easy C integration as the common solution. C integration works, though it's less than ideal.
On the other hand, you're being a bit uncharitable by assuming the MoarVM developers aren't focusing on performance.
They prioritized getting it working -first-, but have since paid more attention to improving its run-time performance. Their efforts have already made considerable impact, with more on its way.
I've benchmarked its performance a couple of times, and it's still too slow to interest me, but will keep an eye on it. At some point there may be an inflection point which makes it a compelling alternative to other languages.
Though perl is still my bread-and-butter, and I've written python for a living and liked it, I've become quite infatuated with D of late. It's essentially C with some straightforward extensions and improvements, which gives it roughly 3x to 4x as much practical expressive power than C (but only about 1/3 the expressiveness of perl), and excellent support for casual parallelism, while matching C for run-time performance and small memory footprint.
Before I wrote perl for a living, I wrote C for several years, and D has "clicked" with me in a way that other languages have not. Learning python and Go was rough, but I muscled my way through them. Learning D hasn't been like that. It's actually pleasant to learn, and I find myself thinking about it when I really should be focusing on other things.
One thing D doesn't have is a lot of jobs. Maybe it will someday, but I expect to write perl6 for a living before writing D for a living (and expect to be writing perl and python for a living for a while before that).
Anyway, my point is that the MoarVM developers are actively working to give perl6 better run-time performance, and it is way too early to discount perl6 on account of its current performance.