7 ms·

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some of the mistakes of a terribly engineered language. Javascript should never have been considered a serious language for back-end development. Node.js to me seems like someone's 'Frankenstein's monster'-esque experiment that escaped its captivity and wreaked wide-scale havoc on the surrounding world.

osrec 6y ago
Terribly engineered because it's not type checked, or for some other reason?
- petre 6y ago
  Many reasons, some of which Dart fixes. Too bad it hasn't catched on. Now it's a language to build mobile apps with. Maybe it will be usable for cross platform desktop GUIs as well. And hopefully some of its sane language features will be ported to future versions of ES. https://medium.com/flutter-community/the-ultimate-javascript-vs-dart-syntax-guide-2f7d8ad8bde6 https://medium.com/flutter-community/the-ultimate-javascript...
hombre_fatal 6y ago
This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.
- thelazydogsback 6y ago
  Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node (and Deno, FWICT) lack general native or green thread support for true multi-processing without serialization to separate clusters, so you are forced to use async and timers for long-running or parallel work.
  - tannhaeuser 6y ago
    Well the async/evented execution model, and omitting synchronize, complex "happens-before" semantics, and shared memory a la Java (which JavaScript and V8 lacks) is the entire point of node.js and libuv. I agree that it doesn't fit typical complex business logic with expectations of some level of isolation, but then node.js isn't a good fit for these kind of problems. Node.js is based on CommonJS, and there are/were alternative implementations of a CommonJS runtime, including process-per-request implementations like v8cgi/TeaJs, or implementations based on Rhino (Mozilla's venerable JavaScript engine written in Java) such as Ringo which can call into the JVM, and do multithreading. Complaining about this on node.js is complaining about your own decision to use node.js really. And multithreading isn't great either for these workloads; it was originally invented for coroutines in desktop apps.
    - thelazydogsback 6y ago
      > Complaining about this on node.js is complaining about your own decision to use node.js really Yes - but there isn't much choice in the mainstream. Sure, I'd rather use .net core/Kestral, but if you want back-end JS/TS then Node is it, unless your org let's you experiment w/Deno or other.
  - hombre_fatal 6y ago
    I'm not being unfair when I enumerate the most popular languages for comparison. When people crap on Javascript, they presumably prefer another language. And C#/Kotlin aren't exactly the top picks. Kotlin has BYOB coroutines which are hard to work with. People don't use them. Going with the C# approach where async behavior looks sync was a bad move. I predict Kotlin's coroutines will never be a centerpiece abstraction just like how people don't really use Go's channels (people in practice just go back to Mutexes). I mean, try it. Write the equivalent to this in Kotlin: // get background work started now const background = promise() // crawl some urls concurrently as well, just 4 at a time const crawl = Promise.map(urls, crawl, { concurrency: 4 }) // while that's going on, we have some work that // we must get done. for (const task of tasks) { await worker(task) } // worker's done, now we can wait on // the crawler and background work. const [a, b] = await Promise.all([ crawl.then(processResults), background ]) CSP never caught on because after you have more than one channel as a central bus (the toy architecture), you immediately descend into channel hell. In-channels, out-channels, channels over channels. Back to using pencil and paper and scouring your code to decode the classic buffer bloat problem. A single-threaded event loop with a central promise abstraction is a great way to write networked code. Btw, I use Kotlin in a large JVM project and I'm stuck with the horror of https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre.... That's more likely what you'll be doing day to day with Kotlin, not playing with its toy coroutines.
WorldMaker 6y ago
Deno's existence is partly based on the idea that Typescript would need to be a first class citizen in whatever Node's successor will be.

osrec 6y ago

Terribly engineered because it's not type checked, or for some other reason?

petre 6y ago
Many reasons, some of which Dart fixes. Too bad it hasn't catched on. Now it's a language to build mobile apps with. Maybe it will be usable for cross platform desktop GUIs as well. And hopefully some of its sane language features will be ported to future versions of ES. https://medium.com/flutter-community/the-ultimate-javascript-vs-dart-syntax-guide-2f7d8ad8bde6 https://medium.com/flutter-community/the-ultimate-javascript...

hombre_fatal 6y ago

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

thelazydogsback 6y ago
Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node (and Deno, FWICT) lack general native or green thread support for true multi-processing without serialization to separate clusters, so you are forced to use async and timers for long-running or parallel work.
- tannhaeuser 6y ago
  Well the async/evented execution model, and omitting synchronize, complex "happens-before" semantics, and shared memory a la Java (which JavaScript and V8 lacks) is the entire point of node.js and libuv. I agree that it doesn't fit typical complex business logic with expectations of some level of isolation, but then node.js isn't a good fit for these kind of problems. Node.js is based on CommonJS, and there are/were alternative implementations of a CommonJS runtime, including process-per-request implementations like v8cgi/TeaJs, or implementations based on Rhino (Mozilla's venerable JavaScript engine written in Java) such as Ringo which can call into the JVM, and do multithreading. Complaining about this on node.js is complaining about your own decision to use node.js really. And multithreading isn't great either for these workloads; it was originally invented for coroutines in desktop apps.
  - thelazydogsback 6y ago
    > Complaining about this on node.js is complaining about your own decision to use node.js really Yes - but there isn't much choice in the mainstream. Sure, I'd rather use .net core/Kestral, but if you want back-end JS/TS then Node is it, unless your org let's you experiment w/Deno or other.
- hombre_fatal 6y ago
  I'm not being unfair when I enumerate the most popular languages for comparison. When people crap on Javascript, they presumably prefer another language. And C#/Kotlin aren't exactly the top picks. Kotlin has BYOB coroutines which are hard to work with. People don't use them. Going with the C# approach where async behavior looks sync was a bad move. I predict Kotlin's coroutines will never be a centerpiece abstraction just like how people don't really use Go's channels (people in practice just go back to Mutexes). I mean, try it. Write the equivalent to this in Kotlin: // get background work started now const background = promise() // crawl some urls concurrently as well, just 4 at a time const crawl = Promise.map(urls, crawl, { concurrency: 4 }) // while that's going on, we have some work that // we must get done. for (const task of tasks) { await worker(task) } // worker's done, now we can wait on // the crawler and background work. const [a, b] = await Promise.all([ crawl.then(processResults), background ]) CSP never caught on because after you have more than one channel as a central bus (the toy architecture), you immediately descend into channel hell. In-channels, out-channels, channels over channels. Back to using pencil and paper and scouring your code to decode the classic buffer bloat problem. A single-threaded event loop with a central promise abstraction is a great way to write networked code. Btw, I use Kotlin in a large JVM project and I'm stuck with the horror of https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre.... That's more likely what you'll be doing day to day with Kotlin, not playing with its toy coroutines.

WorldMaker 6y ago

Deno's existence is partly based on the idea that Typescript would need to be a first class citizen in whatever Node's successor will be.