Startup time is not the strong point of Rakudo. And it will be a long time before it will.
Beyond startup, performance definitely has attention of the core developers: that's when hot code gets inlined, and JITted to machine code if you're on Intel hardware. But before that, currently not so much.
The best possible startup time that could potentially be reached in the current implementation of Rakudo, is the bare startup time of NQP in which Rakudo is basically implemented. Compare NQP on an Intel 2.4 GHz i9 on MacOS:
% time nqp -e ''
real 0.04s
user 0.03s
sys 0.01s
with:
% time rakudo -e ''
real 0.15s
user 0.15s
sys 0.03s
With NQP taking about 16MB of memory.
Raku as a language is selected for its features, its community and possibly for its promise. Whether that is a disaster or not, is up to the user.
Finally, if you want fast startup, don't use a scripting language.
>Finally, if you want fast startup, don't use a scripting language.
Huh? Isn't startup speed one of the points of simpler, less optimized interpretation strategies? I mean, unless you compare it to AOT compilation, which is another story.
Those numbers show that Perl and Tcl, both "full featured" scripting languages, don't have the least issue on the matter.
I'm not the kind to freely rain on parades, especially when Raku is already not a popularity king, but I don't think my use of the word "disaster" was unfounded, even if not "very nice".
> those numbers show that Perl and Tcl, both "full featured" scripting languages, don't have the least issue on the matter.
Anybody using modern Perl will most likely also use Moose, and probably big integers as well. If you compare startup times with Perl / Moose / big integers with Rakudo (on the same Intel hardware as before):
% time perl -MMoose -Mbigint -e ''
real 0.20s
user 0.14s
sys 0.02s
% time rakudo -e ''
real 0.16s
user 0.15s
sys 0.04s
And suddenly, Raku starts up faster than Perl! Because Raku comes with a Moose like object system and big integers out of the box, it doesn't need to do anything special to give you those features.
So in a way, you're comparing apples with oranges when you're just comparing bare startup times. Because you are not considering the feature set you get with a bare startup.
The thing is you can chose to write perl in a way that doesn't suck. The problem with TMTOWTDI is that with 18 people in a code base.... well its best to have a set of conventions when writing perl. Let's all agree to use 5.x.x with these features for example
These days you can TMTOWTDI in Python as well though.
The TMTOWTDI argument was valid in very early stages of Perl vs Python debate, like some what between 2000 - 2006 etc.
These days Python is just Perl with mandatory tab indentation. Python is no longer that small language, with small set of syntactical features. C++/Java etc in the meanwhile have gotten even more TMTOWTDI heavy over the years.
I don't really work with python often enough but as for php there's usually one boring way to do it. We eschew generally more fun stuff like array operations because for loops work and the intent is vlear
> Fundamentally, Raku regexes are very much like subroutines...
And if they're part of a grammar, they're essentially methods on a class. And a class that can be sub-classed. Or have roles mixed in, consisting of regexes.
An ordinary identifier is composed of a leading alphabetic character which may be followed by one or more alphanumeric characters. It may also contain isolated, embedded apostrophes ' and/or hyphens -, provided that the next character is each time alphabetic.
Thanks for the link and the excerpt. Just out of curiosity, did the capitalized "NOT" was there because my above message was interpreted as a guess that `2-5-7` could serve as an identifier in Raku? That was not my belief nor what I tried to expose, to be clear on that point.
> Only for those grapheme clusters that do not have a representation in Unicode!
I think it's reasonable to consider a grapheme cluster composing one codepoint to be a codepoint, not a grapheme cluster. One grape is not a cluster of grapes.
> Also, these negative i32s are really an implementation detail.
What a coincidence! I was explicitly discussing the implementation.
Oh, is this the thing where some people pretend that Raku is different from Rakudo? Fine. Pretend I said Rakudo.
> Unless you want regexes to be a. correct in the unicode world, and b. be performant
I work extensively on low-level pattern matching code. So I can say with considerable confidence that blowing up every string to take up four bytes per codepoint or grapheme cluster, is not the only way to make regex correct in the unicode world, nor is it necessarily the best, or even helpful. The assertion that a regex search on a blown-up and custom-tailored string is going to be more performant than performing that search on the native UTF-8 representation of the string, is hard to justify. It's seems evident to me that it would be less so, by default.
Furthermore, I'm unsure how O(1) access to anything could aid regexen, since using them is O(n) by definition.
I think Raku is an interesting language and that people should check it out, to be clear. That doesn't mean I agree with every choice the Rakudo implementation has made.
> I think Raku is an interesting language and that people should check it out, to be clear
I agree :-)
> That doesn't mean I agree with every choice the Rakudo implementation has made
Indeed. Some of these choices have their roots in the late 1990's / early 2000's. Some of them make less sense now than they did then. FWIW, these are continuously evaluated by the current core team, to continue to improve Rakudo.
I really wish more people would use Raku :-) Because it is all built in there already! :-)
reply