4 ms·

Single-threaded in a multicore world is nice? Implicit type coercion on par with PHP is nice? Implicit var args are nice??? (That's the worst part by far). I wo

• kybernetikos 9y ago
  > Single-threaded in a multicore world is nice? Javascripts approach to threading - default single threaded event loop, but with message passing to communicate with other threads is actually a pretty good model for people who want to write multi-threaded code that doesn't break. This is important when coding for a very open platform like the web. Confusion about what is running on the UI thread and what isn't and how to communicate between them is the kind of error that pops up in java ui code. I wouldn't want that for the web. Besides, the threading approach is more about the runtime rather than the language. There are lots of clustering and threading libraries on npm if you want them for your server-side code, and you have WebWorkers in the browser. Sure, the implicit type coercion (pretty much everyone hates this) and var args (hasnt bothered me as much as it seems to have bothered you) were not good choices, although compare it to other languages of the time - first class functions were by no means universally available and now almost every modern language has them. A literal notation for maps in the language was a great decision too. Prototype inheritance may be a little weird but it is elegant, more general and radically simpler than class based inheritance. Javascript certainly has its warts but I find it fairly productive to code in. Plus it's paired with a runtime that has seen a shocking level of genius engineering over the last 10 years. The speed of iteration is unparalleled. The reach of a deployed piece of code is unique and likely to remain so for the foreseeable future. There aren't many other platforms that have developer tools for inspecting a running system, visualizing ui, network and detailed render performance that are as good.
  • anothergoogler 9y ago
    > Javascripts approach to threading - default single threaded event loop, but with message passing to communicate with other threads is actually a pretty good model for people who want to write multi-threaded code that doesn't break. This is simply wrong. The "approach" to threading is that there is none. It's single-threaded. You cannot write multi-threaded code directly in JS. On the server side, this can lead to things like a naive fetch after cache miss denying service to your web application. Nothing on the queue can run until the current function call finishes. Even lovely Python doesn't have this issue because, while the GIL is a PITA, Python has real threads, and can switch during a function call. To be clear, I'm not talking about web browser programming, where JS for some time has been the only option. I'm talking about the ridiculousness of server-side JS when we know clock speeds are hitting a wall and that parallelism is the only way to squeeze out more performance. Steele, Armstrong et. al. have lectured at length on this topic. > There are lots of clustering and threading libraries on npm No, there aren't. Running several node processes via PM2 is not threading. You cannot use multiple cores directly from the same Node program unless you drop down to C++. You can vaguely do it in the browser, but the limitations on communications between the main thread and web workers, especially with SharedArrayBuffer being off-limits post-Spectre, are pretty much non-starters. It's a nice option to have for specific cases (games programmers take advantage of web workers to read models without blocking the main thread, for instance), but it's only bolted onto web browsers.
    • kybernetikos 9y ago
      > You cannot use multiple cores directly from the same Node program unless you drop down to C++. Well, someone has to drop down to C++, but it doesn't have to be me (node webworker-threads). This is the same as in most languages. > you cannot use multiple cores directly from the same Node program unless you drop down to C++. As I said in my comment, threading is primarily a runtime thing, not a language thing. There are javascript runtimes (napa.js, node webworker-threads, nexusjs, browsers) that have threading (even by your restrictive definition that doesn't include threads layered onto child processes like the npm package 'threads' does), just as there are runtimes for e.g. java that do not (and the bulk of the threading support in most other language runtimes is also written in C++ so it seems churlish of you to complain about that in javascript runtimes). Most languages do not need significant changes to their syntax or keywords to support multithreading. Maybe you're comparing node.js specifically (where I think that for a long time there was a belief among the leads that letting the OS manage processes was a better approach - it's been interesting to watch this same argument play out in the rust community) with something like Go which has pleasant primitives for concurrency built in as part of the language. If you are, then to some extent I agree with you - something like goroutines might be really nice in javascript and is arguably better than what the js community has, but I also stand by my runtime/language distinction. Goroutines are not OS threads. You can run go programs with GOMAXPROCS set to 1 without changing the language at all.
  • anothergoogler 9y ago
    HN is not allowing me to edit my adjacent comment (11 minutes ago...), but I meant to add: I'm sort of amazed that the implicit var args don't bother you... with var args promoted to first class syntax in ES6, the only reason they're still there is for backwards compatibility. Passing an unhandled arg to a function should at least be a runtime error, and likewise omitting a positional arg that lacks a default. I've seen countless bugs caused by this "feature" alone. When I think of JS programming in the large, I think of "undefined is not a function" and "cannot read property 'foo' of undefined." It's quite hellish.