4 ms·

The headline is misleading in my opinion. You can't just write workers in Python now. Instead, they are providing a template for how you could call an existing

The headline is misleading in my opinion. You can't just write workers in Python now. Instead, they are providing a template for how you could call an existing Python-to-JavaScript transpiler to convert your Python code into JavaScript. They still only run JavaScript. So instead of writing your worker in JS, you get to write it in a Python syntax except all the functions you calls are still to JS functions, some of the syntax is non-standard, and most of the Python standard library is missing. I don't think many people are going to be terribly excited by that. You just get more headaches with very little upside. It's more like a neat demo than something you would want to seriously use.

throwgeorge 6y ago
can you use webasm with cloudflare workers?
elithrar 6y ago
Agree - I do think they have something novel with Workers, but with the upsides (small overhead, SW-like API, WASM) comes downsides (poor native multi-lang support, JS API drives other languages). But this announcement is all “man behind the curtain”: you’re not really writing Python, but instead JavaScript-as-Python, without any of the good parts of Python or modern JavaScript. Instead you’re likely to end up with a Franken-program that is neither. As a way to appeal to some users, sure: this would have been a solid set of guides/tutorials on the edge of what they support. But as a major announcement, it feels like Cloudflare is trying to trick users into seeing Workers as something it’s not.
throwaway894345 6y ago
Also, it has to fit in < 1 MB, and you won't be able to import anything that uses C extensions. Considering how bloated Python projects are (no dead code elimination whatsoever), I don't expect this to be very usable in practice. I wonder why they don't target WASM in addition to JS? In the latter case, anything that compiles to WASM would be fair game (I still wouldn't recommend Python in that case, but it would at least be less kludgy for other languages).
- eat_veggies 6y ago
  cloudflare workers does support wasm! I've written workers in C before and compiled them with emscripten. Check this one out: I was able to compile the lua interpreter to wasm in order to run lua code on the fly with a worker. It's absolutely a stupid toy but it's still pretty fast, and gives you a decent idea of just how powerful workers can be. https://github.com/veggiedefender/lhp https://github.com/veggiedefender/lhp
kentonv 6y ago
Agreed that it's far from perfect, and there's a lot of work to be done to make sure all the common native code libraries are well-supported. But, what I find really interesting is, we are finding it a lot easier to transpile other "managed" languages to JavaScript than to target WebAssembly. Building Python to Wasm hasn't worked well so far because the code footprint is quite large, and brings with it a whole language runtime including interpreter, garbage collector, API glue, etc. Whereas if we transpile to JS, we get V8's built-in GC, and it's much easier to call into existing high-level JS APIs. The result is nice, low code footprint, which can be distributed to thousands of edge nodes at low cost and can start up very quickly. Both transpiling and Wasm approaches come with challenges when you want to support native-code extensions: the corresponding native library itself needs to be ported to Wasm. (Once it has, then it can be called by Wasm code or JS code, so it seems like whether or not the rest of the app is Wasm or transpiled is not critical.) There are plans to extend Wasm to support built-in GC. Maybe then Wasm will make sense for managed languages. But, right now we're seeing Wasm is best-suited to C/C++/Rust, while transpiling is a better way to support most other languages. (I'm the tech lead for Workers, though I wasn't directly involved in this specific project.)
- ageitgey 6y ago
  I totally understand that CPython is too heavy to build for WebAssembly and the limitations of Transcrypt are very reasonable for what the Transcrypt project is aiming to do. It's neat that it works at all as a backdoor way to run some Python-looking code on CF and it's a cool OSS project. But I also don't think that a light transpiler is ever going to get anywhere close to a "real" Python developer experience. Python has an enormous standard library and Transcrypt implements almost none of it. The standard library is core to what makes Python Python. If I can't use any of the built-in functions that I know and love, I don't think it's really fair to claim I'm using Python except in a very superficial way. I think the disappointment is that I was excited to have an alternative to Google Cloud Functions and AWS Lambda (which both more or less support Python "for real"). This feels more like 20% support in my opinion.

throwgeorge 6y ago

can you use webasm with cloudflare workers?

elithrar 6y ago

Agree - I do think they have something novel with Workers, but with the upsides (small overhead, SW-like API, WASM) comes downsides (poor native multi-lang support, JS API drives other languages). But this announcement is all “man behind the curtain”: you’re not really writing Python, but instead JavaScript-as-Python, without any of the good parts of Python or modern JavaScript. Instead you’re likely to end up with a Franken-program that is neither. As a way to appeal to some users, sure: this would have been a solid set of guides/tutorials on the edge of what they support. But as a major announcement, it feels like Cloudflare is trying to trick users into seeing Workers as something it’s not.

throwaway894345 6y ago

Also, it has to fit in < 1 MB, and you won't be able to import anything that uses C extensions. Considering how bloated Python projects are (no dead code elimination whatsoever), I don't expect this to be very usable in practice. I wonder why they don't target WASM in addition to JS? In the latter case, anything that compiles to WASM would be fair game (I still wouldn't recommend Python in that case, but it would at least be less kludgy for other languages).

eat_veggies 6y ago
cloudflare workers does support wasm! I've written workers in C before and compiled them with emscripten. Check this one out: I was able to compile the lua interpreter to wasm in order to run lua code on the fly with a worker. It's absolutely a stupid toy but it's still pretty fast, and gives you a decent idea of just how powerful workers can be. https://github.com/veggiedefender/lhp https://github.com/veggiedefender/lhp

kentonv 6y ago

Agreed that it's far from perfect, and there's a lot of work to be done to make sure all the common native code libraries are well-supported. But, what I find really interesting is, we are finding it a lot easier to transpile other "managed" languages to JavaScript than to target WebAssembly. Building Python to Wasm hasn't worked well so far because the code footprint is quite large, and brings with it a whole language runtime including interpreter, garbage collector, API glue, etc. Whereas if we transpile to JS, we get V8's built-in GC, and it's much easier to call into existing high-level JS APIs. The result is nice, low code footprint, which can be distributed to thousands of edge nodes at low cost and can start up very quickly. Both transpiling and Wasm approaches come with challenges when you want to support native-code extensions: the corresponding native library itself needs to be ported to Wasm. (Once it has, then it can be called by Wasm code or JS code, so it seems like whether or not the rest of the app is Wasm or transpiled is not critical.) There are plans to extend Wasm to support built-in GC. Maybe then Wasm will make sense for managed languages. But, right now we're seeing Wasm is best-suited to C/C++/Rust, while transpiling is a better way to support most other languages. (I'm the tech lead for Workers, though I wasn't directly involved in this specific project.)

ageitgey 6y ago
I totally understand that CPython is too heavy to build for WebAssembly and the limitations of Transcrypt are very reasonable for what the Transcrypt project is aiming to do. It's neat that it works at all as a backdoor way to run some Python-looking code on CF and it's a cool OSS project. But I also don't think that a light transpiler is ever going to get anywhere close to a "real" Python developer experience. Python has an enormous standard library and Transcrypt implements almost none of it. The standard library is core to what makes Python Python. If I can't use any of the built-in functions that I know and love, I don't think it's really fair to claim I'm using Python except in a very superficial way. I think the disappointment is that I was excited to have an alternative to Google Cloud Functions and AWS Lambda (which both more or less support Python "for real"). This feels more like 20% support in my opinion.