4 ms·

Instead of responding to the fact that JavaScript: 1. Has no adequate threading model. 2. Has no reasonable type system. 3. Has better alternatives on the se

Instead of responding to the fact that JavaScript: 1. Has no adequate threading model. 2. Has no reasonable type system. 3. Has better alternatives on the server side. ...you're making it personal, and about the people. Look at your post; you're just accusing the critics of Node of feeling "intellectually superior". That's just an ad hominem attack. And you think that critics want you to rage quit the internet and give up? No, that's not what critics of Node want. Or at least, that's not what I want. What I want is for people to either acknowledge the problems with Node and fix them (unlikely), or start using better alternatives on the server side, and start investing more in WebAssembly and langauges targeting WebAssembly, so we don't have to use JavaScript any more. I want this because as long as Node/JavaScript are around, I have to either deal with those horrible tools, or not take those jobs. This isn't about feeling superior, it's about improving my life by using tools that aren't godawful.

jamescostian 10y ago
1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" 3. Nice opinion
- vonmoltke 10y ago
  > 1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html Process spawning and threading are two different but related mechanisms. The former is much more expensive and hard to use with optimization techniques like pooling. It also forces message passing for IPC rather than shared memory. > 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer.
  - deleted 10y ago
    [deleted]
  - kowdermeister 10y ago
    > Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer. Really, who cares? Types are important for the programmer not for the compiler. If I know what I'm doing then lack of ints doesn't concern me.
    - dottrap 10y ago
      There are certain classes of programming and mathematics that really need integers such as cryptography and fields that would need big number libraries.
      - kowdermeister 10y ago
        That's totally valid, but they shouldn't use Node.js if that's a mission critical part of the project. Nobody is saying that Node.js is the holy grail, but I see that expectations are that high.
  - buu700 10y ago
    Not that this should be necessary, but it'd actually be pretty simple for a compiler to fix #2: transform `const i: int = 3;` into `var i = new Int32Array([3]);` and change future references from `i` to `i[0]`. No clue what the performance implications would be for really heavy uses of this, but it'd at least be a workable solution if you absolutely required a true integer type at run-time.
  - geofft 10y ago
    asm.js has valid, correctly-behaving integers, and asm.js works correctly on non-asm.js-aware implementations, so the lack of a native integer doesn't seem like a problem. The emitted code might have lots of "|0"s in it, but I don't see many people complaining about the beauty of their C compiler's generated object code and the lack of native anything-other-than-integers.
deno 10y ago
1. For an async-first environment, which node mostly is, lack of threading is hardly an issue. Only threading node should ever have is the web worker w/ shared memory & atomic ops that’s already going into the Web Platform[1]. I say this is an advantage. 2. Typescript is great, it even has strict null checking via union types. Way better than the half-hearted attempt at optional typing you’ll find in Python 3. So if you think Python is a good ecosystem, then node is miles better. Sure, it’s not Scala, but on the other hand interop w/ Javascript and Web Platform is seamless. It’s a trade-off, but one that I think is very much worth taking. Also it compiles in seconds, not hours. 3. You can share code w/ client which is actually useful considering web app logic is moving client-side. See: React. 4. WebAssembly is nowhere ready. No idea if using it/tooling/debugging will be any good for anything other than what emscripten enables right now. It’s a very risky investment to be considering that early. Even if you think WebAssembly will pan out, the languages that will target it already target Javascript. It’s just alternative bytecode, really. [1] http://tc39.github.io/ecmascript_sharedmem/shmem.html#StructuredData.SharedArrayBuffer http://tc39.github.io/ecmascript_sharedmem/shmem.html#Struct...
- deleted 10y ago
  [deleted]
all2well 10y ago
>Has no reasonable type system I'll bite on this. Javascript's type system is with no question my favorite part of it! JS's object model is incredibly powerful, which is why ES6 classes are implemented basically as syntax sugar, and why so many languages can be transpiled to Javascript. I also don't think that the lack of threading is as much of a problem as you might think it is. For one, it means you can sidestep a lot of the data ordering problems that you get in a threaded environment. There's no question that Javascript has shortcomings, but so many of the problems that happen in Javascript come from people treating it like Java, when it's a lot more like Lisp. In many ways, the architecture of Javascript revolves around a very simple, powerful object model in a way that's tough to parallel in most other languages.
- grumpyprole 10y ago
  I'm guessing he mean't static type system. This is the formal meaning of "type" in programming language theory. What you describe is a system of runtime tags.

