12 ms·

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. PyTo

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 system out of the water, runs in browsers, has non-stupid package management systems (PIP is a joke), is easy to get started, etc. <The world if data scientists/ML/CV people used Typescript.JPEG>

miketery 3y ago
Isn’t mojo the future on that front?
- crubier 3y ago
  Mojo looks cool. But I'll wait for it to be open sourced AND as easy to use as Typescript + React for real complex web apps before considering it. I expect this to take 2-5 years if it ever happens. It's a possible future, not the present.
skratlo 3y ago
[flagged]
winrid 3y ago
TS is a joke tsc is the only compiler I've had to step through with a debugger multiple times. No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. Not to mention unpredictable generational GC. Or the crazy crap people do with the type system (what you call better other people call a mess). At least Python has some semblance of runtime type safety.
- crubier 3y ago
  > TS is a joke I'll discuss facts > tsc is the only compiler I've had to step through with a debugger multiple times. 99.9% of Typescript developers never ever had to do that. Sounds like a "you" problem > No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. You're talking about NodeJS, which is just one of the many JS engines. It's also 200% easier to start NodeJS with a flag to increase the (sane) default memory limit, as compared to the insanity of setting up a Python environment. > Not to mention unpredictable generational GC. Is Python GC better? Really? The good thing with Python is that the whole language is so slow that GC is just a drop in the bucket. On the other hand, Millions (Billions?) have been spent optimizing JS engines and it shows. Also: GIL. > Or the crazy crap people do with the type system (what you call better other people call a mess). I don't know what you're talking about, TypeScript go Brrr and I get magnificent Intellisense and subtle type checking, while MyPy and friends keeps crapping their pants > At least Python has some semblance of runtime type safety. No. And critically it has no semblance of comp time type safety either.
  - cellularmitosis 3y ago
    > I'll discuss facts > the insanity of welp, so much for that.
    - crubier 3y ago
      Whoops ¯\_(ツ)_/¯
  - winrid 3y ago
    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 whole ecosystem stinks. I cannot wait to move my larger Node projects to Java or something else. Idk how much dev time people waste on arcane tsc or npm issues but the answer is "too high" regardless. At least esbuild is okay.
zelphirkalt 3y ago
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 better than poetry. Or at least I have not had a single case, where I thought: "Ah, if only it was behaving like NPM." Rather the opposite. But anyway, the whole language specific package manager business is starting to annoy me. I would like to be able to simply use something like GNU Guix and sometimes I am able to do just that.
- crubier 3y ago
  > 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.
  - Elfir3 3y ago
    Poetry has more to do with pip and virtualenv than NPM to be honest.
  - uranusjr 3y ago
    Citation needed. Poetry itself said Composer and Cargo were the main inspirations[1]. Both of them work differently from NPM; Poetry has mostly the same differences that its claim checks out. You would be in quite some surprises down the road if the sperficial similarities persuade you to apply one tool’s paradigm to another. [1]: https://github.com/python-poetry/poetry/tree/0.1.0#why https://github.com/python-poetry/poetry/tree/0.1.0#why
- crubier 3y ago
  > 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. Depends on the use case. For ML, sure, it doesn't. For web servers, it depends. For stuff like this React-like tool, it matters.
whatyesaid 3y ago
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 about experimentation. It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge.
- valtism 3y ago
  You don't exactly need to compile Typescript to make it run, you can just strip the types out which is much faster than compilation. If you want you can run `tsc` to have the compiler compile it and check for errors, but this can be running as you develop to act more as a linter.
- lukevp 3y ago
  Running esbuild to strip types and then running node, or using deno/bun, is much faster than Python. There’s also nothing that would prevent interactive JS or TS either… That’s what the browser debug console does.
- myrryr 3y ago
  > It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge. I guess you have completely missed people running language models on WebGPU then. I think webasm + webgpu will be a target for a lot of new ml libraries.
  - whatyesaid 3y ago
    Well yeah, as a sort of compilation target for sure, not just for language models but all ML models need to be integrated somewhere. The ML code and web code will be independent though.
    - crubier 3y ago
ideamotor 3y ago
I agree.
CJefferson 3y ago
My experience of doing maths in JavaScript was terrible. Fairly simple things like [1,2] < [10,2] return false (unlike every other language I’ve ever used), as < is implement by converting to strings, then comparing. Is that fixed by Typescript, or does it inherit all those kinds of weird JavaScript behavior?
- chrismorgan 3y ago
  TypeScript is a JavaScript superset. It adds features, but doesn’t change the meaning of existing stuff. (Almost all of what it adds can just be stripped out syntactically to yield JavaScript, but there are a few features that generate actual code, like enums.)
