5 ms·

I wish someone would port Python to BEAM. I'm actually surprised there isn't a project out there, except some really old stale project called beam.py I found on

I wish someone would port Python to BEAM. I'm actually surprised there isn't a project out there, except some really old stale project called beam.py I found on github, which hasn't been worked on since 2010.

cyberpunk 9y ago
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?
- 35bge57dtjku 9y ago
  No more GIL problems? What couldn't you do, say by making BEAM/OTP -specific features be a library you import in Python, and by mapping Python language features to however Erlang does them? I get there will likely be problems, but what specific problems would you run in to?
  - cyberpunk 9y ago
    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.
    - 35bge57dtjku 9y ago
      You can't accomplish all of that by making users import a library to use those things, like I said? Or at least enough of it to make it reasonably useful as a Python?
      - cyberpunk 9y ago
        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?
      - tormeh 9y ago
        BEAM is for distributed systems and MySQL is for databases. Porting Python to run on BEAM like Erlang does is like porting Python to run on MySQL like SQL does: Possible, but slightly surrealistic.
      - deleted 9y ago
        [deleted]
    - toast0 9y ago
      > 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? I don't know that Python on the beam is a good idea / worth the work, but I don't think there's a fundamental issue here: A process is more or less a thread, which Python already knows about. Cast is just sending a message, which is erlang:msg(Dest, Msg); call is send a message plus selective receive. General receive is easy, call a function (not already available) and return the message. Selective receive is trickier, because python doesn't have a construct for matching like Erlang, so you'd have to figure out how to specify the possible message signatures you'd like to receive; plus extra work to get the make_ref mailbox marking optimization. Monitors and links are just calling functions, and maybe being killed or getting specific messages later -- it's a VM feature, not a language feature. Same with a node. You would have to make some hard decisions about any pythonic state though. It would be more functionally pure to pass that around as a function argument, but it might feel more like python if it was stuffed into the process dictionary. Python state shared between multiple processes/threads would be forbidden, of course. Mutability would also need some soul searching to fit into Beam's garbage collection. EDIT to add: of course, you would need to restrict I/O to message passing -- anything with file descriptors should be rewritten to be message passing with beam ports.
      - cyberpunk 9y ago
        Well, I was a bit dishonest there and you've called it. Monitor/Link and Cast/Call are all built ontop of the regular message passing functionality of the language. The point I 'whitehat fibbed' to make stands though, python might be feasable as a syntax implementation but there's a _MASSIVE_ difference in the architecture of helloworld as a flask app and the same under cowboy; trying to get one to behave as the other makes no sense to me. Implementing a python on beam makes no sense as to actually benefit from beam you'd need to write a lot of libraries to actually play with the environment and why would anyone bother? And sorry but no, processes are not more or less threads. My laptop can do this: 3> processes:max(250000). Max allowed processes: 262144 Process spawn time=3.408 (15.644) microseconds Process teardown time=3.156 (1.552) microseconds That created 250k procs then stored the pids of each in a list, then iterated though that list and killed those processes; I don't think you can do that with threads.. Preemptive scheduling is a big deal also.
- thecity2 9y ago
  Have you heard of Mochi? "Mochi is a dynamically typed programming language for functional programming and actor-style programming. Its interpreter is written in Python3. The interpreter translates a program written in Mochi to Python3's AST / bytecode." https://github.com/i2y/mochi https://github.com/i2y/mochi If all that can be done in Python 3, surely it could be ported to run on BEAM to good effect.
sashaafm 9y ago
There's a BEAM language with Python Syntax I believe
- marianoguerra 9y ago
  I think you mean efene: http://efene.org/ http://efene.org/
jsnathan 9y ago
BEAM wasn't designed for OO languages where all values are mutable objects. It would be highly impractical to try to run Python on top of it. You'd have to create a Frankenstein interpreter to get anything working.
jchassoul 9y ago
There's Lua on the BEAM https://github.com/rvirding/luerl https://github.com/rvirding/luerl no need for Python.
plainOldText 9y ago
It's really not that hard to learn a new language. I love Python, it was the first language I truly loved, but now after over a year of writing a project in Elixir, I find the latter equally impressive, and even more elegant.
- thecity2 9y ago
  It's not hard to learn a new language but it is hard to port all the old libraries to that language.

