Erlang Performance Lab

This looks very pretty from the screenshots and kudos for throwing out out there so apparently soon in its development; I might check it out (Erlanger here) but I would really like a better idea of what this thing does or some actual docs?

Download link is a .gz and the getting started page goes nowhere really?

When you make tools for developers, the really important bit is communicating why this thing is useful, and then how to use it right?

Love to see Erlanger tools and I'll be following you, but this seems a smidge immature....

How does it work out network use? Does it depend on certain behaviours? Does it simply make pretty things from trace?

This is great. I'm going to play around with it for an Elixir project.

I'd just like to say I found the homepage did a very good job of explaining the product. Good screenshots and well written summaries of each feature/benefit.

Edit: seconding the call for documentation. Also maybe a link to Getting Started at the top, that's seems like where I'd start vs downloading a .tar.gz without instructions.

Why would that make sense?

The gains you get for free using otp and the beam vm depend heavily around language integration of vm features. Porting python to a vm it would work slowly on and would be unable to use most of, if not all of, the benefits without changing the language would give you what exactly?

I'm not going to get too into this as I hope most readers understand why this couldn't work without needing much depth....

Python has no concept of a process like Erlang does. The standard library does even know about, let alone is able to deal with, the difference between cast and call messages. It can't do messages even. There is no way to translate monitors vs links. What's a node? .....

You could implement python syntax maybe, but python will never make sense on beam.

Not really. Erlang/OTP applications get the advantages they have by being what they are and that's not really something you can import as a library to a language which doesn't even have primitives those systems speak.

If it sounds like a good idea to do that when you are solving something horrible, then your better bet is to write that functionality in a beam language instead of trying to play beam in a language which can't do it.

This is a bit of a different world than most of us are used to. Porting python to the jvm or making it run on v8 are different goals than making something play in the beam space.

You could run single node python with a port to beam, but there would be no advantages to doing it. It would be slower and no one would use it. Beam langauges only get you something when you're doing distributed things really and python isn't equipped for playing those natively.

You could wrap it in some libs maybe, sure. But why would you?