4 ms·

> performance prevents it being taken seriously in production. Performance is a big one. Not focusing on performance is like a strategic mistake for a programm

> performance prevents it being taken seriously in production. Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.

windsurfer 7y ago
Ruby seems to be doing ok.
- chessturk 7y ago
  I agree, somehow we're not all writing everything in Rust yet. Maybe it's coming, but I doubt it.
patrickas 7y ago
That is exactly what the main architect of the compiler has been working on for the past couple of years. 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 https://www.youtube.com/watch?v=QNeu0wK92NE
- zzzcpan 7y ago
  Well, no, these are all slow interpreted languages. There is no reason to invest any time into another one just as slow in 2019.
  - Ultimatt 7y ago
    Wat? Consider Perl was created in 1987 when compute resources were things like the Apple II with a Motorola 68020 at 16 MHz with 4MB of RAM. Exactly what do you imagine was the reaction back then? Something being "interpreted" (which Perl 6 is not any more than C# or Java or JavaScript) simply doesn't matter given modern computers, and things like JIT at runtime are hugely valuable even in languages like C. Some interpretation is better than upfront compilation.
ttkciar 7y ago
On one hand, you're totally right. 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.
- cutler 7y ago
  Too early? In 4 months it will be 4 years since Perl 6 was released and it's still 5 times slower than Ruby at simple tasks like parsing a log file with a regex.

> performance prevents it being taken seriously in production. Performance is a big one. Not focusing on performance is like a strategic mistake for a programming language these days.

windsurfer 7y ago

Ruby seems to be doing ok.

chessturk 7y ago
I agree, somehow we're not all writing everything in Rust yet. Maybe it's coming, but I doubt it.

patrickas 7y ago

That is exactly what the main architect of the compiler has been working on for the past couple of years. 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 https://www.youtube.com/watch?v=QNeu0wK92NE

zzzcpan 7y ago
Well, no, these are all slow interpreted languages. There is no reason to invest any time into another one just as slow in 2019.
- Ultimatt 7y ago
  Wat? Consider Perl was created in 1987 when compute resources were things like the Apple II with a Motorola 68020 at 16 MHz with 4MB of RAM. Exactly what do you imagine was the reaction back then? Something being "interpreted" (which Perl 6 is not any more than C# or Java or JavaScript) simply doesn't matter given modern computers, and things like JIT at runtime are hugely valuable even in languages like C. Some interpretation is better than upfront compilation.

ttkciar 7y ago

On one hand, you're totally right. 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.

cutler 7y ago
Too early? In 4 months it will be 4 years since Perl 6 was released and it's still 5 times slower than Ruby at simple tasks like parsing a log file with a regex.