cyberpunk 9y ago

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?

35bge57dtjku 9y ago
No more GIL problems? What couldn't you do, say by making BEAM/OTP -specific features be a library you import in Python, and by mapping Python language features to however Erlang does them? I get there will likely be problems, but what specific problems would you run in to?
- cyberpunk 9y ago
  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.
  - 35bge57dtjku 9y ago
    You can't accomplish all of that by making users import a library to use those things, like I said? Or at least enough of it to make it reasonably useful as a Python?
    - cyberpunk 9y ago
      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?
    - tormeh 9y ago
      BEAM is for distributed systems and MySQL is for databases. Porting Python to run on BEAM like Erlang does is like porting Python to run on MySQL like SQL does: Possible, but slightly surrealistic.
    - deleted 9y ago
      [deleted]
  - toast0 9y ago
    > 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? I don't know that Python on the beam is a good idea / worth the work, but I don't think there's a fundamental issue here: A process is more or less a thread, which Python already knows about. Cast is just sending a message, which is erlang:msg(Dest, Msg); call is send a message plus selective receive. General receive is easy, call a function (not already available) and return the message. Selective receive is trickier, because python doesn't have a construct for matching like Erlang, so you'd have to figure out how to specify the possible message signatures you'd like to receive; plus extra work to get the make_ref mailbox marking optimization. Monitors and links are just calling functions, and maybe being killed or getting specific messages later -- it's a VM feature, not a language feature. Same with a node. You would have to make some hard decisions about any pythonic state though. It would be more functionally pure to pass that around as a function argument, but it might feel more like python if it was stuffed into the process dictionary. Python state shared between multiple processes/threads would be forbidden, of course. Mutability would also need some soul searching to fit into Beam's garbage collection. EDIT to add: of course, you would need to restrict I/O to message passing -- anything with file descriptors should be rewritten to be message passing with beam ports.
    - cyberpunk 9y ago
      Well, I was a bit dishonest there and you've called it. Monitor/Link and Cast/Call are all built ontop of the regular message passing functionality of the language. The point I 'whitehat fibbed' to make stands though, python might be feasable as a syntax implementation but there's a _MASSIVE_ difference in the architecture of helloworld as a flask app and the same under cowboy; trying to get one to behave as the other makes no sense to me. Implementing a python on beam makes no sense as to actually benefit from beam you'd need to write a lot of libraries to actually play with the environment and why would anyone bother? And sorry but no, processes are not more or less threads. My laptop can do this: 3> processes:max(250000). Max allowed processes: 262144 Process spawn time=3.408 (15.644) microseconds Process teardown time=3.156 (1.552) microseconds That created 250k procs then stored the pids of each in a list, then iterated though that list and killed those processes; I don't think you can do that with threads.. Preemptive scheduling is a big deal also.
thecity2 9y ago
Have you heard of Mochi? "Mochi is a dynamically typed programming language for functional programming and actor-style programming. Its interpreter is written in Python3. The interpreter translates a program written in Mochi to Python3's AST / bytecode." https://github.com/i2y/mochi https://github.com/i2y/mochi If all that can be done in Python 3, surely it could be ported to run on BEAM to good effect.

sashaafm 9y ago

There's a BEAM language with Python Syntax I believe

marianoguerra 9y ago
I think you mean efene: http://efene.org/ http://efene.org/

jsnathan 9y ago

BEAM wasn't designed for OO languages where all values are mutable objects. It would be highly impractical to try to run Python on top of it. You'd have to create a Frankenstein interpreter to get anything working.

jchassoul 9y ago

There's Lua on the BEAM https://github.com/rvirding/luerl https://github.com/rvirding/luerl no need for Python.

plainOldText 9y ago

It's really not that hard to learn a new language. I love Python, it was the first language I truly loved, but now after over a year of writing a project in Elixir, I find the latter equally impressive, and even more elegant.

thecity2 9y ago
It's not hard to learn a new language but it is hard to port all the old libraries to that language.