Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React, but in Python

github.com

Post reply on HN
Print view View original

131–140 of 179 posts

Re: React, but in Python

#131

Post by sitkack »

nonbirithm wrote: post #122
quickthrower2 wrote: post #73

Earlier quoted context omitted.

Yeah this seems to combine the worst of both worlds: react headscratching (e.g. why useEffect do this weird shit) and slowness of the phoenix style send it all back to the server. The solution? For python people: learn some JS and use django.

The most popular stable diffusion UI uses gradio, which is the same paradigm of defining a web frontend in the backend, and the performance just falls apart after the code reaches a certain size. The need for most interactivity to roundtrip to the server and back opens up tons of places where a bad connection could leave the whole app in a half-broken state. And beyond that, it's just slow . So much so that mobile us…

I mean, what if the app is only ever used by one person over localhost? Seems you would be blocked on access to the GPU, unless it also has GPU farm support?

Re: React, but in Python

#132

Post by lelanthran »

bb88 wrote: post #100
winrid wrote: post #92

Earlier quoted context omitted.

The Python GC is slow, but predictable. I've seen the Node runtime falls apart past like 8gb heap all the time, but I have python scripts that run just fine with a 32gb heap. Requiring the max old space flag is already too much. It's annoying. Python does indeed have some runtime type safety. Way more than any JS runtime I've used. And I've written way more Node/JS/TS than Python. In terms of the compiler, Nah. The w…

I spent a good chunk of last year learning go, and felt dumber for doing so. I feel like Rust is the way to go in 2023 and beyond -- particularly if the rustaceans can get past their own stupidity.

You cannot really compare Rust and Go.

Rust is for when you really need to perform manual memory management. If you don't need that, then a GC language is better.

If you're choosing manual memory management over GC, you better have a really good reason to do so or a really small application that you're writing.

Re: React, but in Python

#133

Post by remkop22 »

lelanthran wrote: post #132
bb88 wrote: post #100

Earlier quoted context omitted.

I spent a good chunk of last year learning go, and felt dumber for doing so. I feel like Rust is the way to go in 2023 and beyond -- particularly if the rustaceans can get past their own stupidity.

You cannot really compare Rust and Go. Rust is for when you really need to perform manual memory management. If you don't need that, then a GC language is better. If you're choosing manual memory management over GC, you better have a really good reason to do so or a really small application that you're writing.

Literally the whole point of rust is to not do manual memory management and let a compiler handle that for you.

Re: React, but in Python

#134

Post by robertlagrant »

crubier wrote: post #71

Controversial, but I think that rather than trying to make Web stuff (e.g. React) work in Python, a more fruitful direction would be to make ML stuff (e.g. PyTorch, OpenCV) work in Typescript. Javascript/Typescript is way faster than Python, is ubiquitous and can run pretty much everywhere, has many engine implementations, has an incredibly wide ecosystem, has a type system (Typescript) that blows any Python type sys…