- TheAlchemist 3y ago
  I don’t get the example - how is it obvious what should be the result of comparison of 2 lists ?
  - boredemployee 3y ago
    In Python, when comparing lists using the less than (<) operator, the comparison is performed element-wise. The first element of each list is compared, and if they are not equal, the comparison result is determined based on the comparison of the first unequal elements. In this case, [1, 2] and [10, 2] both have different first elements (1 and 10). Since 1 is less than 10, the comparison result is True. The second element of both lists (2) does not affect the comparison result because the first element is already sufficient to determine the outcome. [1, 2] < [10, 2] evaluates to True.
    - coding_lobster 3y ago
      What's the use case for this?
      - CJefferson 3y ago
        Lots of mathematical algorithms sort lists lexicographically. It comes up in graphs and lots of other combinatorics problems. Often you want a total order on 2D coordinates, an this ordering is (usually) the simplest and best.
mountainriver 3y ago
Good luck recreating all the data science libraries in Javascript, that was decades of work. We now have WASM so its far more likely JS just isn't needed
- crubier 3y ago
  You might be surprised. https://news.ycombinator.com/item?id=36006626 https://news.ycombinator.com/item?id=36006626 But of course yes, The ML stuff should be Wasm and WebGPU. The point is you can access it from Typescript. Just like most data science libraries are not Python, they just have Python bindings.
