MoarVM | Hacker News Reader

MoarVM

moarvm.com

103 pointsz3phyr36 comments

I feel like I should know more about it since I spent so much time writing Perl in the 90's, contributing modules to CPAN, etc. It seemed like the de-facto language for dynamic web sites for a while. I have to admit I never fully understand what Perl 6 was going to be. It seemed like it was going to be a language-agnostic runtime. Then it seemed to become a spec with no implementation. After a while I sorta lost track.

Have things changed and Perl 6 is ready for production? Are there people building things with Perl 6?

That really depends. If you need a richful module ecosystem then you won't be that lucky. But if your task would be doable with the many built-ins (and the modules shown on modules.perl6.org), then I'd say use it. I see that I am way more expressive and faster to solve tasks in Perl 6 then, say. Perl 5. (Besides I have to hack PHP at work in many cases. rant!)

And yes, there are ppl who use it for production, but I am not sure that matters much when there tasks might be totally different to yours?

Without looking it up my recollection was that python 3000 and perl 6 would target parrot. I recall hacking on parrot back when it was new but now i doubt anyone I ever worked with uses perl6. Plenty of good reasons for all this. Language adoption requires stability or the appearance thereof.

reading the perl6 monthly logs perl seemed to stay true to it's swiss army chainsaw philosophy. it almost looked like almost every programming language feature you would think of would eventually end up in perl. ofc this was the idea i got a couple years back.

but read kbd's comment below or the mailing someone else posted.

http://lists.parrot.org/pipermail/parrot-dev/2013-February/0...

parrot was to be the perl6 vm, but that never happened. it become too much at the same time

so they tried to fork off parrot:

> However, even if you remove the baggage and optimize for Rakudo (or rather NQP) integration, Perl6-on-Parrot will still be a 2nd-class citizen as long as no one replaces the PMC-based object system with 6model, which is imo a major undertaking; it might be easier to restart from scratch and fix other 'mistakes' along the way. That's where Parrot2 comes in

so no i don't think perl 6 is ready for production. that said, i thought it was it a cool language. even though i'm not sure if there was a clear direction of where it was going.

> that said, i thought it was it a cool language. even though i'm not sure if there was a clear direction of where it was going.

Why are you using past tense? When you skim the last year here you cannot say that Perl 6 is dead: https://github.com/rakudo/rakudo/blob/nom/docs/ChangeLog

(Instead there are some exciting things to read there, at least exciting for me :o)

Language features rank, for me, below language as community stability. That's why perl5 is a viable option: it's super stable and cpan is great.

Perl 6 isn't production ready in the same sense Perl 5 is production ready.

But you can test bulk of the language features. Agreed that the stage of affairs are no way close what one describe as a commonly accepted definition of production ready.

I won't give a timeline especially when I'm not working on it in any way. But I guess they are pretty close in making a production ready release.

Perl6 reminds me of the BeOS clones out there. It makes me nostalgic and I want to click on the links to see what is going on with it... but ultimately it seems like it will never amount to much.

Perl, BeOS, Amiga, etc. had their time. They were really cool in what they accomplished in their day, but most of us moved on.

Are there any BeOS clones besides Haiku?

Any living ones? There was Zeta Neo from YellowTab, they sold CDs for a period of time and I got one. There's this section on Wikipedia if you want to look into it:

http://en.wikipedia.org/wiki/BeOS#Continuation_and_clones

I wouldn't call Zeta any more a clone of BeOS than eComStation is a clone of OS/2. It used the same codebase.

Perl 6 is what happens when you try to rewrite a long-established and mature piece of software from scratch--that is: it's going to take years longer than you planned, it won't be remotely backwards compatible, it probably won't even do the same stuff, and it will end up souring lots of people on the old and new versions. I've seen it happen time and again.

Exactly. So you always have two choices:

1) Just update a little step by step. Here you would keep your userbase until there is a piece of software after a decade that will take a high percentage of that userbase.

2) Do a rewrite that takes three times longer than planned and split your userbase in half for the old and the new version. You can just pray that the new version is worth it.

So in a sense you will do the wrong and the right thing at once.

Interesting tidbit, MoarVM reuses libuv, the core of Node.js. The whole design seems very goal oriented, yet has all the features you'd expect from a modern VM, from Unicode to threads. Looks promising.

> libuv, the core of Node.js

