5 ms·

The Rakudo compiler targeting MoarVM is also "finished" in the sense I expect it would take you a while to find something not implemented from the spec. More ad

The Rakudo compiler targeting MoarVM is also "finished" in the sense I expect it would take you a while to find something not implemented from the spec. More advanced things like concurrency and parallelism features are ready, and there are even nice things built out of them like the Cro microservices framework https://cro.services/ https://cro.services/. You can also build applications with Cro using full integration with a JetBrains based IDE https://commaide.com/ https://commaide.com/, which feels like a level of maturity and support someone might expect of a finished product? Thats the real myth, is someone can read this article and still not realise Perl 6 is an entirely useful and complete language with a good implementation and nice tooling.

geofft 7y ago
Then the article should say that, not just say that the Platonic ideal of Perl 6 is well-defined in the writings of the prophet Larry.
cutler 7y ago
... but still dog slow. Sorry, it matters.
- omaranto 7y ago
  Ruby is reasonably fast now, but when it became popular it still was very slow. So while speed definitely matters, maybe its lack is not an insurmountable obstacle.
  - cutler 7y ago
    The competition is a lot hotter these days.
    - KirinDave 7y ago
      Is it? It seems like the scripting language world is incredibly stagnant these days. Can you name an "up-and-coming" scripting language?
      - pantalaimon 7y ago
        Maybe that's because scripting languages are a bad idea for anything performance critical anyway - and experience has shown that even if things are not performance critical initially, they might become eventually. So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?
        kitotik 7y ago
        Time to market.
        simonh 7y ago
        Performance just isn’t the only, or always the most important factor when choosing a language. Sometimes we choose a language and it’s ecosystem for factors we know we value right now, rather than ones we might value later on.
        KirinDave 7y ago
        > Maybe that's because scripting languages are a bad idea for anything performance critical anyway This is an example of how programming as a discipline and activity is consistently dismissed by the software community as an unnecessary contrivance. "What about absolute performance?" But the reality is you're making tons of those tradeoffs. You're using a compiler, on an instruction set designed for humans, leaning on network stacks that do work for you in generic but sub-optimal ways, using container systems that introduce huge performance penalties. Those are socially acceptable to you. They're special in that you think they aren't special. > So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place? This assumes they are in fact equally capable. Please don't retort with Turing completeness. That's a copout and we all know you aren't about to go shipping things in BF.
        nrdvana 7y ago
        Or they go the other way, after an initial assumption that the task was performance-critical when in fact a scripting language was perfectly capable and took 1/10 the effort to write. https://opensource.com/article/18/1/my-delorean-runs-perl https://opensource.com/article/18/1/my-delorean-runs-perl
    - microwavecamera 7y ago
      All of the popular interpreted languages we use now were dog slow when they originally came out and we still had to deal with many the quirks of low level languages back then but here we are. If you don't like it just don't use it.
      - acdha 7y ago
        This really depends on the task in question and which languages you were comparing it to. Back in the day it was fairly common to have Perl, PHP, Python, etc. outperform languages like C in cases where the task complexity meant that the C programmer had been so busy debugging that they never got around to implementing a better algorithm which required more complex code, or it turned out that the C code behind the Perl regex engine, Python list/dict, etc. already had those optimizations. Java and C++ were compiled but back then the implementations were far less mature and it was easy to find cases where they underperformed in cases which should have been easy on paper. Not having a package manager really favored languages with one or a strong standard library since the alternative was often someone doing a quick naive implementation and never getting around to significant optimizations. The other thing to remember is that in the pre-SSD era it was much easier to be I/O-bound, masking most of the differences.
        b2gills 7y ago
        Someone once posted Perl6 and C/C++ code to #perl6 on freenode.net According to them, Perl6 was faster. (The Perl6 code was also a lot shorter, and I could argue it was easier to understand.) --- My guess is that the reason was that the C/C++ code had to scan for null terminators often, and copy strings around. (Or perhaps more precisely the stdlib had to do that.) MoarVM doesn't use null terminated strings, and it treats strings as immutable objects. If you do something like create a substring, it creates a substring object that points into the original string. So rather than copying a bunch of data it basically just creates a pointer. (Strings are technically immutable in Perl6, it is easy to assume otherwise though.)