pwdisswordfishc 3y ago
> has non-stupid package management systems Excuse me what
wraptile 3y ago
No please no. Can we just leave javascript and all of it's flavors behind already. All of this innovation and people want to program in _transpiled_ programming language? It's like turles all the way down but it's just hacks all the way down in the js world and it'll start catching up with us if it hasn't already.
- crubier 3y ago
  It’s not transpiled. Only some implementations of it are. Just use Bun or Deno with TypeScript. There is literally zero runtime impact. It’s just natively TypeScript.
  - sgammon 3y ago
    i believe deno compiles typescript on the fly, in a V8 isolate; it is not interpreted natively in the same way javascript is (but, yes, you don't have to bundle it or transpile it first)
robertlagrant 3y ago
Why not just implement a Typescript backend that outputs Python instead of Javascript? (-:

miketery 3y ago

Isn’t mojo the future on that front?

crubier 3y ago
Mojo looks cool. But I'll wait for it to be open sourced AND as easy to use as Typescript + React for real complex web apps before considering it. I expect this to take 2-5 years if it ever happens. It's a possible future, not the present.

skratlo 3y ago

[flagged]

winrid 3y ago

TS is a joke tsc is the only compiler I've had to step through with a debugger multiple times. No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. Not to mention unpredictable generational GC. Or the crazy crap people do with the type system (what you call better other people call a mess). At least Python has some semblance of runtime type safety.

crubier 3y ago
> TS is a joke I'll discuss facts > tsc is the only compiler I've had to step through with a debugger multiple times. 99.9% of Typescript developers never ever had to do that. Sounds like a "you" problem > No DS/ML researcher wants to deal with VM args just to use more than 1GB of memory. That alone would cause so much frustration. You're talking about NodeJS, which is just one of the many JS engines. It's also 200% easier to start NodeJS with a flag to increase the (sane) default memory limit, as compared to the insanity of setting up a Python environment. > Not to mention unpredictable generational GC. Is Python GC better? Really? The good thing with Python is that the whole language is so slow that GC is just a drop in the bucket. On the other hand, Millions (Billions?) have been spent optimizing JS engines and it shows. Also: GIL. > Or the crazy crap people do with the type system (what you call better other people call a mess). I don't know what you're talking about, TypeScript go Brrr and I get magnificent Intellisense and subtle type checking, while MyPy and friends keeps crapping their pants > At least Python has some semblance of runtime type safety. No. And critically it has no semblance of comp time type safety either.
- cellularmitosis 3y ago
  > I'll discuss facts > the insanity of welp, so much for that.
  - crubier 3y ago
    Whoops ¯\_(ツ)_/¯
- winrid 3y ago
  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 whole ecosystem stinks. I cannot wait to move my larger Node projects to Java or something else. Idk how much dev time people waste on arcane tsc or npm issues but the answer is "too high" regardless. At least esbuild is okay.

zelphirkalt 3y ago

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 better than poetry. Or at least I have not had a single case, where I thought: "Ah, if only it was behaving like NPM." Rather the opposite. But anyway, the whole language specific package manager business is starting to annoy me. I would like to be able to simply use something like GNU Guix and sometimes I am able to do just that.

crubier 3y ago
> 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.
- Elfir3 3y ago
  Poetry has more to do with pip and virtualenv than NPM to be honest.
- uranusjr 3y ago
  Citation needed. Poetry itself said Composer and Cargo were the main inspirations[1]. Both of them work differently from NPM; Poetry has mostly the same differences that its claim checks out. You would be in quite some surprises down the road if the sperficial similarities persuade you to apply one tool’s paradigm to another. [1]: https://github.com/python-poetry/poetry/tree/0.1.0#why https://github.com/python-poetry/poetry/tree/0.1.0#why
crubier 3y ago
> 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. Depends on the use case. For ML, sure, it doesn't. For web servers, it depends. For stuff like this React-like tool, it matters.

whatyesaid 3y ago

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 about experimentation. It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge.

valtism 3y ago
You don't exactly need to compile Typescript to make it run, you can just strip the types out which is much faster than compilation. If you want you can run `tsc` to have the compiler compile it and check for errors, but this can be running as you develop to act more as a linter.
lukevp 3y ago
Running esbuild to strip types and then running node, or using deno/bun, is much faster than Python. There’s also nothing that would prevent interactive JS or TS either… That’s what the browser debug console does.
myrryr 3y ago
> It's not like there's any overlap between current web developers and ML people anyway to need an unified bridge. I guess you have completely missed people running language models on WebGPU then. I think webasm + webgpu will be a target for a lot of new ml libraries.
- whatyesaid 3y ago
  Well yeah, as a sort of compilation target for sure, not just for language models but all ML models need to be integrated somewhere. The ML code and web code will be independent though.
  - crubier 3y ago

ideamotor 3y ago

I agree.

CJefferson 3y ago

My experience of doing maths in JavaScript was terrible. Fairly simple things like [1,2] < [10,2] return false (unlike every other language I’ve ever used), as < is implement by converting to strings, then comparing. Is that fixed by Typescript, or does it inherit all those kinds of weird JavaScript behavior?

chrismorgan 3y ago
TypeScript is a JavaScript superset. It adds features, but doesn’t change the meaning of existing stuff. (Almost all of what it adds can just be stripped out syntactically to yield JavaScript, but there are a few features that generate actual code, like enums.)
TheAlchemist 3y ago
I don’t get the example - how is it obvious what should be the result of comparison of 2 lists ?
- boredemployee 3y ago
  In Python, when comparing lists using the less than (<) operator, the comparison is performed element-wise. The first element of each list is compared, and if they are not equal, the comparison result is determined based on the comparison of the first unequal elements. In this case, [1, 2] and [10, 2] both have different first elements (1 and 10). Since 1 is less than 10, the comparison result is True. The second element of both lists (2) does not affect the comparison result because the first element is already sufficient to determine the outcome. [1, 2] < [10, 2] evaluates to True.
  - coding_lobster 3y ago
    What's the use case for this?
    - CJefferson 3y ago
      Lots of mathematical algorithms sort lists lexicographically. It comes up in graphs and lots of other combinatorics problems. Often you want a total order on 2D coordinates, an this ordering is (usually) the simplest and best.

mountainriver 3y ago

Good luck recreating all the data science libraries in Javascript, that was decades of work. We now have WASM so its far more likely JS just isn't needed

crubier 3y ago
You might be surprised. https://news.ycombinator.com/item?id=36006626 https://news.ycombinator.com/item?id=36006626 But of course yes, The ML stuff should be Wasm and WebGPU. The point is you can access it from Typescript. Just like most data science libraries are not Python, they just have Python bindings.

pwdisswordfishc 3y ago

> has non-stupid package management systems Excuse me what

wraptile 3y ago

No please no. Can we just leave javascript and all of it's flavors behind already. All of this innovation and people want to program in _transpiled_ programming language? It's like turles all the way down but it's just hacks all the way down in the js world and it'll start catching up with us if it hasn't already.

crubier 3y ago
It’s not transpiled. Only some implementations of it are. Just use Bun or Deno with TypeScript. There is literally zero runtime impact. It’s just natively TypeScript.
- sgammon 3y ago
  i believe deno compiles typescript on the fly, in a V8 isolate; it is not interpreted natively in the same way javascript is (but, yes, you don't have to bundle it or transpile it first)

robertlagrant 3y ago

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