It really amuses me that most people know libuv via Node.js. The library is the single greatest innovation of Node.js, having failed to achieve thread safety, and it's now powering both Julia and Rust. For many, many years, there was libevent, and then libev, and finally libuv—the event loop runtime finally hit production grade. If you know anything about Node.js, you should know libuv; javascript is pretty useless without asynchronous event processing.

> the event loop runtime finally hit production grade

The event loop has been production grade for a very, very long time, via kqueue, completion ports, and poll/epoll. Plenty of software takes advantage of these interfaces. Having a good cross-platform userspace wrapper is just icing on the cake.

Sorry, I should revise what I said: cross platform event looping hit production. Otherwise the platforms are just too different: POSIX doesn't help us here.

> it's now powering both Julia and Rust.

And neovim. https://github.com/neovim/neovim

That is the whole point, yes. It will get no features that are fun to implement but won't help Rakudo (Perl 6) to run on it.

What ever happened to the Parrot VM?

It’s practically dead:

http://lists.parrot.org/pipermail/parrot-dev/2013-February/0...

It's so sad. Parrot was conceived to be Perl 6's VM. Then the authors of Parrot decided to focus on making it more general purpose/language-independent, spent time writing incomplete implementations of various languages like Javascript on it, and ultimately didn't support any language well.

Parrot became so hostile towards its original purpose that Rakudo had to break from it.

Incidentally, I don't know why Perl folks don't implement Perl 6 on top of PyPy, which is a high quality dynamic language VM that already exists, and offers a JIT compiler to boot.

Because (and that's a quote) "PyPy is unproven and experimental technology".

I'm probably killing the joke, but what makes this absolutely great is that this is a reason for Perl 6 not to use PyPy

Developing an experimental language is a huge effort. And that effort becomes much larger if the underlying runtime environment causes problems.

So either you need a proven, stable VM (JVM, .NET, mono, ...), or you need to have control over it, so that you can fix problems you encounter.

Basing it on an experimental VM that you don't have control over, and that might have slightly conflicting goals (dynamic vs. gradually typed, for example, different calling conventions for routines) is precisely the problem we had with parrot, and we don't want to replace the parrot problems with pypy problems, we can avoid it :-)

RPython is a framework for writing VMs.

You write an interpreter for your language in RPython (a statically typed language with syntax that is a subset of Python's) and the framework generates a VM with a JIT and GC and so on. You have full control over whatever happens in your interpreter, you can give the JIT hints and having types too early will not hinder the JIT.

You also keep calling it experimental, but PyPy is a production-ready Python VM, which is more than one can say about Parrot or even Perl6.

PyPy is production ready now, but that's actually a fairly recent development. I first heard about peel 6 in 2007, well before PyPy could have been predicted to work. Python barely had Psycho going for it. ParrotVM was the original form of PyPy, in some ways, and it just turned out to be too massively ambitious for a community that was already beginning to dwindle.

My point was that Perl6 and Parrot are still experimental.

Which PyPy problems did you have in mind?

The main reason not to use PyPy is that Perl 6 is a gradually typed language, that is some type information is available at compile time. And that makes PyPy a less-than-ideal target platform.

(It actually seems that runtime environments that are optimized for statically typed languages, but have some support for dynamic stuff, suit Perl 6 better than dynamic runtimes. The CLR and JVM backends have the best run time performance so far, but they suffer from large startup times, which is something that the Perl community is very sensitive to).

rurban is working hard these days to make Parrot fast again. Let's check again in a month to see how this went out :o)

It's... an ex-Parrot?

Sorry...

parrot is definitely not dead. Some people left. It has some architectural problems (missing 6model and slow method calls) and had to survive some destruction done over the last years, but it had a good jit and has better threads than moar, which will bite moar sooner or later.

parrot threads are essentially lock-less and scale linearly, moar threads are traditional, they lock on every single hash, array or object access.

The parrot jit will come back soon. And I just fixed all internal compiler optimizations, so parrot -O2 is safe again.

On the other hand, the moar GC and calling convention is better than parrot, their new GC is a copying one, similar to the third vm targetting perl, p2 on potion. http://perl11.org/p2/

Favorite VM name ever.

BeerVM was also considered as a name :o)

Might be a clever reference to Smalltalk VMs? ST had SOAR VM, and now RoarVM

Reply on news.ycombinator.com