Why not just implement a Typescript backend that outputs Python instead of Javascript? (-:

Re: React, but in Python

#135

Post by Elfir3 »

crubier wrote: post #89
zelphirkalt wrote: post #84

Earlier quoted context omitted.

The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter. Typically people will not use pip directly in serious projects, except for quick and dirty package installs to prototype something. In any serious project I would expect people to use any of the package managers, that support creating a lock file. But then NPM for example is not…

> But then NPM for example is not better than poetry. Poetry is good exactly because it copied the concepts from NPM / Yarn. It's almost a port of NPM to the Python ecosystem, 8 years later.

Poetry has more to do with pip and virtualenv than NPM to be honest.

Re: React, but in Python

#136

Post by lelanthran »

remkop22 wrote: post #133
lelanthran wrote: post #132

Earlier quoted context omitted.

You cannot really compare Rust and Go. Rust is for when you really need to perform manual memory management. If you don't need that, then a GC language is better. If you're choosing manual memory management over GC, you better have a really good reason to do so or a really small application that you're writing.

Literally the whole point of rust is to not do manual memory management and let a compiler handle that for you.

> Literally the whole point of rust is to not do manual memory management and let a compiler handle that for you.

Incorrect. The compiler forces you to handle memory properly. It doesn't, as far as I know, manage it for you.

The burden is on the programmer to do it correctly. The compiler stops the programmer from doing it incorrectly.

Compare with GC, where the programmer is freed from the burden of worrying about memory altogether.

Re: React, but in Python

#137

Post by innocentoldguy »

Stephen_0xFF wrote: post #130
uhtred wrote: post #2

I thought generating html from function calls went out with the dinosaurs. We back doing it again?

Still very much alive. This implementation with python, to me, doesn’t look promising, but Elixirs LiveView does.

LiveView is awesome. We've completely replaced React with LiveView and the user and developer experience is significantly better.

Re: React, but in Python

#138

Post by remkop22 »

lelanthran wrote: post #136
remkop22 wrote: post #133

Earlier quoted context omitted.

Literally the whole point of rust is to not do manual memory management and let a compiler handle that for you.

> Literally the whole point of rust is to not do manual memory management and let a compiler handle that for you. Incorrect. The compiler forces you to handle memory properly . It doesn't, as far as I know, manage it for you. The burden is on the programmer to do it correctly. The compiler stops the programmer from doing it incorrectly. Compare with GC, where the programmer is freed from the burden of worrying about…

I would make a distinction between managing memory (malloc, free) and then subsequently handling said memory in a safe manner.

The first part Rust does for you.

The second part you'll indeed have to do yourself and the compiler will force you to do it safely.

Re: React, but in Python

#139

Post by zelphirkalt »

laurencerowe wrote: post #99
zelphirkalt wrote: post #84

Earlier quoted context omitted.

The speed of the output of the compiler of the glue language almost does not matter. Whether it is Python or TypeScript, it will not matter. Typically people will not use pip directly in serious projects, except for quick and dirty package installs to prototype something. In any serious project I would expect people to use any of the package managers, that support creating a lock file. But then NPM for example is not…

pip supports lock files. https://pip.pypa.io/en/stable/cli/pip_freeze/

That is not a typical lock file. If it is, then it is a bad one. Lock files need checksums, not version numbers (oh well, both.). Version numbers do not protect from changes. At least not in all important cases or scenarios. I've had packages in the PHP world change their checksum and when I alerted them about it, they were like "So? We only changed some documentation of that version." ... Who knows what else people change in the same version. No. You need checksums.

Re: React, but in Python

#140

Post by whatyesaid »

devjab wrote: post #125
whatyesaid wrote: post #93

Earlier quoted context omitted.

JavaScript is a joke when you consider things like prototypes and classes. Not saying Python is perfect but JS really feels atrocious to me. TypeScript requires you to compile, the whole point of Python for ML and data science is you're running in an interpreted environment where you delegate as much code out as you can for both data processing and algorithms to invisible C++. The interpreted part is key as ML is abo…

We do with Typescript what a lot of people do with Python. Handle most things with Typescript and then contract off the really compute heavy parts to C\C++ (slowly moving to Rust). I’ve worked extensively with both Python and JavaScript and while we use Typescript because it’s much easier to setup an environment where your code is protected from you than it is with JavaScript you can actually do the same with JSDoc.…

Personally I only use SvelteKit which I find is nice by building around what the web technology currently is.

As for static types to be honest I don't see how it's useful in the context of ML. You might use a Pandas dataframe, which already comes with types enforced inside of it. You shouldn't ever use a for loop on a Pandas dataframe or whatever because then you're running Python instead of C++, Pandas has inbuilt functions and operators.

However Python does have type hints but probably not strict enough, Mojo may improve in this if it really supports both AOT and JIT.

Package management in Python isn't that bad with requirements.txt. The real problem is Python versions are breaking and whatnot (very often ML libraries are months behind latest) but the main Python installation you have only supports virtual environments for packages. Really it should support something like conda out of the box where you create an environment with a Python version.

Post reply on HN