11–20 of 28 posts
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.
Earlier quoted context omitted.
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…
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?
Earlier quoted context omitted.
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…
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?
Earlier quoted context omitted.
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?
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…
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.
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.
You'd have to create a Frankenstein interpreter to get anything working.
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.
Earlier quoted context omitted.
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…
> 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 thr…
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
Preemptive scheduling is a big deal also.
Earlier quoted context omitted.
> 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 thr…
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 othe…
I agree that it would be a lot different architecture than a normal python application; but where there could be value, is if you wanted to write a distributed thing in python with all the nice properties you get from an erlang system, your choices now are either drop python (my preference!); write dist/otp yourself, but in python (hard, because how do you bolt on monitors, etc); write just enough erlang to coordinate python running as port commands (probably doable, but could be fragile).
I personally would love to run a little bit of perl on the beam, but i know it's crazy, so I don't mention it very often ;)
Earlier quoted context omitted.
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 othe…
Yes, I know processes are different than threads, but the basic idea is similar -- a process is an execution context with its own stack and program counter and etc; so is a thread, but the etc differs. That python knows how to run in threads means it's at least got some of the basics that might enable it to run in multiple contexts, was my only point. I agree that it would be a lot different architecture than a norma…