Although this began as a usual book review, it quickly grew into an
all-encompassing article as a result of the additional and extended
While concurrency is always covered as part of a book on SQL Server,
this title is totally dedicated to it. Exaggerated one might say; quite
the opposite and with good reason I would say. It aims to raise
awareness of this frequently underrated subject whose incomprehension
can result in massive performance complications.
The problem lies in that no matter how well designed your
application, database, or SQL queries are, all working harmonically in
isolation, going multi-user without putting considerable effort into
understanding concurrency (and how your specific DBMS goes about it),
will sooner or later lead your edifice into collapsing, shaken by
performance degradation, unacceptable waiting time or even corrupted
So this is where this slim guide comes in, to properly educate anyone
working with the RDBMS in k…
NV: The JVM has been primarily designed with statically typed
languages in mind. The same goes for the CLR, and that is why the DLR
(build on top of CLR) came into existence. Have you at some point
considered the DLR (maybe combined with Mono instead of the CLR) or
JVM’s Dynalink, both of which admittedly have a good Meta Object
protocol infrastructure, as a potential backend to Rakudo?
JW: One interesting thing to note about Perl 6 is
that it’s a gradually typed language, which means the considerations
are a little different from if it was dynamically typed. In that sense,
VMs which explicitly seek to do both static and dynamic typing well are
especially interesting for Perl 6.
I can’t speak too well to the DLR, but I do know that Niecza, the
Perl 6 on CLR implementation, went the way of not using it for a range
of reasons. By contrast, the JVM’s invokedynamic instruction has been
rather interesting from a Perl 6 implementation point of view.
Dynalink is certainly of …
NV: What does that say about the JVM’s project’s life
expectancy? Will it run in parallel with MoarVM’s development? Does all
this forecasts Parrot’s demise?
JW: The JVM is playing that difficult “second
backend” role. Going from one target VM to two exposes all kinds of
assumptions, such as places where things are not sufficiently well
abstracted and so forth. Such abstractions are not easy to design
because you’re not only thinking about how to hide differences, but how
to convey enough semantic information downwards in order to allow good
Having the second VM that is already mature and well established is a
huge help. OK, I did manage to segfault the JVM thanks to the odd
invokedynamic bug I managed to hit upon. But by and large, if something
is wrong, I can be pretty sure that the JVM itself will not be to blame.
So, the JVM porting leads the way.
That naturally means we’ll get to a rather complete Rakudo on JVM some
way ahead of getting there with …
The latest news is that Parrot Virtual Machine is no longer the only one enjoying Rakudo’s exclusivity.
Not long after Rakudo had been successfully ported to the JVM a new
hosting candidate that aims to change the rules of the game, MoarVM,
All that activity has raised a lot of questions regarding Parrot, Rakudo and the direction Perl 6 is heading for: Is Parrot dead ? Why yet another VM and what’s up with the JVM?How does Perl 6 stack up against other modern languages like C# ?Is there any room in the programming world for it, after all?
For getting the definitive answers to these intriguing questions,
we’ve managed to get hold of Jonathan Worthington for an exclusive
interview. Jonathan is the architectural mastermind and primary driving
force behind not only Rakudo’s implementation, but also all the projects
revolving around it, such as NQP, the port on the JVM, and now the
brand new MoarVM.
As if simultaneously engaging in these cognitively demanding