5 ms·

TypeScript is a pretty good language for writing web servers, as long as you don’t need to do computationally heavy parallel computing. And you can still do tha

by yashap 5y ago

TypeScript is a pretty good language for writing web servers, as long as you don’t need to do computationally heavy parallel computing. And you can still do that, but it’s very awkward. I’ve done plenty of backend work in all of TS, Scala, Go, Python and PHP. Scala is my personal favourite, but it’s not as practical for teams as TS or Go, which are both very productive languages, with good enough type safety and performance, that new devs can learn quickly. And I’d easily choose TS over PHP or Python for a large system. Plus, it IS pretty nice being able to use a single language everywhere. My current company is TS RESTful services with TS/React on the web, and TS/React Native on mobile, pretty hard to beat how easy it is to do full stack dev work for most ppl in this setup.

SavantIdiot 5y ago
> computationally heavy parallel computing. JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.) The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY. I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move
- lhnz 5y ago
  It sounds like you want something a bit like WebGPU: https://gpuweb.github.io/gpuweb/ https://gpuweb.github.io/gpuweb/
  - SavantIdiot 5y ago
    Close, but I don't want to have to switch memory models, e.g. upload/download. What I want is the incredibly diverse numerical computing support and logical syntax of NumPY but in the same process & memory space. The W3C endeavor is something a little different. Thanks tho!!
    - lhnz 5y ago
      I think you will be interested to read this article about the future of data programming in JavaScript (http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/ http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/). I do think that this kind of thing will be able to be built on top of WebGPU (I saw this experimental POC that did so recently: https://github.com/milhidaka/webgpu-blas https://github.com/milhidaka/webgpu-blas). The only issue is that since JavaScript doesn't support operator overloading even if a production-level library was created the code would be a little less readable.
      - SavantIdiot 5y ago
        This article nails it. While Python is such an elegant language for scientific research, it falls on its face when it comes to packaged applications (and as stated in my other posts, it's awkward async support compared to Node). I realllly hope scientific computing moves into NodeJS, or, Python gets better at asyncio and cross-platform packaging.
- yashap 5y ago
  Node does have worker threads. They’re awkward because no shared memory, lots of serialization overhead and boiler plate, but if you’ve got heavy data processing to do on say a 4-8 CPU machine, you can certainly split it up between 4-8 CPU threads.
  - hajile 5y ago
    Node supports SharedArrayBuffer. It’s not perfect, but is usable. In truth, assemblyscript or rust running in wasm is probably the best solution going forward.
    - yashap 5y ago
      True, but regardless, the kind of ergonomic, low overhead parallel computing available in Scala or Go just isn’t possible in Node. In Scala or Go, parallel computing is barely anymore difficult than synchronous computing, in Node it’s quite the pain in the ass once you want to start passing objects with methods and whatnot between threads.
  - SavantIdiot 5y ago
    That's process parallelism, not compute parallelism. To radically different things. I've avoided using node worker threads in favor child.fork, which then resolves to IPC through process.on and process.send, which is like any other process management.

by yashap 5y ago

SavantIdiot 5y ago

> computationally heavy parallel computing. JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.) The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY. I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move

lhnz 5y ago
It sounds like you want something a bit like WebGPU: https://gpuweb.github.io/gpuweb/ https://gpuweb.github.io/gpuweb/
- SavantIdiot 5y ago
  Close, but I don't want to have to switch memory models, e.g. upload/download. What I want is the incredibly diverse numerical computing support and logical syntax of NumPY but in the same process & memory space. The W3C endeavor is something a little different. Thanks tho!!
  - lhnz 5y ago
    I think you will be interested to read this article about the future of data programming in JavaScript (http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/ http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/). I do think that this kind of thing will be able to be built on top of WebGPU (I saw this experimental POC that did so recently: https://github.com/milhidaka/webgpu-blas https://github.com/milhidaka/webgpu-blas). The only issue is that since JavaScript doesn't support operator overloading even if a production-level library was created the code would be a little less readable.
    - SavantIdiot 5y ago
      This article nails it. While Python is such an elegant language for scientific research, it falls on its face when it comes to packaged applications (and as stated in my other posts, it's awkward async support compared to Node). I realllly hope scientific computing moves into NodeJS, or, Python gets better at asyncio and cross-platform packaging.
yashap 5y ago
Node does have worker threads. They’re awkward because no shared memory, lots of serialization overhead and boiler plate, but if you’ve got heavy data processing to do on say a 4-8 CPU machine, you can certainly split it up between 4-8 CPU threads.
- hajile 5y ago
  Node supports SharedArrayBuffer. It’s not perfect, but is usable. In truth, assemblyscript or rust running in wasm is probably the best solution going forward.
  - yashap 5y ago
    True, but regardless, the kind of ergonomic, low overhead parallel computing available in Scala or Go just isn’t possible in Node. In Scala or Go, parallel computing is barely anymore difficult than synchronous computing, in Node it’s quite the pain in the ass once you want to start passing objects with methods and whatnot between threads.
- SavantIdiot 5y ago
  That's process parallelism, not compute parallelism. To radically different things. I've avoided using node worker threads in favor child.fork, which then resolves to IPC through process.on and process.send, which is like any other process management.