jamescostian 10y ago

1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" 3. Nice opinion

vonmoltke 10y ago
> 1. There are two built-in solutions to this (as well as a slew of other solutions in modules), the cluster module and the child process module: https://nodejs.org/api/cluster.html https://nodejs.org/api/cluster.html and https://nodejs.org/api/child_process.html https://nodejs.org/api/child_process.html Process spawning and threading are two different but related mechanisms. The former is much more expensive and hard to use with optimization techniques like pooling. It also forces message passing for IPC rather than shared memory. > 2. JS's duck typing is thought to be a "feature" to some and a "bug" to others, so if you think it's a bug, use TypeScript or Flow. They'll give you "reasonable type system[s]" Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer.
- deleted 10y ago
  [deleted]
- kowdermeister 10y ago
  > Nothing that transcompiles into JavaScript can fix JavaScript's lack of a native integer. Really, who cares? Types are important for the programmer not for the compiler. If I know what I'm doing then lack of ints doesn't concern me.
  - dottrap 10y ago
    There are certain classes of programming and mathematics that really need integers such as cryptography and fields that would need big number libraries.
    - kowdermeister 10y ago
      That's totally valid, but they shouldn't use Node.js if that's a mission critical part of the project. Nobody is saying that Node.js is the holy grail, but I see that expectations are that high.
- buu700 10y ago
  Not that this should be necessary, but it'd actually be pretty simple for a compiler to fix #2: transform `const i: int = 3;` into `var i = new Int32Array([3]);` and change future references from `i` to `i[0]`. No clue what the performance implications would be for really heavy uses of this, but it'd at least be a workable solution if you absolutely required a true integer type at run-time.
- geofft 10y ago
  asm.js has valid, correctly-behaving integers, and asm.js works correctly on non-asm.js-aware implementations, so the lack of a native integer doesn't seem like a problem. The emitted code might have lots of "|0"s in it, but I don't see many people complaining about the beauty of their C compiler's generated object code and the lack of native anything-other-than-integers.

deno 10y ago

1. For an async-first environment, which node mostly is, lack of threading is hardly an issue. Only threading node should ever have is the web worker w/ shared memory & atomic ops that’s already going into the Web Platform[1]. I say this is an advantage. 2. Typescript is great, it even has strict null checking via union types. Way better than the half-hearted attempt at optional typing you’ll find in Python 3. So if you think Python is a good ecosystem, then node is miles better. Sure, it’s not Scala, but on the other hand interop w/ Javascript and Web Platform is seamless. It’s a trade-off, but one that I think is very much worth taking. Also it compiles in seconds, not hours. 3. You can share code w/ client which is actually useful considering web app logic is moving client-side. See: React. 4. WebAssembly is nowhere ready. No idea if using it/tooling/debugging will be any good for anything other than what emscripten enables right now. It’s a very risky investment to be considering that early. Even if you think WebAssembly will pan out, the languages that will target it already target Javascript. It’s just alternative bytecode, really. [1] http://tc39.github.io/ecmascript_sharedmem/shmem.html#StructuredData.SharedArrayBuffer http://tc39.github.io/ecmascript_sharedmem/shmem.html#Struct...

deleted 10y ago
[deleted]

all2well 10y ago

>Has no reasonable type system I'll bite on this. Javascript's type system is with no question my favorite part of it! JS's object model is incredibly powerful, which is why ES6 classes are implemented basically as syntax sugar, and why so many languages can be transpiled to Javascript. I also don't think that the lack of threading is as much of a problem as you might think it is. For one, it means you can sidestep a lot of the data ordering problems that you get in a threaded environment. There's no question that Javascript has shortcomings, but so many of the problems that happen in Javascript come from people treating it like Java, when it's a lot more like Lisp. In many ways, the architecture of Javascript revolves around a very simple, powerful object model in a way that's tough to parallel in most other languages.

grumpyprole 10y ago
I'm guessing he mean't static type system. This is the formal meaning of "type" in programming language theory. What you describe is a system of runtime tags.