- KirinDave 7y ago
  Compared to Python? They're like, comparable no?
  - cygx 7y ago
    Depends: Some things can still be really (and I mean really) slow. For example, I've been complaining about the speed of the regex/grammar engine for years. On the upside, the parallelism story is better than Python's or Perl5's.

geofft 7y ago

Then the article should say that, not just say that the Platonic ideal of Perl 6 is well-defined in the writings of the prophet Larry.

cutler 7y ago

... but still dog slow. Sorry, it matters.

omaranto 7y ago
Ruby is reasonably fast now, but when it became popular it still was very slow. So while speed definitely matters, maybe its lack is not an insurmountable obstacle.
- cutler 7y ago
  The competition is a lot hotter these days.
  - KirinDave 7y ago
    Is it? It seems like the scripting language world is incredibly stagnant these days. Can you name an "up-and-coming" scripting language?
    - pantalaimon 7y ago
      Maybe that's because scripting languages are a bad idea for anything performance critical anyway - and experience has shown that even if things are not performance critical initially, they might become eventually. So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place?
      - kitotik 7y ago
        Time to market.
      - simonh 7y ago
        Performance just isn’t the only, or always the most important factor when choosing a language. Sometimes we choose a language and it’s ecosystem for factors we know we value right now, rather than ones we might value later on.
      - KirinDave 7y ago
        > Maybe that's because scripting languages are a bad idea for anything performance critical anyway This is an example of how programming as a discipline and activity is consistently dismissed by the software community as an unnecessary contrivance. "What about absolute performance?" But the reality is you're making tons of those tradeoffs. You're using a compiler, on an instruction set designed for humans, leaning on network stacks that do work for you in generic but sub-optimal ways, using container systems that introduce huge performance penalties. Those are socially acceptable to you. They're special in that you think they aren't special. > So why would you write anything in a scripting language only to rewrite it later in a compiled langue, if you could have used an equally capable compiled language in the first place? This assumes they are in fact equally capable. Please don't retort with Turing completeness. That's a copout and we all know you aren't about to go shipping things in BF.
      - nrdvana 7y ago
        Or they go the other way, after an initial assumption that the task was performance-critical when in fact a scripting language was perfectly capable and took 1/10 the effort to write. https://opensource.com/article/18/1/my-delorean-runs-perl https://opensource.com/article/18/1/my-delorean-runs-perl
  - microwavecamera 7y ago
    All of the popular interpreted languages we use now were dog slow when they originally came out and we still had to deal with many the quirks of low level languages back then but here we are. If you don't like it just don't use it.
    - acdha 7y ago
      This really depends on the task in question and which languages you were comparing it to. Back in the day it was fairly common to have Perl, PHP, Python, etc. outperform languages like C in cases where the task complexity meant that the C programmer had been so busy debugging that they never got around to implementing a better algorithm which required more complex code, or it turned out that the C code behind the Perl regex engine, Python list/dict, etc. already had those optimizations. Java and C++ were compiled but back then the implementations were far less mature and it was easy to find cases where they underperformed in cases which should have been easy on paper. Not having a package manager really favored languages with one or a strong standard library since the alternative was often someone doing a quick naive implementation and never getting around to significant optimizations. The other thing to remember is that in the pre-SSD era it was much easier to be I/O-bound, masking most of the differences.
      - b2gills 7y ago
        Someone once posted Perl6 and C/C++ code to #perl6 on freenode.net According to them, Perl6 was faster. (The Perl6 code was also a lot shorter, and I could argue it was easier to understand.) --- My guess is that the reason was that the C/C++ code had to scan for null terminators often, and copy strings around. (Or perhaps more precisely the stdlib had to do that.) MoarVM doesn't use null terminated strings, and it treats strings as immutable objects. If you do something like create a substring, it creates a substring object that points into the original string. So rather than copying a bunch of data it basically just creates a pointer. (Strings are technically immutable in Perl6, it is easy to assume otherwise though.)
KirinDave 7y ago
Compared to Python? They're like, comparable no?
- cygx 7y ago
  Depends: Some things can still be really (and I mean really) slow. For example, I've been complaining about the speed of the regex/grammar engine for years. On the upside, the parallelism story is better than Python's or Perl5's.